读书笔记之《No-SQL精粹》

No-SQL精粹读书笔记

介绍

随着web互联网的发展，往往需要存储海量数据以及高效的访问数据.No-SQL数据库应运而生,其中以Memcached、Redis、MongoDB作为典型代表.


推荐指数:★★★★

No-SQL精粹很像一本介绍文摘，让我们对当下流行的No-SQL数据库有所了解，明白如何选择.

---

No-SQL精粹读书笔记正文

第一章:为什么使用No-SQL

1.1关系数据库的价值

1)持久化存储数据
2)并发控制
3)集成(共享数据库集成)
4)近乎标准的模型(对SQL的支持和事务的支持)

---

1.2阻抗失谐

阻抗失谐指的是:关系模型和内存中程序的数据结构之间存在的差异.

目前开发中有很多映射框架来帮我们尽量降低阻抗失协开发难度，比如ORM框架hibernate等.

---

1.3”应用程序数据库”与”集成数据库”

应用程序数据库:即统一访问数据库的应用程序(类似数据库网关),对外只提供接口访问数据库.

举例:公司中有A、B、C、D...等多个应用,如果每个应用都能直接访问数据库的话,那么任意的更新操作可能是存在风险的,
如果所有的应用都只能通过X应用程序接口来访问数据库的话,那么给维护和开发都会带来很大的便利.
即使后期想要切换后台数据库对其它应用来说是不可见的不影响,达到了解耦的效果.

备注:推荐使用应用程序数据库方式访问数据库.

---

1.4蜂拥而至的集群

关系型数据库不是设计给集群用的.

---

1.6nosql登场

NoSQL并没有统一的概念定义,可以理解成非传统关系数据库(不支持SQL).

No-SQL数据库共有的特性是
1)不使用关系模型,没有对SQL提供支持
2)对集群环境提供支持
3)开源
4)为互联网而生
5)无模式(相对)


选择No-SQL的两个主要原因

1)、待处理的数据量很大,或对数据访问的效率要求很高,从而必须将数据放在集群上.
2)、想采用一种更为方便的数据交互方式来提高应用程序开发效率.(传统关系型书库存在阻抗失协问题)

---

1.6要点

1、关系型数据库这几十年都很成功,它能够持久化保存数据,控制并发访问同时提供一套集成机制.
2、由于关系模型与内存中的数据结构不匹配,所以应用程序开发人员一直为这种阻抗失谐问题锁困扰.
3、数据库领域的迁移趋势:原来,各个应用程序都把同一份数据库当成共用的集成点;现在,各个应用程序都会封装自己的数据库,并通过服务彼此集成.
4、促使数据存储方式发生变化的重要原因是:需要在集群上运行大量数据,而关系型数据库不能再集群中高效运行.
5、NoSQL是偶然出现的新名词.它没有规范的定义

.No-SQL数据库共有的特性是
1)不使用关系模型,没有对SQL提供支持
2)对集群环境提供支持
3)开源
4)为互联网而生
5)无模式(相对)

6、NoSQL崛起锁产生的重要影响是混合持久化.

---

第四章:分布式模型

催生NoSQL的主要原因是:我们需要一种能够运行在大集群上的数据库.随着数据量的增加,以购买更强大服务器来运行数据库的纵向扩展会变得越来越困难.
与之相比,将数据库运行在服务器集群上的横向扩展方式,却颇受青睐.面向聚合数据库非常适合横向扩展方式,因为聚合此时就自然成了数据分布单元.

---

宽泛的说,数据分布有两条路径:复制与分片.

复制就是将同一份数据拷贝至多个节点.
复制又分两种形式:
    1)主从复制模式
    2)对等复制模式

分片则是将不同数据存放在不同节点中.

---

4.1单一服务器

当数据量不是很多时候,就不需要将数据分布式模型存储了.
在不需要分布数据就能应对时,总应选用"单一服务器"方案.

4.2分片

一般来说,数据库的繁忙体现在:不同用户需要访问数据集中的不同部分.在这种情况下,我们把数据的各个部分存放在不同的服务器中.
以此实现横向扩展.该技术就叫分片.


无论如何,从单一节点想分片迁移,都比较难.(要想完成分片业务模块不能太耦合,否则难度就更大)

