C Mohan 讨论NoSQL的得与失
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
建议继续学习:
- hbase运维 (阅读:13670)
- 我对技术方向的一些反思 (阅读:9852)
- Key-Value小数据库tmdb发布:原理和实现 (阅读:7305)
- SQL vs NoSQL:数据库并发写入性能比拼 (阅读:6610)
- 让Redis使用TCMalloc,实现高性能NOSql服务器 (阅读:6089)
- SQL到NOSQL的思维转变 (阅读:5635)
- Using MySQL as a NoSQL (阅读:5653)
- nosql数据库选型 (阅读:4803)
- 分享会-高性能nosql数据库redis (阅读:4440)
- MySQL vs NoSQL 效率与成本之争 (阅读:3794)
扫一扫订阅我的微信号:IT技术博客大学习
- 作者:jametong 来源: a db thinker's home
- 标签: NoSQL
- 发布时间:2013-05-28 14:51:20
- [66] Go Reflect 性能
- [66] Oracle MTS模式下 进程地址与会话信
- [65] 如何拿下简短的域名
- [59] android 开发入门
- [59] IOS安全–浅谈关于IOS加固的几种方法
- [59] 图书馆的世界纪录
- [58] 【社会化设计】自我(self)部分――欢迎区
- [53] 视觉调整-设计师 vs. 逻辑
- [47] 界面设计速成
- [47] 读书笔记-壹百度:百度十年千倍的29条法则