纵横大数据主要观点（二）

分布式关系型数据库典型的架构

Share-Nothing

MPPDB一般都是此架构，主要是将数据拆分存储到不同的节点上，在各自节点上独立读写数据，正因为如此，此架构只适合OLAP业务，如果进行表关联操作时仍会进行网络节点之间的数据迁移与交换工作，同样的网络会成为MPPDB 水平扩展的瓶颈。TeraData目前最大商用规模大约600节点。

Share-Disk

典型的应用是Oracle RAC，不同于传统的HA架构，ShareDisk架构中的每个节点都是工作节点，独立处理业务。由于是ShareDisk架构，读写磁盘就会出现冲突，会产生大量的存储网络流量，通常存储网络的流量会因为数据库节点规模增加变成瓶颈

OLTP和OLAP 通常部署在两套系统中主要原因是数据库系统追求的高TPS，OLTP追求的是高并发、随机读写，要保持交易十五的ACID 特性，维护强大的数据库日志，目前实现OLTP单点能力（主机平台+高端IO存储）。OLAP追求的是批量操作、高并发读操作，技术上主要解决很好的分配与管理各种资源（即资源的精细化管理）。 关于Join操作，跨表聚合操作，对于OLTP数据库需要大量的IO操作将表数据读取到内存进行操作；而MPP数据库本身就是根据某个键值对数据进行分布式存储，相当于提前为多表Join操作做了很多工作。OLTP通常是通过hash join进行优化，OLAP是通过分布式join。

NoSQL数据库

NoSQL数据库是随着互联网应用发展起来的（是新兴数据库产品，并不是完全的新技术），主要是用来处理半结构化数据/非结构化数据。NewSQL是关系型数据库联邦（主要代表是VoltDB），内存数据库集群。

NewSQL数据库

实现NewSQL通常是采用数据库“联邦”来实现。主要就是采用“垂直分库“，”水平分表”。分库分表以后，按照分库分表的策略会将数据分散到不同的物理设备上（只有这样才能增加数据库的处理能力），这就导致了应用会感知到数据在不同的数据库服务器上。此外，还可以通过读写分离来增加。

企业数据库变化的路径

一般企业数据库变化的路径如下如下：小型数据库->大型数据库->现有数据库扩展；在企业刚起步阶段数据量不大采用小型数据库，当企业到达一定规模时为了能满足业务负载、可用性、安全性等一系列诉求最近直接等方法就是采购大型商用数据库；随着业务量等不断增加没有业界没有简单直接升级数据库产品就可以解决数据处理要求，此时就只能在现有数据库中扩展。

1. 小型数据库：MySQL、SQL Server、PostgreSQL
2. 大型数据库：Oracle、DB2甚至是基于大机（MainFrame）数据库解决方案
3. 对现有数据库管理系统进行扩展（通常是已经上了Oracle、DB2等大型数据库的情况）
   • 直接scale up
   • 采用厂商提供高阶方案，例如：oracle rac
   • 分库分表
   • 读写分离

典型等数据库扩展方案

垂直分库

1. 将原来在中心物理数据库中不同类型database拆分到不同的物理数据库（也就是把原来数据库的关联操作要改成两个数据中心之间的关联消息通信服务）
2. 分库是业务人员需要对数据库进行重新设计优化，去掉不必要、复杂的关联操作

水平分表

1. 按照独立数据库中的某一个大表按照某种方式拆分成“子表”，通常是按照某一列或者多列值进行均分或者按照哈希算法分割
2. 将子表部署在不同物理数据库服务器中以提升整体数据库性能

读写分离

1. 将一个中心库分成两类库，一类用于处理读操作，一类用于处理写操作
2. 需要增加一个读写分离代理来专门完成该任务，屏蔽对应用的影响
3. 读写分离数据库中数据是完全一致的
4. 可以设置读操作一致性规则，例如要等到从R（大于等于1）个读库读到的数据库一致时才返回读操作结果
5. 写操作的数据库必须实时或者准实时将数据同步到读库。

小结 1. 分库分表和读写分离是相辅相成，可单独实施也可以一起实施。分库包容了分表（一般在实施分库的基础上再实施分表），分库分表和读写分离是平行的，可以同时实施。 2. 数据库联邦牺牲即时一致性，但保证了最终的一致性（CAP原则中，牺牲了C），也就意味着实际应用中弱化了的事务和关联性。