《NoSQL精粹》章节试读

《NoSQL精粹》的笔记-第2章　聚合数据模型 - 第2章　聚合数据模型

聚合是作为交互单位的数据集合。数据库中的ACID操作以聚合为界。
如果数据交互大多在同一聚合内执行，则应使用面向聚合的数据库；若交互操作需要使用多种不同格式的数据，那么最好选用“聚合无知式数据库（关系型，图数据库）”
聚合的有用之处在于它可以把经常访问的数据放在一起。
面向聚合数据库获取数据时以聚合为单位，因此，它只能保证单一聚合内部内容的原子性。
如果待处理的数据中存在大量关系，那么这意味着你更应该选用关系型数据库，而不是NOSQL数据库。

《NoSQL精粹》的笔记-第2页 - 第一章——为什么使用NoSQL

第一节首先讨论了关系型数据库的价值，包括其近乎完美的数学模型、持久化、并发等等优势。接下来的三节分别讨论了关系型数据库与数据应用的“阻抗失谐”的问题、低成本信息交互情况下用“应用程序数据库”的概念取代关系型数据库所代表的“集成数据库”的趋势、以及集群的使用。这三点都是技术发展过程中关系型数据库统治地位动摇的因素，并由此提出了NoSQL的概念。当然NoSQL也无法有效解决好这三点，但通过对各种因素的权衡，可以有更多的选择，如混合持久化等等。

《NoSQL精粹》的笔记-第3章　数据模型详解 - 第3章　数据模型详解

使用面向聚合的数据库处理不同聚合之间的关系，要比处理统一聚合内部的关系更难。
图数据库将数据组织成一张由节点和边所组成的图，它们合适处理关系复杂的数据结构。
在无模式数据库中，可以给记录随意新增字段，然而用户在使用数据时，通常还是要遵循一套隐式模式。
面向聚合的数据库通常能够用不同方式重组主聚合的数据，以计算出各种“物化视图”。计算过程一般通过“映射简化”来实现。

《NoSQL精粹》的笔记-第26页 - 2

三种NoSQL
键值型
文档型
列族型
第三种不太好理解

《NoSQL精粹》的笔记-第7章　映射-化简 - 第7章　映射-化简

“映射-化简”是一种在集群上执行并发计算所用的模式。
“映射”任务从聚合中读出数据，将之缩减为相关键值对。“映射”操作每次只能读取一条记录，所以可在存放记录的节点上并发执行。
只有正对单个键的操作才具备“一致性”，因为这种操作只可能是“获得”，“设置”或“删除”。
Cassandra的写入操作在“行”级别是“原子的”（应该也可以推演到其他的列族数据库）。
假如某一列的获取次数比其他列更频繁，那么为了性能起见，应该将其值用作行健。
有些问题用列族数据库来解决并不是最佳选择，例如需要以“ACID事务”执行写入及读取操作的系统。

《NoSQL精粹》的笔记-第14页

各种 NoSQL 数据库的共同特征是：
• 不使用关系模型（也不使用 SQL 语言）
• 在集群中运行良好
• 开源
• 适用于 21 世纪的互联网公司
• 无模式

《NoSQL精粹》的笔记-第30页

图数据库与面向聚合数据库的明显差异，就在于其重视数据间的“关系”。这种数据模型上的差异也导致了其他方面的一些区别：图数据库通常运行在单一的服务器上，而不是分布于集群中；为了使数据保持一致，ACID 事务需要涵盖多个节点与边。
它和面向聚合数据库仅有的相似之处在于，二者都不使用关系模型，而且它们受关注的时间点也和 NoSQL 领域中的其他新技术大致一样。

《NoSQL精粹》的笔记-第21页

对某些数据交互有用的聚合结构，可能会阻碍另一些数据交互。若是采用“聚合无知模型”，那么很容易就能以不同方式来查看数据，因此，在操作数据时，如果没有一种占主导地位的结构，那么选用此模型效果会更好。

《NoSQL精粹》的笔记-第4章　分布式模型 - 第4章　分布式模型

宽泛地说，数据分布有两条路径：复制（replication）与分片（sharding）。“复制”就是将同一份数据拷贝至多个节点；而“分片”则是将不同数据存放在不同节点中。复制与分片是两项“正交的”技术：即可以在两者中选一个来用，也可以同时使用它们。“复制”有两种形式：“主从式”和“对等式”。

《NoSQL精粹》的笔记-第二章 - 第二章

键值，文档，列族数据库都使用聚合这一概念（面向聚合的数据库），而且聚合中都有一个可以查找其内容的索引键。在集群上运行时，聚合是中心环节，因为数据库必须保证将聚合内的数据存放在同一个节点上。聚合还是“更新”操作的最小数据单位，对事务控制来说，以聚合为操作单元，其大小正合适。

