聚合国内IT技术精华文章,分享IT技术精华,帮助IT从业人士成长

C Mohan 讨论NoSQL的得与失

2013-04-13 15:31 浏览: 7147 次 我要评论(0 条) 字号:

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

No related posts.



网友评论已有0条评论, 我也要评论

发表评论

*

* (保密)

Ctrl+Enter 快捷回复