《NoSQL精粹》读书笔记

NoSQL数据库数据模型的通常分类：

1. 键值数据模型
2. 文档数据模型
3. 列族数据模型
4. 图数据模型

常见NoSQL数据库：

Redis, Cassandra, MongoDB, Neo4J, Riak...

数据库应用趋势：

1. 因为数据量愈来愈大，大型系统的扩展方式由数据库在单一计算机上的纵向扩展->在计算机集群中的横向扩展

2. 混合持久化(关系型数据库 + NoSQL数据库)

 

第一部分

第1章 为何使用NoSQL

* 关系型数据库和应用程序之间的“阻抗不匹配”。关系模型和应用程序程序中内存数据结构的不一致致使这种情况，所以涌现出不少对象-关系映射(ORM)框架，但滥用ORM可能会致使性能问题。

* “集成数据库”和“应用程序数据库”，前者是一种多应用程序分享使用同一数据库的方式，特色是全部应用程序均可以得到本身想要的东西，但因为要兼容全部应用程序，所以数据库的设计可能会过度复杂致使很差维护，而且也须要应对系型数据库和应用程序之间的“阻抗不匹配”。后者衍生除了web服务，应用程序之间以接口的方式进行交互，一般使用XML或JSON来交换数据，此时就可使用结构丰富的数据格式(数组、嵌套结构等)了。

* web服务常用传输文本信息的HTTP协议，对一些性能要求较高的状况，可使用二进制协议。

* 关系型数据库和计算机集群的格格不入。关系型数据库能把数据划分为几个集合，分别部署在各自独立的服务器上运行，这能够有效地对数据库分片。但这么作也有缺点，应用程序必须控制全部分片，它要知道数据库中的每份小数据存放在哪里才行。并且，查询、参照完整性、事务、一致性控制等操做也没法再跨分片的环境下执行。

* 在集群中使用关系型数据库有可能遇到成本的问题(商用关系型数据库通常按服务器台数计费)。

* 出现了以谷歌和亚马逊为首的典型计算机集群用户，为此谷歌研发了BigTable，亚马逊则是Dynamo。

* 混合持久化须要把集成数据库迁移到应用程序数据库上，通常来讲，应用程序数据库均可以采用NoSQL数据库，但集成数据库不适合使用NoSQL数据库。企业能够考虑把原来存放在集成数据库中的数据转移到各个应用程序数据库，而后使用web服务来链接这些系统。这既下降了应用之间的耦合度，也下降了成本和维护难度。

* 选用NoSQL数据库的两个主要缘由：

1. 待处理的数据量很大，对数据访问的效率要求很高，从而必须把数据放在集群上。
2. 但愿采用一种更为方便的数据交互方式来提升应用程序的开发效率。

* NoSQL的特征：

1. 不使用关系模型
2. 在集群中运行良好
3. 开源
4. 适用于21世纪的互联网公司
5. 无模式

第2章 聚合数据模型

* 聚合结构能够把关联数据直接嵌入在某个聚合中，从而方便查找。聚合使数据库在集群上管理数据存储更为方便。

* 对某些数据交互有用的聚合结构，可能会阻碍另外一些数据交互。在对数据建模时，须要考虑到哪一种场景占主导地位，据此来设计数据聚合的方式。

* 选用面向聚合模型的决定性因素，就是它很适合在集群上运行。咱们须要把采集数据时所需的节点数将至最小。若是在数据库中明确包含聚合结构，那么数据库就知道这些数据就会被一块儿操做，并放在同一节点中。

* 一般状况下，面向聚合的数据库不支持跨越多个聚合的ACID事务。聚合是做为交互单元的数据集合，数据库中的ACID操做以聚合为界。

* 键值数据库、文档数据库、列族数据库都属于面向聚合的数据库。

* 若是数据交互大都在同一聚合内执行，则应使用面向聚合的数据库；若是数据交互操做须要使用多种不一样格式的数据，那么最好选用“聚合无知式数据库”。

 

第3章 数据模型详解

图数据库

* 常见的图数据库有：FlockDB, Neo4J, Infinite Graph。