《NoSQL精粹》的笔记-第40页

宽泛地说，数据分布有两条路径：复制（replication）和分片（sharding）。“复制”就是将同一份数据拷贝至多个节点；而“分片”则是将不同数据存放在不同节点中。复制与分片是两项“正交的”（喻指多个因素互不干扰，可分别对待）技术：既可以在两者中选用一个，也可以同时使用它们。

《NoSQL精粹》的笔记-第15页 - 第二章——聚合数据模型

本章主要介绍了聚合数据模型的概念。在传统关系型数据库中，数据模型通常利用关系和元组来表示，这种模型具有很强的数据组织能力，也因此得到了广泛的应用。但随着技术的进一步发展，对领域数据的使用呈现聚合的特点（即经常多种数据同时写入或读取），这是NoSQL出现的一个必要因素。当然非聚合数据模型仍然有其用武之地，因为“聚合无知模型”可以很容易从多个方式来查看数据，这是其一大优势（适合于前文提到的集成数据库）。
本章列举了键值数据模型、文档数据模型以及列族数据模型这三种常见的聚合数据模型，它们的结构由松垮到相对严谨呈现出聚合数据模型向关系数据模型的渐变，开发人员可以根据对数据结构的严格程度选择自己需要的数据库。

《NoSQL精粹》的笔记-第4章　分布式模型 - 第4章　分布式模型

将不同的数据分片存放在多个服务器中，每一个数据子集都专门由一台服务器负责。
将数据复制到多个服务器上，没份数据都能在多个节点中找到。
“主从复制”：将其中一个节点当做权威数据源，并负责写入操作；其他从节点都要好主节点保持同步，它们可以负责读取操作。
“对等复制”：任何节点均可写入，节点间相互协调以同步其数据。
“主从复制”：减少了更新数据时的冲突几率，但它却会让主节点成为写入操作的瓶颈，而“对等复制”则避免了这一点。

《NoSQL精粹》的笔记-第49页 - 第五章——一致性

只要存在数据共用的情况，数据一致性的问题就无法回避。关系型数据库试图通过”强一致性“来避免各种不一致问题。应用NoSQL的集群环境保证”强一致性“的代价太高，因此引入了一系列的方案减少数据不一致带来的问题，如CAP定理、最终一致性等等。
一致性包含写入一致性（顺序一致性等）和读取一致性（逻辑一致性、复制一致性等）。两者都有解决方案，不过这些解决方案是以高开销为基础的，因此还需开发人员自己权衡。对于复制一致性，NoSQL通常会保证“最终一致性”，也就是说，在任意时刻，节点中都可能存在“复制不一致”问题，然而只要不再继续执行其他更新操作，那么上一次更新操作的结果最终将会反映到全部节点中去。 有些场景下对一致性的要求没有那么高，因此可以放宽“一致性”的约束，并由此提出了CAP定理：给定“一致性”、“可用性”、“分区耐受性”这三个属性，我们只能同时满足其中两个属性。该定理在集群环境中有较大意义，它说明如果满足分区耐受性，则需要在一致性和可用性之间进行权衡。
某些场合为了提高系统的性能，可以牺牲一些“持久化”以换取更好的性能。（这很好理解，不再赘述）
最后一节讨论了“仲裁”方案，该方案利用多节点操作提升了系统的一致性，包括写入仲裁：W>N/2和读取仲裁：R+W>N（R读取节点数，W写入节点数，N是复制因子）。这两个公式在集群环境下有较好的一致性方案，而且存在较大的权衡空间，因此很多集群系统都使用了这种方案。

《NoSQL精粹》的笔记-第22页

键值数据库和文档数据库：两者主要是通过聚合来构建的。
两种模型的区别：键值数据库的聚合不透明，只包含一些没有太多意义的大块信息；与此相反，在文档数据库的聚合中，可以看到其结构。不透明的优势在于，聚合可以存储任意数据。数据库可能会限制聚合的总大小，但除此之外，其他方面都很随意。文档数据库则要限制其中存放的内容，它定义了其允许的结构与数据类型，而这样做的好处是，能够更加灵活地访问数据。
在键值数据库中，要访问聚合内容，只能通过键来查找。而使用文档数据库时，则可以用聚合中的字段查询。可以只获取一部分聚合，而不获取全部内容，此外，数据库还可以按照聚合内容创建索引。
在键值数据库中，基本上都是通过键来搜索聚合内容，而在文档数据库中，我们提交的查询关键词往往基于文档的内部结构，它也许是键，但是更有可能是其他东西。

《NoSQL精粹》的笔记-第二部分　实 现 - 第二部分　实 现

