MongoDB简单调研


背景

一直受传统RDB的影响,对于数据库表的设计可能大多数开发者都形成了思维定势。在云计算和大数据背景下,RDBMS正在接近极限,KV存储将受到越来越多的关注。学习NoSQL,不求能革RDBMS的命,但希望在设计思路上能得到一些拓宽,很多场景里,SQL表的设计和计算语句其实蛮难受的。

RDBMS天生不是分布式的,因其保持着ACID的特性发展至今,非常重视数据完整性,但在机器规模增长的情况下,ACID是不可扩展的。同时,随着数据量和访问频率增加,ACID所要维护的开销在增大。分割数据库,无论水平还是垂直,都是在分散总数据和读取需求,达到优化目的,维护代价和难度也随之上升。而KV的查找本质是散列表,且数据量无论如何增大,查找时间几乎固定不变,即非常适合大规模数据。ACID很注重CAP中的C,而参考现实世界中很多事务,比如快递,从你下单、付款到取货,资金和物品的流转并不严格一致,只要在一段时间内整个交易的最后结果满足一致性就可以了。同样,NoSQL和RDBMS比,更偏向于BASE(Basically Available, Soft-state, Eventually consistent)的折中,重视可用性,但不追求状态的严密性,且满足最终一致性。下面我以mongodb为例,展现一些他的特性和场景,期待NoSQL在当下能被更多的开发者拿来一显身手。

mongodb与RDBMS

mongodb是面向文档的nosql,CouchDB则是这一类数据库的元祖。从总体上看,

mongodb是最亲和RDBMS的一个NoSQL,能解决大部分关系型数据库解决的问题

跟面向列存储的HBase相比,面向文档存储和面向行存储更接近,比如在没有索引的情况下,扫描整个表内记录,同样是扫描全文档,及文档的每个字段

mongodb的索引同样也是B树,在一些索引的优化和设计上会和MySQL比较相似(当然需要遵循mongo的设计来做,不完全划等号)

你可以把mongodb拿RDBMS一样来使用(当然不推荐这么做),无非是将一行记录变成mongodb里的json对,在document(相当于mysql的table)之间,也可以做类似外键一样的引用

mongodb虽然没有严格的事务性操作,但是开发者自己可以做到类似事务的效果。这一点也算是mongodb贴近RDBMS的一个表现吧。

以下会从各个主要关注点来展开mongo的特性,展现角度更偏向于想要调研使用mongodb的人,看看mongodb是否符合自己的业务场景,也希望我的分析会有所帮助。

存储结构怎么样

Mongodb的存储类似JSON,每个db内有多个collection,相当于table,每个collection内是许许多多的document,这个document的schemeless的。本质上,他的面向文档指的是key-value中的value,而这个value可以是一个值(引用id或基本类型),可以是一个数组,也可以是一个文档(嵌套的json对)。

一对多是最常遇到的场景,mysql中要使用两张或以上表的关联甚至join进行查询,在mongo中直接使用嵌套型或引用型(用id)就可以了。没有特殊需求的话,嵌套的方式只要一张"表"就可以实现。比如我这样建立一个人的信息:

{
    id : 1,
    name : "pelick",
    hobbies : {
        "GameA", "GameB", "GameC"
    },
    friends : {
        male : {
              2, 3, 4 # id refer to other person
        },
        female : {
            {
                  name : "Rita",
                  hobbies : { "dancing" }
            },
            {
                  name : "Kaka",
                  nickname : "Riva"
            }
          }
      }
}

上述这样的结构中,展现了无模式、value为数组、嵌套、引用等。

处理好多对多的关系可谓是NoSQL的精髓所在。理论上,可以在一个集合中完成存储。不过实际上这样的情况非常罕见。这是由于查询的多样性所导致的,若是只有一种类型的查询,则这种多对多的关系放在一个良好设计的集合中,虽然会有大量的冗余,但是效率一定是最高的。如何设计这种数据库的关键就是看你有多少种查询,每一种的频率是多少,使用的其他要求是什么样的。对于不同的查询,同样的数据库设计的性能也是大不一样。还有一点,一般不要拆成三个集合,这是传统的关系型数据库的思维方式。而常见的情况就是拆成两个集合,然后有一部分冗余,对最常用的查询做一个索引。

总结就是两张表,一张里面存了另外一张里的id集合,有冗余存放,主要是根据查询场景设计和建索引,不要和RDBMS一样变三张。此外还有个好处是可以进行正反向查询,在各自的字段里加上id数组。

接下来请看第2页精彩内容

推荐阅读:

 

CentOS编译安装MongoDB

 

CentOS 编译安装 MongoDB与mongoDB的php扩展

CentOS 6 使用 yum 安装MongoDB及服务器端配置

Ubuntu 13.04下安装MongoDB2.4.3

如何在MongoDB中建立新数据库和集合

MongoDB入门必读(概念与实战并重)

  • 1
  • 2
  • 3
  • 下一页

相关内容