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

╰+哭是因爲堅強的太久メ 2022-07-15 15:21 195阅读 0赞

# 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之前先要分析清楚需求.