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数组。
推荐阅读：