* 图数据库对于处理复杂关系的场景较为理想，例如社交网络、产品偏好、资格认定规则等包含复杂关系的数据。

* 对关系型数据库来讲，操做内部相互关系比较紧密的数据模型一般须要使用不少JOIN语句，效率也较差。使用图数据库遍历关系，则很是迅速。主要缘由是因为图数据库会多花一些时间用于插入关系数据，以此来缩短遍历关系时所需的时间。在一些查询效率高于插入效率的场合，这种权衡很是重要。

* 图数据库使用边和节点来存储数据，使用图数据库时，大部分时候都是在浏览各类关系。

* 图数据库和面向聚合的数据库的明显差异，在于图数据库重视数据间的“关系”，这种数据模型上的差别也致使了其余一些区别。图数据库通常运行在单一服务器上而非集群中。为了使数据保持一致，ACID事务须要涵盖多个节点与边。类似之处是，它们都不适用关系模型。

无模式数据库

* 各类形式的NoSQL都有一个特性，就是它们都是无模式的。在关系型数据库中，咱们首先要定义好模式，就是用一种预约义结构向数据库说明，有哪些表，表中有哪些列，每列存放什么类型的数据，必须先定义好模式，才能使用数据库。相反，无模式数据库就显得至关随意了，能够在一个键下存听任意数据。

* 无模式数据库没有关系型数据库的那么多限制，可是它自己也存在一些问题，无论数据库无模式到什么程度，它都存在“隐含模式”，它是指在编写数据操做代码时，对数据结构所作的一系列假设。虽然咱们能够在无模式数据库中以合法名称的键值存放数据，可是这也就假定了程序须要知道这些字段，除非咱们只是无脑地遍历数据结构依次打印键值对，然而这基本没有什么意义。

* 应用程序代码中的隐含模式也会带来一些问题，它意味着要想理解数据库中的数据，必须深刻研究应用程序的代码才行，若是代码很清晰易懂，那么你能够根据它推断出数据的模式，然而这一点却没法保证，由于这彻底取决于你的代码是否清晰。举个简单的例子，某个字段，在一些聚合中保存为字符串，在另外一些聚合中保存为对象(由于数据库是无模式的，理论上彻底可能出现这种状况)，若是你不知晓代码的逻辑，基本没法判断出这个字段的这两种数据类型究竟有什么区别。并且，因为数据库感知不到模式，也就没法自行验证数据，这就少了一道保障。不一样应用程序可能也会以彻底不一样的方式使用某个字段。固然了，在验证数据方面，咱们还必须在全部使用这个数据库的应用程序中都加上彻底相同的验证逻辑来确保数据正确性和安全性。

* 从本质上说，无模式数据库是把模式交由访问其数据的应用程序代码来处理，若是有多个应用程序须要访问同一个数据库，可能会出现问题。一种缓解此问题的方法是把数据互动操做封装成独立的应用程序，并经过web服务的形式将它和其余应用程序集成。另外一种方法是在聚合中明确划分出不一样应用程序的区域。

物化视图

* 关系型数据库能够利用视图来展现一些须要复杂计算才能给出的数据，视图就比如一张关系表，只不过它是经过基表计算得来的，在访问视图时，数据库会计算出视图中的数据，这种形式的封装很方便。有了视图这种机制，客户端不须要担忧它访问到的是基本数据仍是派生数据，不过生成视图须要大量计算，比较消耗性能。

* 物化视图是一种事先计算好并缓存起来的视图，若是数据读取频繁，且对实时性要求不高的话，可使用物化视图来优化性能。在NoSQL中，能够利用物化视图来处理这种需求。面向聚合的数据库更强调这个问题，由于大多数应用程序都要处理某种与聚合机构不相符的查询操做。

* 构建物化视图有两种方法，第一种是在每次基础数据变动的时候都去更新物化视图，若是读取物化视图的次数远比写入的多，且想得到更为实时的数据，那么这种方法比较合适。第二种是经过批处理来定时更新物化视图，这须要根据业务需求来制定方案，须要考察业务能容忍过期多久的数据。

