关系型数据库与Key-value型数据库Mongodb模式设计对比

fmms 12年前

       MongoDb 相比于传统的 SQL 关系型数据库,最大的不同在于它们的模式设计( Schema Design )上的差别,正是由于这一层次的差别衍生出其它各方面的不同。

    我们可以简单的认为关系型数据库由数据库、表(table)、记录(record)三个层次概念组成,而在构建一个关系型数据库的时候,工作重点和难点都在数据库表的划分与组织上。一般而言,为了平衡提高存取效率与减少数据冗余之间的矛盾,设计的数据库表都会尽量满足所谓的第三范式。相对的,可以认为MongoDb由数据库、集合(collection)、文档对象(Document-orientedBSON)三个层次组成。MongoDb里的collection对应于关系型数据库里的表。当然,不要期望collection会满足所谓的第三范式,因为它们根本就不在同一个概念讨论之内。类似于表由多条记录组成,集合也包含多个文档对象,虽然说一般情况下,同一个集合内的文档对象具有相同的格式定义,但这并不是必须的,即MongoDb的数据模式是自由的(schema-free、模式自由、无模式)。

    以一实例来说,假设我们需要设计一个小型数据库来存储学生、地址、科目、成绩这些信息,那么关系型数据库的设计如图1所示,而Key-value型数据库的设计则可能如图2所示。

 

 

关系型数据库与Key-value型数据库Mongodb模式设计对比

 

  

1、关系型的数据库设计

 

关系型数据库与Key-value型数据库Mongodb模式设计对比

 

2Key-value型的数据库设计(直接借用的mongodb官方图)

        对比图1和图2,在关系型的数据库设计里划分出了4个表,而在Key-value型的数据库设计里却只有两个集合。如果说集合与表一一对应的话,那么图2中应该也有4个集合才对,为什么可以把本应该是集合的addressscores直接合入了集合students中?原因就在于在Key-value型的数据库里,数据模式是自由的。

scores来说,在关系型的数据库设计中将其单独成一个表是因为studentscore是一对多的关系,如果将score合入student表,那么就必须预留最多可能的字段,这会存在浪费,并且当以后新增一门课程时扩展困难,因此一般都会将score表单独出来。而对于Key-value型的数据库就不同了,其scores字段就是一个BSON,该BSON可以只有一个for_course,也可以有两个、三个、任意个for_course,其固有的模式自由特性使得它可以将score包含在内而无需另建一个score集合。

       对于与student为一对一关系的address表也可以直接合入student,无需担心address的扩展性,当以后需要给address新增一个province字段,直接在数据插入时加上这个值即可。

        当然,对于与student成多对多关系course表,为了减少数据冗余,可以将course建立为一个集合,同关系型的数据库设计中类似。

        对比于关系型的数据库,在Key-value型的数据库里将数据合入一起有几大好处:首先,数据检索时没有了进行表间连接(join)的巨大开销(虽然目前MongoDb中没有join的概念);其次,合入一起的数据在磁盘上的存放也更容易在一起,因此数据的读取/写入都更快速。另外,无需担心扩展性问题,Key-value型数据库的自身特性使得字段的增删改十分容易。