---

4.3主从复制

主从式分布中,我们将数据复制到多个节点上.其中有一个节点叫做"主节点"其余的叫做"从节点".

主节点和从节点的数据一致性通常是靠数据库日志文件的,推拉模式同步数据.

在需要频繁读取数据集的情况下,"主从复制"最有助于提升数据访问性能.通常主节点只处理数据更新请求,从节点完成数据查询请求.

主从复制有一个缺点就是数据一致性问题,是存在延迟的.

---

4.4对等复制

"主从复制"有助于增强读取操作的故障恢复能力,然而对写操作却帮助不大.主从复制的性能瓶颈会出现在主节点的写操作上.
对等复制能解决这个性能瓶颈,但是对等复制存在的最大问题就是数据一致性问题.

从目前实际开发上的选择上来看,更多的是采用主从复制模式.

---

4.5结合”分片”与”复制”技术

复制和分片两种策略可以结合起来使用.结合它们的优点,当往往系统架构就会复杂很多,只有当达到一定数据量和需求时才选择使用.

---

4.6要点

数据分布有两种方式

    1)分片:将不同的数据分片存放在多个服务器中,每一个数据子集都专门由一台服务器负责.
    2)复制:将数据复制到多个服务器中,每份数据都能在多个节点中找到.

复制技术又分为两种形式
    1)主从复制:一个主节点,多个从节点
    2)对等复制:任何节点都可更新数据,节点间相互协调以同步其数据.

    主从复制减少了更新数据时的冲突机率,但是它会让主节点成为性能瓶颈.

---

第五章:一致性

面向集群的NoSQL数据库需要面对一致性的问题,关系型数据库试图通过"强一致性"来避免各种不一致问题,
在NoSQL领域中,需要我们自己思考系统需要何种一致性.

---

5.1更新一致性

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

---

5.2读取一致性

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

---

5.3放宽“一致性”约束

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

关系型数据库一般用事务来加强一致性，但是事务会影响系统性能。

---

CAP定理，其中CAP的意思是

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

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

---

5.4放宽“持久性”约束

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

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

---

5.5仲裁

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

---

第6章:版本戳

版本戳就是版本号的意思,乐观锁就是基于版本号来实现的.

---

版本戳用户标识数据的版本，典型情况是使用计数器版本戳，如果当前数据库中某条数据的版本戳是3，而用户请求更新的数据版本戳是2，

说明在用户上一次读取到更新之间，该条数据发生了一次更新，可能是有其他人在此时更新了数据，所以这个用户的更新会失败。

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

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

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

第八章:键值数据库

键值数据库是一张简单的哈希表,所有数据访问都通过主键来操作.

键值数据库应该说是最简单的一种NoSQL数据库,就像Java中的HashMap或Python中的字典.

---

最典型和应用最广的键值数据库是Memcached、Redis,Redis的数据结构非常丰富,所以近年来很流行,Redis不仅能作简单的键值数据库使用,还能提供更复杂的功能.

---

适用案例:
    1)存放会话信息
    2)购物车数据


不适用场合:
    1)数据间关系
    2)含有多项操作的事务
    3)查询数据
    4)操作关键字集合

第九章:文档数据库

"文档"是文档数据库中的主要概念.此类数据库可存放并获取文档,其格式可以是xml、json、bson等.

文档数据库的代表:MongoDB、CouchDB

---

适用案列:
    1)事件日志记录
    2)内容管理系统及博客平台
    3)网站分析与实时分析
    4)电子商务应用程序

不适用场合:
    1)包含多项操作的复杂事务
    2)查询持续变化的聚合结构

---

第十三章:混合持久化

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

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

将数据访问封装成服务，可以减少数据库变动对系统其它部分的影响。

新增数据库技术会让编程和操作更复杂，所以要权衡引入新数据库带来的好处和引入它带来的复杂度的利弊

---

第十四章:超越No-SQL

文件系统

事件溯源

内存映像

版本控制

XML数据库

对象数据量

第十五章:选择合适的数据库

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

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

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

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

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

总结

和使用No-SQL相比，选择在什么场景和业务下选择No-SQL数据库更为重要.我们在决定使用No-SQL之前先要分析清楚需求.