* 面向聚合的数据库一般可以用不一样方式重组主聚合的数据，以计算出各类物化视图，计算过程通常使用map-reduce的方式。

构建数据存储模型

* 使用列族数据库建模时，应该按照查询需求而不是写入需求来处理。建模的通则是要便于查询，并且在写入数据时要对其执行“反规范化”操做。

 

第4章 分布式模型

* 面向聚合数据库很是适合于横向扩展方式，由于聚合此时就天然成了数据分布单元。

* 数据分布有两条途径：

1. 复制
2. 分片

* 复制，就是将同一份数据拷贝至多个节点。分片，就是将不一样数据存放在不一样节点中。复制和分片是两项正交的技术，它们既能够选其一使用，也能够结合使用。

单一服务器

* 在大多数状况下，最简单的分布形式就是没有分布，采用单一服务器的形式，特色是简单。

分片

* 分片是把数据的各个部分放在不一样的服务器(节点)中，以此实现横向扩展。分片技术能有效实现负载均衡。为了最大程度地利用分片技术，咱们必须保证须要同时访问的数据都存放在同一个节点上，而且节点必须排布好这些数据块，使访问速度最优。这些措施包括，使服务器服务于地理位置上较近的用户、最大程度实现负载均衡，某些状况下能够把须要依次读取的聚合放在一块儿。

* 常常有人经过应用程序来处理分片，好比把用户姓氏首字母按照A-D，E-G之类的方式存放在不一样分片中，但这样作就把编程模型复杂化了，由于应用程序须要把查询操做分布到多个分片上。若是想调整分片，就须要修改应用程序的相关逻辑并迁移数据。不少NoSQL数据库都提供了“自动分片”来让数据库本身负责把数据分布到各分片，并将查询请求路由至适当分片中。

* 单一使用分片技术在应对数据库故障时比较力不从心，一旦某个节点崩溃，则该分片上的数据就不可访问，虽然说可能只是其中一个分片出问题，但比较已经没法对外提供完整的服务了。后面会看到采用分片结合复制的技术构造冗余能够缓解此问题。

主从复制

* 在主从复制中，有一个节点叫节点，其他的叫从节点。主节点存放权威数据，复制操做就是要让从节点和主节点的数据保持同步。

* 主节点负责处理数据的读写，从节点只负责数据读。这样只要增长从节点就能够实现横向扩展。

* 能够采用手动指定主节点和自动选择主节点两种模式，手动指定须要咱们本身配置集群，自动选择比较简单，会让它们自动选举出主节点，若是以后这个主节点崩溃了，会自动指派新的主节点，减小故障时间，手动指定则无此福利。

* 主从复制有助于加强读取操做的故障恢复能力。

* 主从复制对于写入操做很是频繁的场合，虽然能将读取操做分流，稍稍缓解主节点写入数据的压力，但对写入操做的性能并无什么显著的提高。

* 复制技术再带来好处的同时也有一个致命弱点，就是数据的不一致。若是主节点更新了一个数据，但还未通知从节点，那么用户从从节点读出的数据就不是最新的，甚至因为各从节点同步速度的快慢数据仍是各异的。更极端的状况是，主节点崩溃了，此时有部分数据还没有同步到从节点，这部分数据就会丢失。

* 主节点仍然是系统的瓶颈和弱点。

对等复制

* 对等复制中的全部节点都是平等的，不存在主从节点一说，全部节点均可以接受读写请求，节点会将自身的写入操做通知给其余全部节点。

* 增长节点能够轻易提高性能。

* 对等复制也存在数据一致性问题，因为两个不一样节点能够同时处理写入操做，因此可能出现两位用户同时对同一条记录的状况，这就致使“写入冲突”。数据读取的不一致性也存在，但持续时间相对较短，由于最终都会归于一致，写入不一致却老是存在。

* 写入不一致的几种解决方案思路：

1. 无论什么时候写入数据，各副本之间总能相互协调，确保不发生冲突，这须要花费必定的网络流量来协调写入操做。
2. 设法处理这些不一致的写入操做，好比合并这些操做。

