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

建议继续学习：

1. hbase运维    (阅读：13598)
2. 我对技术方向的一些反思    (阅读：9677)
3. Key-Value小数据库tmdb发布：原理和实现    (阅读：7255)
4. SQL vs NoSQL：数据库并发写入性能比拼    (阅读：6455)
5. 让Redis使用TCMalloc，实现高性能NOSql服务器    (阅读：6019)
6. SQL到NOSQL的思维转变    (阅读：5539)
7. Using MySQL as a NoSQL    (阅读：5523)
8. nosql数据库选型    (阅读：4641)
9. 分享会-高性能nosql数据库redis    (阅读：4363)
10. MySQL vs NoSQL 效率与成本之争    (阅读：3647)