文章吧-经典好文章在线阅读:NoSQL精粹读后感10篇

当前的位置:文章吧 > 经典文章 > 读后感 >

NoSQL精粹读后感10篇

2018-03-07 21:16:02 来源:文章吧 阅读:载入中…

NoSQL精粹读后感10篇

  《NoSQL精粹》是一本由[美]Pramod J. Sadalage / [美]Marti著作机械工业出版社出版的平装图书,本书定价:49.00元,页数:176,文章吧小编精心整理的一些读者读后感希望对大家能有帮助

  《NoSQL精粹》读后感(一):很全面 很精粹

  这本书的作者数据库重构的作者,可见对数据库的功力是可以的。

  书中的精华是前面6章。

  关系数据库被称为关系数据库,是因为关系太重要的。所有的数据库都避免不了。一种方式是关系分散到各个地方,通过外键关联,这个是普通关系数据库。一种是聚合关系,把关系放在一起,这种有kv数据库和文档数据库以及图数据库,列族数据库。

  关系的聚合,可以理解对象,对于面向对象的应用层来说是很用好的。

  但是这些新的数据库都没有去完全实现多行事务。一个解决办法是尽量聚合在一起,这样保证单个对象的事务就可以了。

  对于分布式数据库来说cap也是难以回避的。一般保证一致性的代价太高,会选择牺牲一点一致性,来提高一点可用性。在事务和读写效率做权衡的时候会用到仲裁,一般是超过半数通过就可以了。R+W>N,调整不同的r和w来做权衡。

  分布式实现事务也一般会用到版本戳。

  在分布式模型中接触最多的应该是分片和复制了。分别是纵向和横向的扩张。

  复制可以降低压力,但是必然存在延时,不管是主从复制还是对等复制。延时就会带来不一致。

  非关系型数据库的分片有个优点,分片时候关联的数据还是在一起。如果是关系数据库没处理好的话,join的数据在不同的机器,那个就比较蛋疼了。

  关系型数据库说白了是没有固定关系的,你可以通过不同的关联去产生不同的关系。这个是优点,但是要去关联,这个是个比较复杂事情。nosql一般会存储的时候就把关系写在一起,对于应用程序来说是很方便的,但是应用程序需要多个关系的时候呢,这时候就比较麻烦了。所以nosql一般适用于简单场景

  列族数据库我也是认为比较有意思的。他把多行看成一个整体,称为列族。他跟关心列本身,一般的数据库更关心行。他有kv数据库的优点,能通过key获取。有文档数据库的有点,他的列是可以扩展的。从面向对象的角度来看,可以理解为他更关心子对象的集合。他的一个核心优势是处理集合,而且处理的是子对象,粒度更细也更有效率。

  《NoSQL精粹》读后感(二):笔记

  第一章 FS vs Sql vs NoSql

  1.文件系统和数据系统对比

  a.文件系统和数据库是对数据不同层次上的抽象

  文件系统完全不了解数据的文件内容结构

  数据库在一定程度上了解数据的结构,比如关系型数据库知道数据是由哪些字段组成的。

  数据库有很多类型,每种的数据模型都不同,是对不同类型的数据的抽象,所以才会有关系数据库,键值数据库,图数据库等等。但这几种数据抽象不是互斥的,而是看应用数据/场景和哪种数据模型更匹配

  .查询,并发控制等的粒度不同

  因为文件系统不了解数据的结构,所以对数据的操作粒度只能在文件级别上(对整份数据进行操作)。

  数据库可以对数据进行更精细的操作,比如关系数据库在查询时可以指定列,并发控制可以达到行锁的粒度等。

  2.关系数据库的阻抗失衡问题

  表是把数据抽象成二维的:行,列

  编程语言是把数据成三维的:行,列,层次

  ORM可以解决这个问题

  3.关系型数据库的致命缺陷和nosql的登场

  a.关系型数据库不适应集群场景

  .nosql登场

  i)nosql数据库不使用sql

  但Cassandra的CQL和SQL很像(说明Cassandra提供对value的查询)

  ii)nosql不使用模式

  键值,文档,列族,通过名称可以知道,这些对value的抽象不同。

  键值完全不了解value的结构。

  文档和列族应该知道value结构?

  iii)nosql也可以是not only sql

  这样nosql不仅仅是一种技术,也是一场技术变革。

  《NoSQL精粹》读后感(三):滥用脚注的典范

  我说的是译者。

  窃以为适合用脚注的地方是:某些需要付出比较多的信息搜集成本的内容,比如需要在超链接之间跳转多次才能获取比较准确的信息,为避免读者重复过程,用脚注的方式给出解释或某种线索。或者是提供一些外人不易获得的内幕信息。

  然而本书译者却用脚注来做名词解释。给这种随手 wiki 随手 google 就能轻易找到答案东西做脚注除了浪费纸之外没一点卵用,更何况译者给出的解释大多也只是给出 wiki 链接而已

  名词1

  《NoSQL精粹》读后感(四):从数据库到NoSQL的一次思路整理

  之前断断续续看过不少NoSQL的资料,EMC颜开的算比较全的了。 但是都是很零散的介绍

  我自己而言,感觉缺少一个主线,最近翻了下《NoSQL精粹》,觉得可以借此整理下思路。

  1. 数据库为什么要算范式?

  细说起来太多。 范式解决了数据冗余,从而保证ACID的操作性能。

  不然一堆删除异常,插入异常,就没法愉快的写SQL了

  另外,对于多个业务公用的数据库,范式解决了集成的问题。

  2. 海量数据了,数据库对此做了哪些优化?

  a. 分表,横向划分+纵向划分 (mysql集群)。

  . share-disk 架构 (oracle的rac 集群),性能受到share里disk的限制.

  3. 但是还不够,问题的根本是什么?

  范式的限制太多,没有了数据冗余,那么每次操作就需要做关联。

  对分布式集群来说,关联的节点越多延迟越高,join等操作仍然需要将大表数据传输到小表机器上做计算。

  4. 对范式的吐槽不是一天两天了,业界整了个聚合的方式来替代关系元组。

  优点: 聚合更简单,更直接,更容易表达。(不需要join等关联操作, 就非常适合分布式集群)。

  缺点: 但是由于冗余,一次修改,需要对应到N个实体。(非常之不适合ACID)。

  :其实关系型数据库也是朝聚合方向做出了优化的,比如————>物化视图。

  5. 性能上去了, ACID就出问题了。

  很好理解:分布式的可用性--------->数据的复制和分片---------->数据冗余---------->数据不一致。

  比如:复制(3份)和分片(同机架不同机器一个备份, 不同机架再一个备份)。

  6. 其实ACID很做作,其实重点在于原子性,转化成如下的问题描述

  a. 写冲突

  1,中心节点模式下,多个写的怎么排序问题。

  2,无中心节点模式下,多个写并发的问题(仲裁问题)。

  . 读写冲突。

  c. 数据持久性。

  7. 解决方式:

  6.a.1 写排序问题(中心节点来决定排序,然后按顺序写多个副本)

  6.a.2 写并发的仲裁问题:

  写入仲裁: 写入成功的数目>复制因子的一半 即 W > N/2,这个好理解。

  读取仲裁:如果写N个副本,写W个算成功,就是允许N-W个失败。最坏的情况下, 你要

  读至少N-W+1个数据才可以。

  放宽条件就变成了:R + W >= N - W + 1 + W = N +1 > N ====== > R+W>N

  6.b 解决不了,让我们学会妥协。会话一致性,最终一致性。

  6.c 数据持久性(WAL方式)

  7. 好奇一下,为啥不能完全解决?

  通俗的说:数据量大了,就得上分布式集群,不然搞不定。

  可是,冗余导致一致性很差,不冗余吧,可用性和性能都上不去。

  学术地说就是CAP定理。原始的CAP定理里3选2的说法其实不好理解。

  实际上可以理解成: 系统会遭遇分区情况时,我们只能在可用性和一致性中间做权衡。

  思考可用性和一致性,不如思考一致性和延迟中如何取舍。

  :

  1.BASE比ACID更做作,基本可用和柔性状态也没有明确的定义

  2.并不是所有的NoSQL都是为分布式诞生的,图数据库采用的是传统数据库的方式。

  3.列族存储,可以当成是2级聚合来理解。

  4.可用性的理解:

  有中心节点的系统,当某个节点挂掉,仍然可以正常工作

  无中心节点的系统,当系统出现脑裂(brain split),系统仍然能工作

  《NoSQL精粹》读后感(五):很薄,很精辟,还需要自己深入和使用这些NOSQL DB才能理解

  感觉很多东西理解还是不够深入;但是老马在最开始基础原理上还是写得不错:比如一致性问题、持久化、复制、切片、集群模型 etc,但是对于具体时间和相关的NOSQL DB,老马也说了现在没有太多好的案例经验,对于每个NOSQL DB都有自己的特点,需要自己去使用和测试自己的关键Case;

  对于典型的NOSQL数据库分类有:

  1.键值数据库----可以尝试一下较火的redis

  2.文档型数据库----可以尝试一下较火的mongdb

  3.列族数据库----可以尝试一下较火的hbase

  4.图数据库

评价:

[匿名评论]登录注册

【读者发表的读后感】

查看NoSQL精粹读后感10篇的全部评论>>

评论加载中……