单机数据库，集群数据库，分布式数据库的概念和比较
单机数据库，集群数据库，分布式数据库的概念和比较
单机数据库：
简介：
只能运行在单机上，不能提供网络功能的数据库。实现数据采集、保存、管理功能，实现信息共享、避免交叉采集数据。
优点：
1. 减少数据冗余，节省存储空间
方便数据查询和管理
实现数据资源共享
方便编写数据库相关应用程序
缺点：
1. 不能进行网络通信
串行处理数据请求
单机存在性能瓶颈
随着业务规模扩大和联机事务增加性能大幅下降
单机数据库的比较：
数据库方案 业务支持 特点
SQLServer连接池
(Shared Everything Model） ① 千万级别数据
② 支持并发数与服务器性能有关，一般不超过200个 ① 针对单机，完全透明的共享CPU/MEMORY/IO资源，并行处理能力差
② 使用方便，开发速度快
Oracle连接池 ① 上亿级别数据
② 管理容易
③ 支持并发数与服务器性能有关，一般不超过200个
① 价格高
② 兼容性好
③ 可移植性好
④ 支持多种通讯网络
MySQL ① 免费
② 支持万条级别数据
③ 第三方工具多
④ 支持并发数与应用程序大小相关，一般100
一般通过分表中间件mycat、MySQL Proxy实现大量数据的处理
集群数据库：
简介：
利用两台以上的服务器，构成一个虚拟单一数据库的逻辑映像，像单机数据库那样，向客户提供透明的数据服务。实现多用户网络操作。
分类：
1. 基于数据库引擎的集群：要求数据库引擎本身具有集群功能，一般只有企业版数据库支持，共享磁盘或非共享磁盘技术均可。
基于数据库网关（中间件）的集群：对数据库集群能力没有要求，标准版数据库即可，只基于不共享磁盘技术。
优点：
提高数据库性能
提高数据库可靠性
提高数据库可扩展性
提高用户体验和数量
缺点：维护数据一致性过程复杂
数据同步消耗大量资源
集群管理技术复杂
关键技术&&实现难点：
1. 提高处理速度 ：数据分散存放（提高并行处理能力）、多处理器系统、负载均衡
提高数据可用性 ：
硬件级冗余（多个独立数据库服务器实现一个逻辑数据库、屏蔽服务器损坏）
软件及冗余（采用多个冗余的运行数据库进程屏蔽软件错误）提高数据安全性 ：增加联机口令保护、增加防火墙
提高数据可扩展性：一个数据库表格分散到多个服务器或者每个服务器分管几个内容不同的表格
集群数据库的比较：
数据库方案 业务支持 特点
Oracle RAC
（Shared Disk Model） ① 实时应用集群
② 支持网络计算
③ 支持并发性能与节点数量有关
④ 多节点负载均衡
⑤ 系统规划设计要求高 ① 本质还是一个数据库，采用了分布式锁管理器，用于集群之间的并发控制，不相关的数据分库
② 各个处理单元使用自己的私有CPU/MEMORY
③ 数据资源共享，可通过增加节点提高并行处理能力，扩展性好
④ 存储器接口性能是瓶颈
⑤ 实现高可用性，不用来针对分布式计算
Microsoft SQL Cluster Server ① 应用透明性要求低
② 共享磁盘
③ 管理方便 ① 节点可主动通过共享负载方式协同完成工作
② 以”active-active”方式共享相同的存储子系统和功能
③ 实现故障恢复和故障返回功能
④ 升级过程中无需停止应用程序
实例Oracle RAC：
Oracle RAC 实时应用集群，是Oracle数据库支持网格计算环境的核心技术。
Oracle’s Real Application Cluster: RAC共享磁盘体系结构，只需增加一个服务节点，自动将节点加入集群服务中，自动将数据分配到该节点上，并将访问自动分发，不用修改应用程序，管理方便。使集群中所有节点的磁盘共享对所有数据的访问，数据无需再节点间进行分区。采用了sharing everything的实现模式，通过CPU共享和存储设备共享来实现多节点之间的无缝集群，用户提交的每一项任务被自动分配给集群中的多台机器执行。
主要优点是对应用层透明，通过Heartbeat检测可用性非常高；主要缺点是存储是共享的，存储上的可扩展能力不足。
Microsoft SQL Cluster Server : MSCS非共享磁盘体系结构，必须手工修改数据的分区，所有集群计算机均可主动通过共享负载的方式协同完成工作，并在某个节点出现故障时分担他的工作。通过自身的容错能力提高应用程序的可用性，在不丢失相关数据前提下，对集群上所运行的应用程序进行故障恢复和管理。
分布式数据库：
简介：
针对各种大集团国际性公司、跨国公司等，地域上比较分散，而在管理上，既要求各个部门具有独立的局部控制，分散管理的能力，同时又要在整个企业内部实现全局控制，统一管理（民航、铁路订票系统、洲际银河汇兑业务等），需要将各个部门、子公司的数据通过网络连接在一起实现共享，使得数据在逻辑上是一个整体。
特点：
1、 物理分布性：数据在物理上分散存储在计算机网络连接起来的多个站点上
2、 逻辑整体性：分散的数据逻辑上是一个整体，被所有用户共享和统一管理，支持全局应用
3、 站点自治性：各个站点上的数据由本地数据库管理系统管理，具有自治处理能力，完成本地具备应用
4、 数据独立性：数据逻辑独立性、物理独立性、分布透明性（由分布式数据库系统屏蔽）
5、 数据冗余性：通过数据冗余提高系统可靠性、可用性，改善系统系能，在多个站点上存储数据副本
核心技术&&实现难点：
一、 数据拆分技术：
当一个表的数据量达到无法处理的时候，就需要将它拆成多个表，在拆分过程中的拆分策略成为核心内容。主要包括：
1、 垂直切分：把表按不同模块划分到不同数据库中。
将原来强耦合的系统拆分成多个弱耦合的服务，通过服务间的调用来满足业务需求，表拆分之后，通过服务暴露出去，保证核心模块的稳定。其中，如何进行合理的业务设计使得业务上松耦合从而将表从技术上隔离开始关键。
实现难点：
a) 表间级联无法在数据库层面实现
b) 单表大数据量依然存在性能瓶颈
c) 事务保证比较复杂
d) 应用端的复杂性增加
2、 水平切分：把一张表按照某种规则将数据划分到不同表或数据库中，从而解决单表大数据量问题。
例如在计费系统中，通过按时间来划分表；而在SaaS应用中，通过按用户维度划分数据表。这样的水平切分没有破坏表间关系，可以将有关系的表放在同一个库内，从而不会影响业务需求，同时解决了单表大数据量的问题。
实现难点：
a) 切分规则复杂
b) 应用端调用难度增加
c) 数据维护难度增加
d) 当拆分规则变化时，需要对数据进行重新迁移
3、 垂直与水平联合切分：综合上述两种策略，结合两者优点，实现模块划分、分区治理的同时，解决单表大数据量的性能瓶颈问题。适合大型项目，不适合小型项目。
实现难点：
a) 项目复杂度极大提高
b) 开发成本增加
c) 数据维护难度增加
二、 与应用程序端的整合策略：
在进行数据切分之后，需要考虑应用端如何方便的存取数据，不能因为数据拆分导致应用端存取数据错误或者处理变得异常复杂
1、 应用端做数据库路由
在应用端每次调用的位置，通过工具包的处理，给每次调用加上路由信息，分析每次调用，路由到正确的库。
实现难点：
a) 无法保持对应用端透明
b) 修改路由策略时还要修改应用端
c) 难以做到动态更改和管理
d) 应用端连接池设计复杂度增加
2、 在应用端和服务器端加一个代理服务器做路由
通过代理服务器来做服务器路由可以屏蔽后端数据库拆分的细节，增强了拆分规则的可维护性。
实现难点：
a) 对客户端和数据库服务器端的连接管理和安全认证
b) 对调用命令和SQL的解析
c) 调用结果需要过滤和合并
3、 数据库端自行路由
通过数据库端的代理产品在数据库端实现路由功能。例如使用MySql提供的MySql Proxy产品。
实现难点：
a) 拆分规则的灵活配置问题
b) 不能保证满足应用端的多种划分需求
优点：
1. 良好的可靠性和可用性：多个站点、多个副本，当某站点故障时，访问仍可以进行
提高效率，降低通信费用：通过合理数据切分，保证常用数据通过本地访问
灵活的可伸缩性：增减站点方便，配置方式灵活，适应性强
自治性和管理控制方便：站点独立管理本地数据库，同时实现统一管理
缺点：数据拆分设计复杂：需要根据各种业务需求对数据进行合理拆分，不合理拆分极大损失架构性能
分布式数据查询处理复杂：需要设计复杂的查询优化算法实现并行性和数据的合理分布
分布式数据更新复杂：对多个站点上的多个数据副本保证数据一致性开销很大
分布式事务的并发控制困难：需要对多个事务的同时读写相同数据进行协调，保证数据完整性和一致性
实例：
基于Hadoop的分布式数据库Hbase:
Hbase是一个分布式的数据库，使用Zookeeper来管理集群。在架构层面上分为Master（Zookeeper中的leader）和多个RegionServer，RegionServer是调度者，管理Regions，基本架构如图：
在Hbase的概念中，RegionServer对应于集群中的一个节点，而一个RegionServer负责管理多个Region。一个Region代表一张表的一部分数据，所以在Hbase中的一张表可能会需要很多个Region来存储其数据，但是每个Region中的数据并不是杂乱无章的，Hbase在管理Region的时候会给每个Region定义一个Rowkey的范围，落在特定范围内的数据将交给特定的Region，从而将负载分摊到多个节点上，充分利用分布式的优点。另外，Hbase会自动的调节Region处在的位置，如果一个RegionServer变得Hot（大量的请求落在这个Server管理的Region上），Hbase就会把Region移动到相对空闲的节点，依次保证集群环境被充分利用。