结合分片和复制技术

* 每一个系统有多个主节点，但对于每项数据来讲，负责它的主节点又只有一个。根据配置的须要，同一个节点既能够做为某些数据的主节点，也能够充当其余数据的从节点，也能够指派全职的主节点和从节点。

 

第5章 一致性

* 面向集群的NoSQL数据库须要面对一致性的问题，关系型数据库试图经过“强一致性”来避免各类不一致问题，在NoSQL领域中，须要咱们本身思考系统须要何种一致性。

更新一致性

* 多个请求同时更新同一条数据会产生写冲突问题，在并发环境下维护数据一致性通常有两种方式：悲观方式和乐观方式。

1. 悲观方式，就是要避免冲突。常见作法是使用写入锁，确保同一时间只有一个请求能够获取该锁。但注意可能致使死锁问题。
2. 乐观方式，就是容许冲突发生，而后检测冲突并对发生冲突的操做排序，再进一步处理。一般使用“条件更新”，就是任意用户在执行更新操做前，都要先检测数据的当前值和上一次读入的是否相同。若是相同，就更新，若是不一样，则更新失败，此时须要先更新到最新在作更新。可参考git等分布式版本管理系统处理冲突的方式。

* 悲观和乐观的方式，都有一个先决条件，就是更新顺序必须一致，这在单机环境下显然成立，但在分布式集群下，可能两个节点会以不一样的顺序执行操做，最终数据就会不一致。

* 在分布式系统的并发问题上，须要有“顺序一致性”，就是全部节点都要保证以相同的次序执行操做。

读取一致性

* 数据库必须具备更新一致性，但就这样还不够，它未必能保证用户所提交的访问请求老是能获得一致的响应。典型场景是一个用户A的一个更新动做须要顺序操做两张表的数据，若是是面向聚合的数据库则此处没法使用ACID事务，所以是依次更新。若是在更新完第一张表但还未更新第二张表时，用户B访问了第二张表的那条数据，就会看到一个不一致的数据。这种一致性叫“逻辑一致性”。

* 并非全部NoSQL数据库都不支持ACID事务，只有面向聚合的数据库不支持，图数据库是支持ACID事务的。

* 面向聚合数据库能够“原子地”更新一个聚合的数据，但仅限于单一聚合内部。因此说，“逻辑一致性”能够在某个聚合内部保持，但各聚合之间则不行。在多个聚合之间更新数据就存在一个时间空档，在此空档内读出的相关数据不知足“逻辑一致性”，这个空档叫“不一致窗口”。NoSQL系统的“不一致窗口”通常很短暂。

* 在引入复制的场景下，就会遭遇一种全新的不一致问题，叫“复制不一致”。若是有多个节点，在个节点上更新了数据，在全部节点还没有所有同步数据前，就会有部分用户访问到过时的数据。但最终，更新仍是会传播到全部节点上，这叫“最终一致性”。

* “复制一致性”和“逻辑一致性”虽然说是两个独立的问题，不过若是“复制”过程当中的“不一致窗口”太长，就会加重“逻辑不一致”问题。两个时间间隔很短且内容不一样的更新操做，在主节点中留下的“不一致窗口”也就几毫秒而已，但因为网络延迟，这个“不一致窗口”在从节点上会比在主节点上长得多。

* “会话一致性”是指在用户会话内部保持“照原样读出所写内容的一致性”。要确保“会话一致性”，其中一种方法是使用“粘性会话”，就是把会话绑定到某个固定的节点，但缺点是会下降负载均衡器的效率。另外一种方法是使用“版本戳”，这个以后会详述。

放宽“一致性”约束

* 一致性很重要，不过有时必须舍弃它。在设计系统时，咱们常常须要牺牲一致性来换取其余特性。

* 关系型数据库通常用事务来增强一致性，可是事务会影响系统性能。

* CAP定理，其中CAP的意思是

1. 一致性(Consistency)，具体含义以前说过。
2. 可用性(Availability)，这里能够指响应的效率，或者说延时。
3. 分区耐受性(Partition tolerance)，若是发生通讯故障，致使整个集群被分割成多个没法通讯的分区时(也叫脑裂)，集群仍然可用。

