NoSql数据库 设计上面的一些心得
NoSql数据库这个概念听闻许久了，也陆续看到不少公司和产品都在使用，优缺点彷佛都被分析的清清楚楚。但我内心一直存有一个疑惑，它的出现到底是为了解决什么问题？html
用户信息表，书籍信息表，用户为书籍打分信息表，评论表。sql
如今假想要作一个显示评论内容的页面，上面会有用户信息和相关书籍的信息，想必你们脑子里已经出现各类select和join了吧。数据库
若是用NoSql仍是一样的设计的话，那你会惊喜的发现NoSql数据库的性能简直差到爆。性子火爆的估计当场就要掀桌。数据结构
什么破烂数据库，不是号称性能一流的吗！性能
好吧，性能问题也就不说了，居然连事务都不支持！？那我同时插入四张表的数据该怎么保持一致？开玩笑的吧！url
NoSql数据库此时默默的泪流满面，冤枉啊……你别说，还真是冤枉它了。spa
先从最基本的设计元素提及，几乎全部的NoSql数据库都没有表（table）的概念，取而代之的是文档（document）。文档是个什么东西？Mongodb的解释，文档是一个使用JSON格式以key-value方式存储数据的结构，好比：设计
{ "item": "pencil", "qty": 500, "type": "no.2" }
看起来和表没什么不一样嘛？咳咳，JSON是支持嵌套结构的，好比能够把书籍信息和用户打分的信息存到一块儿：
{ "id": "123zxcrweq2", "title": "雪中悍刀行", "author": "烽火戏诸侯", "scores": [ { "userid": "454zxcfwer1", "nickname": "Allen", "score": 3, }, { "userid": "678zxkiou1", "nickname": "Judy", "score": 4, } ], }
一堆document存储到一块儿就叫作collection，而同一个collection里面的document能够不同。注意，这里也是重点概念。若是切换到关系型数据库的话，至关于一张表里每一行数据的列均可以不同。这不是乱套了吗？用很差确实会乱套的。code
概念说完了，来看看面对下面这种产品要求的时候应该怎么办。产品经理说了，要在书籍信息页面看到全部评论，评论人的信息和打的分也要出现。htm
若是是关系数据库，获取数据的思路是这样的：
1. 根据书籍Id取到书籍信息。
2. 根据书籍Id取到全部评论信息。
3. 根据评论信息中的用户Id取到相关用户的信息。
4. 根据书籍Id和用户Id取到打分信息。
那在NoSql数据库中若是咱们用以下结构存储数据的话……
{ "id": "123zxcrweq2", "title": "雪中悍刀行", "author": "烽火戏诸侯", "comments": [ { "author": { "id": "454zxcfwer1", "nickname": "Allen", "avatarurl": "头像1.png", }, "score": 3, "title": "书评1", "content": "书评内容1", }, { "author": { "id": "454zxcfwer1", "nickname": "Judy", "avatarurl": "头像2.png", }, "score": 4, "title": "书评2", "content": "书评内容2" } ], }
彷佛只要根据书籍Id查询一次就能获得结果了吧……明白为何说NoSql数据库效率高了吗？一边是从四个集合中查找数据，一边是从一个集合中查找数据，这运行效率肉眼就能看出来差异了吧。
因此到这里我获得了一条设计心得，尽量把一次展现所需的必要数据都存储到一块儿。这是典型的空间换时间。所幸如今的科技条件下空间的价格很是低廉，因此很划算。
根据这个设计结构，彷佛也不须要事务的支持了，用户为一本书籍打分只须要在一个document里面添加数据就够了。
好，document特性的用处明白了，如今就来研究下NoSql数据库另一条原则的用途了，还记得是什么吗？同一个collection里面的document能够不同。
仍是从实际应用中来看，某日，产品经理说，书籍详细信息页面上还要显示书评的建立时间。
若是使用关系数据库该怎么办？
1. 建立一个为Review表增长”creationtime“列的sql脚本。
2. 到数据库中运行。
3. 修改相关代码和存储过程。
NoSql呢？
1. 在Comment结构实体中增长CreationTime，增长赋值代码。
没了，不须要去修改历史数据，由于？同一个collection里面的document能够不同。那若是取到历史数据怎么办？Comment的CreationTime会被置为空。挺合理的，也不会产生什么危害。
大 家都知道，互联网产品的更新速度是很是快的，常常根据用户反馈和市场状况调整产品形态，而数据结构也会常常发生变化。为了适应这种环境，如何处理历史数据 就成了老大难。还记得当年看到一个DBA在设计表的时候会留出几个字段叫作”Reserved1，Reserved2……“，感受好无厘头，浪费空间，后 来随着产品功能的增长才明白这实际上是经验丰富的表现。若是用NoSql就不用这么纠结了。
总结一下，就我浅薄的使用经验来看，NoSql的优势是：1. 在精心的设计下查询性能巨好。2. 数据结构弹性十足，特别适合快速发展中的产品。
另外须要提醒一下，Mongodb不支持事务，因此务必在设计的时候考虑到这一点。核心业务数据尽量经过结构设计作到数据插入的一致性。若是实在没法达成，请当即转回去用关系数据库，不然或早或晚你必定会后悔的。
本文连接：http://www.cnblogs.com/AllenDang/p/3507821.html#!comments