ORM是一种不严谨的抽象（leaky abstraction）总有一些需要更加留意的情况，尤其是像获得较为理想的性能时。
图数据库提供了另一种简化方案，关系型数据库不善于处理关系较多的数据。而图数据库既提供了更自然的API以存储这种数据，又能够查询此类数据结构。
通过使用更符合应用程序需求的数据库来改善程序员的工作效率。
以能处理大量数据，降低延迟且增进数据吞吐量的某种技术组合来改善数据访问性能。
用服务来封装数据库，既能在需求变更或技术成熟后改换其所封装的数据库技术。可将应用程序各部分划归到不同服务中，以便为既有程序引入NOSQL数据库。

《NoSQL精粹》的笔记-第153页

reading finished @ yarkant

《NoSQL精粹》的笔记-第21页

经常会听人说：NoSQL 数据库不支持 ACID 事务，因而其一致性会受损。这一论述简化得有些过头了。通常情况下，面向聚合的数据库确实不支持跨越多个聚合的 ACID 事务。取而代之的是，它每次只能在一个聚合结构上执行原子操作。也就是说，如果我们想以原子方式操作多个聚合，那么就必须自己组织程序的代码。在实际应用中，大多数原子操作都可以局限于某个聚合结构内部，而且，在将数据划分为聚合时，这也是要考虑的因素之一。

《NoSQL精粹》的笔记-3.4　物化视图 - 3.4　物化视图

“物化视图”是一种预先算好并缓存在磁盘中的视图。

《NoSQL精粹》的笔记-第13页

选用 NoSQL 的两个主要原因：一是待处理的数据量很大，或对数据访问的效率要求很高，从而必须将数据放在集群上；二是想采用一种更为方便的数据交互方式来提高应用程序开发效率。

《NoSQL精粹》的笔记-第5章　一致性 - 第5章　一致性

最常见的“悲观方式”就是采用“写入锁”（write lock），这样的话，在修改某个值之前，必须先获取“写入锁”，系统确保某一时刻只有一个客户能够获得这把锁。
“乐观方式”通常采用“条件更新”（conditional update），也就是任意客户在执行更新操作之前，都要先测试数据的当前值和其上一次读入的值是否相同。
因此，这种情况通常叫做“最终一致性”（eventually consistency），也就是说，在任意时刻，节点中都可能存在“复制不一致”（replication inconsistency）问题。然而只要不再继续执行其他更新操作，那么上一次更新操作的结果最终将会反映到全部节点中去。
CAP原理的基本表述是：给定“一致性”（consistency）,"可用性"（availability），“分区耐受性”（partition tolerance）这三个属性，我们只能同时满足其中两个属性。
这样产生的系统，既不具备完美的“一致性”，也不具备完美的“可用性”，但是，这两种不完美的特性结合起来，却能够满足特定需求。
尽管大多数软件开发者都将“更新一致性”看成一件天经地义的事情，但是，在某些情况下，就算不同的客户请求所得到的相应内容不一致，我们依然可以优雅地完成任务。
NOSQL的倡导者经常说，与关系型数据库所支持的ACID事务不同，NOSQL系统具备“BASE属性”（基本可用，柔性状态，最终一致性，Basically Available，Soft state，Eventual consistency）。
如果一个节点处理完更新操作之后，在更新数据尚未复制到其他节点之前，就出错了，那么则会发生“复制持久性”（replication durability）故障。
处理请求所用的节点越多，避免“不一致”问题的能力就越强。
在“一致性”与“可用性”的权衡问题上，存在很多选项，需要根据每一种方案的优缺点来选出一种合适自己的办法。
当两个客户试图同时修改一份数据时，会发生“写入冲突”。而当某客户端在另一个客户端执行写入操作的过程中读取数据时，则会发生“读写冲突”。
悲观方式以锁定数据记录来避免冲突，而乐观方式则在事后检测冲突并将其修复。
在分布式系统中，如果某些节点收到了更新数据，而另外一些节点却尚未收到，那么这种情况就视为“读写冲突”。若写入操作已经传播至所有节点，则此刻的数据库就具备“最终一致性”。
想取得较好的“一致性”，就要用许多节点来执行数据操作，而这又会增大延迟。所以说，经常需要在“一致性”与延迟之间权衡。
“CAP定理”宣称，当有可能发生“网络分区”现象时，必须在数据的“可用性”与“一致性”之间权衡。
可以舍弃一部分“持久性”以减小延迟，如果想让数据库在复制数据出错的情况下依然可用，那么更应该考虑这种权衡方式。
在采用“复制”技术的分布式模型中执行数据操作时，无需联系所有副本，只要为足够多的副本所认可，就能保持“强一致性”。

《NoSQL精粹》的笔记-第27页 - 第三章——数据模型详解