CAP定理所表述的是，给定一致性、可用性和分区耐受性这三个属性，咱们只能同时知足其中两个属性。

放宽“持久性”约束

* 某些数据能够不持久化或延迟持久化，好比用户session或者一些临时数据能够保存在redis中，生成和更新很是频繁但又不是那么重要的数据能够延迟持久化，好比定时持久化写入。

* 是否放宽“持久化”约束须要根据具体需求来肯定。

仲裁

* 假设某份数据须要复制到3个节点中，为了保证"强一致性"，不须要全部节点都确认写入操做，只需其中两个节点(超过半数)确认便可。就是说若是发生两个发生冲突的写入操做，那么只有其中一个操做能为超过半数的节点所承认(W>N/2)。这就叫写入仲裁。

* 读取仲裁，是指想要读取保证可以读到最新的数据，必须联系多少个节点才行。

* 在采用“复制”技术的分布式模型中执行数据操做时，无需联系全部副本，只要为足够多的副本所承认，就能保持“强一致性”了。

* 执行读取操做时所需联系的节点数(R)、确认写入操做时须要联系的节点数(W)和复制因子(N)之间能够用一个不等式来表达：R+W>N。

 

第6章 版本戳

* 版本戳用户标识数据的版本，典型状况是使用计数器版本戳，若是当前数据库中某条数据的版本戳是3，而用户请求更新的数据版本戳是2，说明在用户上一次读取到更新之间，该条数据发生了一次更新，多是有其余人在此时更新了数据，因此这个用户的更新会失败。

* 版本戳通常可使用计数器、GUID、内容哈希值、上一次更新的时间戳来表示，这几种方案各有优劣。也能够结合起来使用，好比CouchDB的版本戳就结合使用了内容哈希和计数器。

* 除了能够避免“更新冲突”以外，版本戳也有助于维护“会话一致性”。

* 在分布式环境中，可使用“由版本戳构成的数组”，来检测不一样节点之间是否发生了“相互冲突的更新操做”。

 

第7章 Map-reduce(映射-化简)

* 映射-化简是一种在集群上执行并发计算所用的模式。

* 映射操做从聚合中读出数据，将之缩减为相关键值对。映射操做每次只能读取一条记录，因此可在存放记录的节点上并发执行。

* 映射任务会生成不少具有同一关键字的值，而化简任务则将它们化简为单一的输出值。每一个化简函数只操做与单个键相关的映射结果，因此多个化简函数能够根据关键字执行并发化简。

* 输入数据与输出数据形式相同的多个“化简函数”可归并为“管道”，以提升并发执行能力，并减小所需传输的数据量。

* 若某个“化简输出”的结果是下一个“映射操做”的输入，那么能够用“管道”组合映射-化简操做。

* 若是须要普遍使用映射-化简的计算结果，那么能够将其存储为“物化视图”。

* 可以使用增量式映射-化简操做来更新“物化视图”，这样作只须要计算视图中发生改变的那部分数据便可，无需把所有数据从头算一遍。

 

第8章 键值数据库

键值数据库和关系型数据库的对比

Oracle	Raik
数据库实例	Raik集群
表	存储区
行	键值对
rowid	键

 

什么是“键值数据库”

* 从API的角度来看，键值数据库是最简单的NoSQL数据库。客户端能够根据键查询值，设置键所对应的值。

* Redis等键值数据库中，所存储的数据不必定非要是领域对象，任何数据结构都行。Redis能够存储list、set、hash等数据结构，还能够求差集、并集、交集和获取某个范围内的数值。

键值数据库特性

* 一致性，只有针对单个键的操做才具有一致性，通常就是set、get或del。

* 事务，不一样键值数据库其事务规范不一样，通常没法保证写入一致性。好比Raik采用仲裁。

* 查询功能，全部键值数据库均可以按照关键字来查询，但没法根据列值来查询。

* 数据结构，键值数据库通常不关心值，值能够是二进制、文本、JSON等。

