加入收藏 | 设为首页 | 会员中心 | 我要投稿 李大同 (https://www.lidatong.com.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 百科 > 正文

<NoSQL精粹>---sadalage/fowler

发布时间:2020-12-13 13:43:02 所属栏目:百科 来源:网络整理
导读:主要讲了nosql各个框架的优缺点,特别与RDBMS做了比较,简略说明了哪些东西适合哪个框架以及nosql的ACID问题 第一章 关系型数据库确实提供了很多好的机制,在持久化和控制并发以及事务上有很好的处理但是从根本的角度,关系模型和内存中的数据结构(键值对)生来就

主要讲了nosql各个框架的优缺点,特别与RDBMS做了比较,简略说明了哪些东西适合哪个框架以及nosql的ACID问题

第一章

关系型数据库确实提供了很多好的机制,在持久化和控制并发以及事务上有很好的处理但是从根本的角度,关系模型和内存中的数据结构(键值对)生来就不匹配,或者称为"阻抗失谐".虽然后期出现了ORM框架来改善这种阻抗失谐,但是高并发查询/修改多关系的表时,就遇到了数据库的瓶颈.此时nosql就能改善这个问题(当然要基于良好的框架选择和优良的"存储模式"),特别是在集群中,nosql更好

第二章

面向关系和面向聚合.在集群中,key是采集数据时所需节点数降至最小,nosql在此时就非常强大了,因为可以把聚合包含的信息弄大一点,包含很多东西(具体看业务需求).键值数据模型(redis)查询时获取整个聚合,文档数据模型(MongoDB)可以只获取部分聚合,还可以创建聚合内容的索引.为保证事务,最好以聚合为最小数据单位操作.所以如果数据交互大多在同一聚合内执行的,可以用面向聚合的数据库(nosql大多都是).

第三章

物化视图/映射化简,就像索引一样,预先准备好业务上要查询的数据,执行时直接拿.nosql这点上比rdbms好,因为它已经持久化了一份.面向聚合的数据库在处理聚合之间的关系时,显得有点棘手.

第六章

不用事务,用版本戳代替,实现离线的并发实现,很好的解决了锁带来的性能问题.

第八章

键值数据库适合存放 会话信息 用户配置信息 购物车数据.不适合数据间关系,含有多项关键操作的事务.查询键值对的某部分值来搜寻关键字(可用lucene等)

nosql目前还是属于年轻的东西,如果目前能忍受的情况下,尽量用RDBMS,因为20多年的积累,相关问题肯定有专家的解决方案

(编辑:李大同)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    推荐文章
      热点阅读