History Repeats Itself, C Mohan 讨论NoSQL的得与失
【1】关系数据库的不足，
a. 不能很好的为Web 2.0的业务做建模（搜索与社交图谱），
b. 无法在数据库层面很好的与JSON等做数据交换,
c. SQL语言与编程语言的差异带来的开发学习使用成本,
d.是否开源，代码能否改动,
f. 关系数据库的优化器、解析器代价太大，影响响应时间、吞吐量，
g.不能很好的满足业务对Scalability以及低成本服务器的需求，
h.在Scale out的情况下的管理复杂度，
i. 不能方便的调整业务的ACID需求，主要为Relax Consistency与Relax Durability的需求。
【2】在构建传统关系数据库方面得到的一些教训，
a. System/38 以对象存储开始，忽略关系，使用paging做缓存管理，锁粒度过粗，
b. Lotus Notes 恢复模块设计简陋，不支持事务处理，大量扩展性较差的内部模块，没有Buffer管理模块，为后续的改造带来了大量的困难,
c. 降低锁粒度非常痛苦,
d. 对于一个类似于DB2这样的产品，要增加Shared Disk的Cluster的支持将会遭遇非常大挑战，需要对buffer/log/lock/recover做全面的改造。
【3】NoSQL的通用问题,
a. 缺少对提高单机并发度至关重要的锁粒度的关注,
b. 缺少对多条记录处理的原子性（Atomicity）的关注,
c.缺少对统一标准的关注,
d. 忘记了高级查询语言与应用程序代码访问独立性的考虑，期待应用开发人员去实现传统数据库中的优化器、并发控制等技术。
【4】关于Index,
a. 仅支持单节点、单Key的操作，功能过于单一，
b. 随着时间、功能的推进，NoSQL需要重新发明主索引、辅助索引，本地索引、全局索引等问题，
c. 对索引的锁与恢复的处理过于简单，会在后续高并发的情况遇到较多坑。
【5】数据模型，
a. 有些NoSQL的数据模型比RDBMS更加复杂，
b. 缺少对应的工具来维护这些复杂的数据模型,
c. 相关的数据建模缺少标准化，为后续的Vendor替换带来障碍，有些通过自己养工程师来解决，企业级客户会很惨,
d. 传统企业做这种业务变更与基础架构变更的困难很大，成本也不低。
【6】文档存储，
a. Lotus 开始的设计为并发与扩展性考虑不够，花费了很大代价来改造，
b. MongoDB依赖单一写入锁，以及没有Buffer管理，
c. CouchBase的Rep做整个Doc的Rep，对于小Doc还行，大Doc的代价会很大,
【7】对事务（ACID）的误读，
a. 只要考虑多记录更新，或单个Key的增量并发更新，继续考虑事务问题，
b. Lotus Notes早期的实现存在并行更新冲突，后通过应用基于日志的恢复与事务解决，
c.对于维护内部的空间管理与数据结构的并发访问，也需要考虑细粒度锁来支撑高并发访问，
d. RDBMS也并不支持完整ACID