* 可扩展性，不少键值数据库均可以采用分片技术。采用这种技术后，键的名字决定了负责存储该键的节点。像Raik这样的数据库，能够控制“CAP”定理中的参数，N(存放键值对的副本节点数)、R(顺利完成读取操做所需的最小节点数)和W(顺利完成写入操做所需的最小节点数)。

适用案例

* 存放会话信息

* 用户配置信息

* 购物车数据

不适用场合

* 数据间关系

* 含有多项操做的事务

* 查询数据

* 操做关键字集合

 

第9章 文档数据库

文档数据库和关系型数据库的对比

Oracle	MongoDB
数据库实例	MongoDB实例
模式	数据库
表	集合
行	文档
rowid	_id
join	DBRef

 

特性

* 一致性，为了在MongoDB数据库中确保一致性，能够配置副本集，也能够规定写入操做必须等待所写数据复制到所有或是给定数量的从节点后，才能返回。提高一致性会下降写入效率。能够配置以增长副本集的读取效率。

* 事务，只支持单文档级别的事务，即原子事务。

* 可用性，文档数据库试图用主从式数据复制技术来加强可用性。多个节点保有同一份数据，即便主节点故障，客户端也依然能够获取数据，应用程序通常不须要检测主节点是否可用。全部请求都由主节点处理，而其数据会复制到从节点。若是主节点故障，副本集中剩余的节点会在其自身范围内选举出新的主节点。副本集一般用于处理数据冗余、自动故障切换、灾难恢复等事项。

* 查询功能，文档数据库能够查询文档中的数据，而不用像键值数据库那样，必须根据关键字获取整个文档，而后再检视其内容。MongoDB还能够基于“内嵌子文档”来查询。

* 可扩展性，增长更多的“读取从节点”，将所有读取操做都引导至从节点上，这样能够扩展数据库应对频繁读取的能力了。若是想扩展写入能力，则能够把数据分片，分片操做根据特定字段来划分数据(该字段的选择很重要)，这些数据要移动到不一样的节点中。为了让各分片负载保持均衡，须要在节点之间动态转移数据，向集群中加入更多节点，并提升可写入的节点数，就能够横向扩展写入能力。把每一个分片都作成副本集能够提升读取效率。

适用案例

* 事件记录

* 内容管理系统和博客平台

* 网站分析和实时分析

* 电子商务应用程序

不适用场合

* 包含多项操做的复琐事务

* 查询持续变化的聚合结构

 

第10章 列族数据库

关系型数据库	Cassandra
数据库实例	集群
数据库	键空间
表	列族
行	行
列	列

 

特性

* 一致性，Cassandra收到写入请求后，会先将待写入数据记录到“提交日志”中，而后将其写入内存中一个名为“内存表”的结构中。写入操做在写入“提交日志”和“内存表”后就算成功了。写入请求成批堆积在内存中，并按期写入一种叫作“SSTable”的结构中，该结构中的缓存一旦写入数据库，就不会再向其继续写入了。若其数据变更，则需新写一张SSTable。无用的SSTable可由“压缩”操做回收。

* 事务，Cassandra没有传统意义上的事务，它的写入操做在行级别的原子的。

* 可用性，Cassandra具有高可用性，由于集群中没有主节点，减小操做请求的一致性便可提示集群的可用性。可用性受制于 R+W>N 这一公式。W是成功执行写入操做所需的最小节点数，R是顺利执行读取操做所需获取的最小应答节点数，N是参与数据复制的节点数。

* 查询功能，Cassandra没有功能丰富的查询语言。在列族插入数据后，每行中的数据都会按照列名排序。若是一列的获取次数比其余列更加频繁，能够考虑将其值用做行健以提升性能。

* 基本查询，有GET、SET和DEL。

* 高级查询和索引编订，Cassandra列族能够用关键字之外的其余列当索引。这些索引以位映射图的形式出现，在列中频繁出现重复值的状况下效果较好。

* Cassandra查询语言(CQL)，提供查询功能，但未包含SQL的所有功能。

* 可扩展性，因为没有主节点，因此只要向Cassandra集群中新增节点就能改善其服务能力。

