《NoSQL精粹》是一本由[美]Pramod J. Sadalage / [美]Marti著作，机械工业出版社出版的平装图书，本书定价：49.00元，页数：176，文章吧小编精心整理的一些读者的读后感，希望对大家能有帮助。
《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精粹》读后感(二)：从数据库到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精粹》读后感(三)：很全面 很精粹
这本书的作者是数据库重构的作者，可见对数据库的功力是可以的。
书中的精华是前面6章。
关系数据库被称为关系数据库，是因为关系太重要的。所有的数据库都避免不了。一种方式是关系分散到各个地方，通过外键关联，这个是普通关系数据库。一种是聚合关系，把关系放在一起，这种有kv数据库和文档数据库以及图数据库，列族数据库。
关系的聚合，可以理解为对象，对于面向对象的应用层来说是很用好的。
但是这些新的数据库都没有去完全实现多行事务。一个解决办法是尽量聚合在一起，这样保证单个对象的事务就可以了。
对于分布式数据库来说cap也是难以回避的。一般保证一致性的代价太高，会选择牺牲一点一致性，来提高一点可用性。在事务和读写效率做权衡的时候会用到仲裁，一般是超过半数通过就可以了。R+W>N,调整不同的r和w来做权衡。
分布式实现事务也一般会用到版本戳。
在分布式模型中接触最多的应该是分片和复制了。分别是纵向和横向的扩张。
复制可以降低压力，但是必然会存在延时，不管是主从复制还是对等复制。延时就会带来不一致。
非关系型数据库的分片有个优点，分片时候关联的数据还是在一起。如果是关系数据库没处理好的话，join的数据在不同的机器，那个就比较蛋疼了。
关系型数据库说白了是没有固定关系的，你可以通过不同的关联去产生不同的关系。这个是优点，但是要去关联，这个是个比较复杂的事情。nosql一般会存储的时候就把关系写在一起，对于应用程序来说是很方便的，但是应用程序需要多个关系的时候呢，这时候就比较麻烦了。所以nosql一般适用于简单的场景。
列族数据库我也是认为比较有意思的。他把多行看成一个整体，称为列族。他跟关心列本身，一般的数据库更关心行。他有kv数据库的优点，能通过key获取。有文档数据库的有点，他的列是可以扩展的。从面向对象的角度来看，可以理解为他更关心子对象的集合。他的一个核心优势是处理集合，而且处理的是子对象，粒度更细也更有效率。
《NoSQL精粹》读后感(四)：滥用脚注的典范
我说的是译者。
窃以为适合用脚注的地方是：某些需要付出比较多的信息搜集成本的内容，比如需要在超链接之间跳转多次才能获取比较准确的信息，为避免读者重复此过程，用脚注的方式给出解释或某种线索。或者是提供一些外人不易获得的内幕信息。
然而本书译者却用脚注来做名词解释。给这种随手 wiki 随手 google 就能轻易找到答案的东西做脚注除了浪费纸之外没一点卵用，更何况译者给出的解释大多也只是给出 wiki 链接而已
名词1
《NoSQL精粹》读后感(五)：很薄，很精辟，还需要自己深入和使用这些NOSQL DB才能理解
感觉很多东西理解还是不够深入；但是老马在最开始的基础原理上还是写得不错：比如一致性问题、持久化、复制、切片、集群模型 etc,但是对于具体的时间和相关的NOSQL DB，老马也说了现在没有太多好的案例和经验，对于每个NOSQL DB都有自己的特点，需要自己去使用和测试自己的关键Case;
对于典型的NOSQL数据库分类有：
1.键值数据库----可以尝试一下较火的redis
2.文档型数据库----可以尝试一下较火的mongdb
3.列族数据库----可以尝试一下较火的hbase
4.图数据库