本章继第二章对聚合数据模型的描述，进一步讨论了常用的数据模型。
关系模型是数据组织所必需的，聚合数据模型也不例外，但由于无法提供多个聚合数据的事务机制（开销太大），聚合数据模型在操作聚合关系时会很困难（这也是选择NoSQL数据库和关系型数据库的一个评判标准）。
当然，如果待处理的数据中存在大量关系，那么关系型数据库也无法很好应对这一问题（复杂的SQL语句和很低查询效率）。因此应运而生另一类NoSQL数据——图数据库，这种数据库并不面向聚合，也不太适用于集群，它是为了解决关系型数据库前面所述缺点而设计的。图数据库通过带属性的节点和边将密集的关系组织起来，舍弃表结构和JOIN操作，可以大大提高关系查询的效率（当然复杂的组织结构也会带来写入效率的降低）。图数据库相对其他NoSQL数据库的一个好处是它在数据库层面上支持传统的事务机制。
相比关系型数据的强模式，NoSQL数据库的无模式或自由模式得到部分开发人员的推崇。然而数据库的无模式不代表整个应用的无模式，因为数据最终还是需要被读取，这种数据模式就是一种“隐含模式”，将由应用程序来保证。“隐含模式”也会带来一系列的问题，数据模式将于应用程序耦合、数据库也无法帮助开发人员校验数据等等。个人认为虽然NoSQL的无模式是很好的想法，带来了数据保存上的自由，但由应用程序来控制其结构不得不说是一种冒险。
本章的最后讨论了两种有关NoSQL效率的问题。一是NoSQL的物化视图的机制，对比关系型数据库的视图，两者都是为高效展示数据的一种方法，鉴于读取NoSQL聚合数据关系的巨大开销，物化视图不失是一种较好的方法。第二个是关于数据存取模型的思考，不同的聚合方式对于数据的操作有巨大的影响，在开发使用前需要深思熟虑。

《NoSQL精粹》的笔记-第21页

ACID 事务：原子性（Atomic）、一致性（Consistent）、隔离性（Isolated）、持久性（Durable）。
其实真正重点是原子性：在单一操作中更新跨越多张表的数个行。

《NoSQL精粹》的笔记-第13页 - 第一章

NoSQL渐渐进入人们视野的原因：
1.阻抗失谐
2.大数据所需要的特性。
集成型数据库到应用程序数据库的转化

《NoSQL精粹》的笔记-第40页 - 第四章——分布式模型

催生NoSQL的主要原因是：我们需要一种能够运行在大集群上的数据库。不同的分布式模型能够带来不同的优势，总的来说可以分为两种互不干扰的方式：复制和分片。
虽说NoSQL是为集群运行环境设计的，但将它运行在单一服务器上是没有任何问题的。而且在应用需求没有那么大的时候，单一服务器是更加简单有效的方式。
聚合数据相比关系型数据更加有利于分片，而分片可以有效的缓解数据库的读写压力，不同的数据将由不同的分片分别写入和读取，从而大大提高数据库的性能。然而它也降低了数据库容错的能力，当分片节点出现宕机将造成整个集群数据的不可信。这两方面是最直观的分片结果，需要开发人员自己的权衡。
复制是把数据复制到多个节点上，这样既提高了数据库的读取性能，也增强了集群的容错能力。复制包含两种方式：主从式复制和对等式复制。对于主从式复制，主节点重点负责写入，而从节点负责读取分流，但这样的系统存在主节点瓶颈的问题，还有更严重的数据一致性问题（下一章将讨论数据一致性问题）。对于对等式复制，它抛开了主节点的瓶颈问题，但却造成了更严重的数据一致性问题。而且复制还有与生俱来的问题就是写入性能的问题。
因此将分片和复制技术合并，争取增强集群容错能力的同时提高数据写入能力，但这种混合技术会造成更加严重的数据一致性问题，具体的解决方案将在下一章讨论。

《NoSQL精粹》的笔记-第二章 - 第二章

在实际应用中，大多数原子操作都可以局限于某个聚合结构内部

《NoSQL精粹》的笔记-第20页

NoSQL 数据库的建模：
对于如何划分聚合边界并没有标准答案，这完全取决于你打算怎么来操作数据。

《NoSQL精粹》的笔记-第21页

《NoSQL精粹》的笔记-第3章　数据模型详解 - 第3章　数据模型详解

不管数据库“无模式”到何种地步，总会存在“隐含模式”。它是指在编写数据操作代码时，对数据结构所做的一系列假设。
无模式数据库感知不到模式，所以它无法用模式来提升存储与获取数据的效率，它也无法自行验证数据，以防止多个应用程序以不一致的方式操作其数据。

《NoSQL精粹》的笔记-第6章　版本戳 - 第6章　版本戳

在分布式系统中，可以采用“由版本戳构成的数组”（a vector of version stamps）来检测不同节点之间是否发生了“相互冲突的更新操作”（confliction update）。