NOSQL(三)分布式数据模型

《NoSQL精粹》读书笔记，转载请注明出处《jiq•钦's technical Blog》

催生NoSQL的主要原因是：需要一种能够运行在大集群上的数据库

面向聚合的数据库非常适合于横向拓展的集群架构，聚合自然成为了数据分布单元，而数据分布主要有两条路：“复制(replication)”和“分片(sharding)”，复制是将同一份数据拷贝至多个节点，分片是将数据分散存放到不同节点上。

1

单一服务器

若使用NoSQL数据库的目的基本上是为了处理聚合，那么就可以考虑在单一的服务器上部署NoSQL数据库。换句话说在不需要分布数据就能应对的场景下，优先选择“单一服务器”的方案。

2

分片

如果数据库的繁忙体现在：不同用户需要访问数据集中的不同部分。那么优先选择分片，将数据的各个部分存放于不同的服务器中，以此实现横向拓展。

**思路：**为了将不同用户的请求均衡地分布到不同的服务器上，采取怎样的策略存放数据是关键。之所以设计“聚合”，就是为了把经常要同时访问的数据放在一起，因此聚合可以作为数据分布式的单元。如何把聚合数据均匀地分布在不同的机器上，有时可能需要采取“领域特定的规则”，很多NoSQL数据库已经提供了“自动分片(auto-sharding)”的功能，由数据库负责将数据分布到各分片，并将数据访问请求引导至适合的分片上。

**优点：**分片对于提升性能尤其有用，因为可以同时提升读取和写入效率，复制技术，尤其是带缓存的复制技术，可以极大提升读取性能，但是对于需要频繁执行写入操作的场景却作用不大，而分片提供了可以横向拓展写入能力的方式。

**缺点：**分片对于提升数据库“故障恢复能力”帮助不大，跟“单一服务器”一样，甚至可能还会降低数据库的错误恢复能力。

3

复制

3.1

主从复制

**思路：**主从结构中有一个主节点和多个从节点，从节点复制主节点的数据，保证所有从节点数据与主节点同步。读取时，可以从主节点或者任意从节点读取数据，即使主节点出错了，从节点依然可以处理数据读取请求，而且还能重新指派一个从节点作为新的主节点，通过新增从节点可以很容易进行水平拓展。这样不仅能够“大幅提升数据读取性能”，还能够“保证读取操作的故障恢复能力”。写入时就比较惨了，需要请求主节点进行更新操作，然后由主节点将数据更新请求发布到从节点，一方面性能不高，不适合频繁写入的场景，另一方面，若主节点出错，在恢复之前都无法处理数据更新请求。

**优点：**处理写入请求性能高、具备故障恢复能力。即使不需要横向拓展，采用主从复制也有其用处，再主节点处理所有读写操作同时，从节点可以充当“即时备份”。

**缺点：**一方面因为主节点是系统的瓶颈和弱点，导致写入操作性能和故障恢复能力都不尽如人意。另一方面有一个很大的缺陷，即数据的不一致性，因为如果主节点处理的更新操作还没有完全通知到所有从节点时，不同的客户端从不同的从节点就可能读出各异的值。

3.2

对等复制

**思路：**为了解决主从复制中主节点成为系统瓶颈和弱点这一问题，抛弃主节点概念，所有节点都可以接受写入请求。

**优点：**解决了主从复制结构中，主节点作为写入操作时的瓶颈和弱点这一问题。

**缺点：**仍然是一致性，由于两个不同节点可以同时处理写入请求，当同一时间试图更新同一份数据时，就会出现“写入冲突”，同时读取一致性问题也会存在。两种极端解决一致性：一种是在真正写入前各个副本之间先协调好，确保不会发生冲突；另一种是把相互冲突的写入操作合并起来，这样任意副本都可以进行数据写入。

4

分片和复制相结合

**思路：**首先对数据进行分片，然后对于每一份数据都采用“主从复制”进行维护，这就意味着系统中存在多个主节点，对于每项数据来说，负责它的主节点只有一个。“列族数据库”就是这样一个例子。