适用案例

* 事件记录

* 内容管理系统和博客平台

* 计数器

* 限期使用

不适用场合

* 须要以“ACID事务”执行写入和读取操做的系统。

* 根据查询结构聚合数据的场景。

* 开发早期、原型期和技术初探期。开发初期没法肯定查询模式的变化状况，查询模式一旦变化，列族的设计也要随之修改。注意，关系型数据库改变数据模式的成本很高，但查询模式的修改为本较低，Cassandra则相反。

 

第11章 图数据库

特性

* 一致性，因为图数据库操做互相链接的节点，因此大部分图数据库一般不支持把节点分布在不一样服务器上。图数据库经过事务来保证一致性，它们不容许出现“悬挂关系”：全部关系必须具有起始节点和终止节点，并且在删除节点前，必须先移除其上的关系。

* 事务，Neo4J是兼容ACID事务的数据库，修改节点或向现有节点新增关系前，必须先启动事务。

* 可用性，Neo4J从1.8开始，支持“副本从节点”，这些从节点能够处理写入操做，向其写入后，它会先将所写数据同步至当前主节点，而后主节点再同步至其余从节点。也能够配合ZooKeeper来记录每一个丛节点和当前主节点中最新的事务ID。

* 查询功能，图数据库可使用Gremlin等查询语言，Neo4J还可使用Cypher语言来查询图。

* 可扩展性，图数据库要运用分片技术比较难，由于它并非面向聚合的，而是面向关系的。因为任何节点都有可能关联其余节点，所以把相关节点放在同一台机器上，遍历图时比较方便，放在多台机器上性能很差。扩展图数据库通常有三种方式：

1. 给服务器配置足量内存，使之彻底能够容纳“工做集”中的所有节点和关系。只有在这些内存量的数值比较合理时，这项技术才有用。
2. 增长仅能读取数据的从节点，便可改善数据的读取能力，全部写入操做仍由主节点负责。
3. 若数据集太大，致使多节点复制不大现实，可采用“领域特定知识”在应用程序端对其分片，好比按照地理位置分片等。

适用案例

* 互联数据

* 安排运输路线、分派货物和基于位置的服务

* 推荐引擎

不适用的场合

* 更新所有或某个子集内实体的场合

* 涉及整张图的操做

 

第12章 模式迁移

* 若要迁移关系型数据库等“强模式”的数据库，可将历次模式变动及其数据迁移操做保存于“版本控制序列”中。

* 因程序代码要依照“隐含模式”来访问无模式数据库的数据，故其数据迁移仍需谨慎处理。

* 无模式数据库亦可借用强模式数据库的迁移技术。

* 无模式数据库可以使用“增量迁移”技术更新数据，以便在不影响应用程序读取数据的前提下，修改数据的隐含模式。

 

第13章 混合持久化

* 混合持久化旨在使用不一样数据库技术处理多种数据存储需求。

* 混合持久化既可为企业中多个程序所用，也能够运用在单个应用程序中。

* 将数据访问封装成服务，能够减小数据库变更对系统其它部分的影响。

* 新增数据库技术会让编程和操做更复杂，因此要权衡引入新数据库带来的好处和引入它带来的复杂度的利弊。

 

第14章 超越NoSQL

* 文件系统

* 事件溯源

* 内存映像

* 版本控制

* XML数据库

* 对象数据量

 

第15章 选择合适的数据库

* 经过使用更符合应用程序需求的数据库来改善程序员的工做效率。

* 以能处理大数据量、下降延迟且增进数据吞吐量的某种技术组合来改善数据访问性能。

* 在决定使用某个NoSQL技术以前，必定要测试其是否如预期般改善了程序员工做效率和数据访问性能。

* 用服务来封装数据库，即能在需求变动或技术成熟后改换其所封装的数据库技术。可将应用程序各部分划分到不一样服务中，以便为既有程序引入NoSQL数据库。

* 大部分应用程序，尤为是“非战略性的”应用程序，应该继续使用关系型数据库技术，至少在NoSQL技术环节还没有更加成熟时是如此。