数据库分片知识分享Word格式.docx
《数据库分片知识分享Word格式.docx》由会员分享，可在线阅读，更多相关《数据库分片知识分享Word格式.docx（12页珍藏版）》请在冰豆网上搜索。
例如，将一个销售明细表拆分到用户库、销售库、收支库的相应表里。
实际情况中，采用此种分片方式的情形较少。
●水平分片
也称为横向分片，是指按数据的行进行分片，即不同的记录分配到不同数据库，例如将全国用户按省市区划分。
在大多数情况下都使用的是水平分片，本文若无特别说明，也指的水平分片。
二、分片的优缺点
1分片的优点
对于分片来说，它的优点有：
●以水平扩展来提高整体性能
随着数据的增长，通过增加更多服务器，将新增数据及负载放置到新增服务器即可。
●更高的可用性，更好的可管理性
当某个数据分片所在的服务器出现故障时，不会使整个系统对外停止服务；
同时，在进行管理和维护时，可以一个分片接一个分片地进行。
●消除单库、单表的性能瓶颈
合理使用拆分规则，保证每个分片数据规模适度，不再受单库、单表的性能瓶颈限制。
判断拆分规则是否合理的主要原则包括：
数据尽可能分布均匀、负载尽量均衡、扩容缩容时数据迁移尽可能少。
2分片的缺点
数据分片会对整个系统的性能和扩展性带来好处，但也增加了开发和维护的复杂度。
尽管分片有多种方式，但它们拥有共同的缺点：
●分布式事务
在任何一个分布式系统，最多只能时满足数据一致性（Consistency）、可用性（Availability）、分区容错性（PartitionTolerance）三个特性中的两个，这被称为CAP原理。
对于关系数据库，最常用到的是二阶段提交（2PC）机制，它能保证各服务器间的数据强一致性，但代价是降低了整体可用性。
而如果采取类似补偿事务（TCC）的机制，整体可用性得到了提升，却最多只能实现服务器间的数据弱一致性。
●跨服务器多表Join
由于数据被拆分到多个服务器节点，必然涉及到跨服务器的多表Join问题。
随着参与Join表的数量、服务器的数量的增加，此问题会变得越来越复杂，导致完成操作的工作量越来越大。
目前较好的做法，一方面是巧妙设计拆分规则，尽量将参与Join的分片存放在同一服务器上，另一方面是在查询时改写SQL，先将一个任务拆分成若干个子任务分配给各服务器执行，然后再整合子任务的返回结果以得到最终结果。
即使如此，在运用场景上仍然存在很多限制（如只能有两个表参与Join），运行性能也难言满意。
●跨服务器分页排序
本问题的核心其实是局部数据的全局定位以及重复执行问题，这会带来额外的管理和运算负担。
大致情况是：
全局定位的位置越靠后，额外的负担就越重。
最乐观的情形是只是取总体的topn条记录，此时m个节点只须各自返回n条记录，参与全局定位的数据是n*m。
但如果要获取总体第f条后的n条记录，则理论上m个节点都需返回f+n条记录，参与全局定位的数据量是（f+n）*m。
如果再涉及其它问题（如重复数据、稳定排序等），处理过程会更加复杂，额外的负担也会越重。
●其它
关系数据库的一些重要特性，如全局唯一性约束、外键约束、触发器等，在处理分片时都会受到诸多限制，甚至完全不支持。
三、PostgreSQL分片方案Citus
1Citus简介
PostgreSQL有几种分片方案，其中最常使用的是Citus，由早期的pg_shard发展而来。
Citus不是一个独立程序，而是一个插件，可以通过CreateExtension进行安装。
每个citus集群有多个PostgreSQL数据库实例组成，数据库实例分为两类：
●master节点，通常有一台。
master节点只存储分库分表的元数据，不存储实际的数据。
●worker节点，通常有多台。
worker节点存储实际的分片数据（shard）。
用户只连接master节点，即用户把SQL发到master节点，然后master节点解析SQL，把SQL分解成各个子SQL发送到底层的worker节点，完成SQL的处理。
2Citus操作示例
#配置分片策略（在MasterNode上创建表之后）：
SELECTmaster_create_distributed_table（'
test_table'
'
id'
hash'
）;
#进行分片操作（将表分为3片，每个分片有2个副本）：
SELECTmaster_create_worker_shards（'
3,2）;
#查看分片：
SELECT*frompg_dist_shard;
#查看分片分布：
SELECT*frompg_dist_shard_placementorderbyshardid,placementid;
通过MasterNode对表test_table进行插入操作时，根据先前定义的分片策略，citus会根据id的哈希值自动为插入的记录选择一个分片进行写入。
当通过MasterNode对表test_table进行查询时，首先master节点解析SQL，分解为各个子SQL发送到底层的worker节点；
当各个worker把数据返给master之后，master再做一次整合，最后把结果返回用户。
3Citus的限制
●可以创建索引，但不支持索引自动命名；
●可以创建唯一约束，但必须在定义表时进行，一旦表中已有记录再创建则报错；
●不支持insert…select…，但支持copy；
●不支持distinct，但支持groupby；
●不支持update和delete时where条件值使用in；
●执行器为real-time时不支持跨节点join，修改为task-tracker后支持，速度较慢；
●MasterNode会成为瓶颈。
四、Oracle分片方案
1OracleSharding组成
Oracle12.2版开始支持分片，基于表分区技术，适用于OLTP场合。
OracleSharding主要包括以下组成部分：
●Shardeddatabase（SDB）：
逻辑上SDB是一个数据库，但是物理上SDB包括多个物理独立的数据库，SDB类似一个数据库池（pool），数据库池（pool）中包括多个数据库（Shard）.目前版本最大支持1000个shard。
●Shards：
SDB包括多个物理独立的数据库，每一个数据库都称为shard，每个shard数据库位于不同的服务器，不共享CPU、内存、存储等资源。
每个shard数据库中保存表的不同数据集,但是每个shard中都有相同的列（columns）。
Shard数据库可以是Dataguard/ADG，提供高可用性，Shard数据库（单机或者ADG）可以通过GSMdeploy来自动创建，也可以将一个已经通过dbca创建好的数据库add到SDB。
●Shardcatalog：
是一个Oracle数据库，用于集中存储管理SDB配置信息，是SDB的核心。
SDB配置变化，比如添加/删除shard，Globalservice等等，都记录在Shardcatalog。
如果应用查询多个shard中的数据，那么由Shardcatalog统一协调分配。
推荐将Shardcatalog配置为dataguard环境，这样可以提供HA高可用。
如果Shardcatalog无法访问，那么只会影响一些维护操作和跨shard访问，而不会影响单独的shard操作。
●Sharddirectors：
GlobalDataService（GDS）实现对Sharding的集中部署和管理。
GSM是GDS的核心组件。
GSM作为Sharddirector.GSM类似于监听器，将客户端对SDB的请求路由到对应的shard，负载均衡客户端的访问。
●Globalservice：
数据库的服务（service），用于访问SDB中的数据
●管理接口：
通过GDSCTL（command-lineutility）接口部署管理监控Sharding。
2OracleSharding方法、对象
OracleSharding支持3种分片方法：
●System-ManagedSharding：
这种方法用户不用指定数据存放在哪个shard中。
Sharding通过一致性哈希（CONSISTENTHASH）方法将数据分区（partitioning），并自动分布在不同的Shard。
System-managedsharding只能有一个shardspace。
●CompositeSharding：
这种方法用户可创建多个shardspaces，每个shardspaces中存放一定范围（range）或者列表（list）的数据。
●SubpartitionswithSharding：
Sharding基于表分区，因此子分区（Subpartitions）技术同样适用于Sharding。
在Oracle12c中，被分片的表称为shardedtable，这些shardedtable的集合称为表家族（TableFamily）。
所谓表家族（TableFamily）是指shardedtable之间存在父子关系，一个表家族中没有任何父表的表叫做根表（roottable），每个表家族中只能有一个根表。
在12.2，在一个SDB中只支持一个表家族。
在表家族中的所有shardedtable都按照相同的shardingkey来分片，主要是由根表的shardingkey决定的。
表家族中有相同shardingkey的数据存储在同一个Chunk中，这样方便以后的数据移动。
Chunk的概念和表家族密不可分。
因为表家族之间的各个表都是有关系的，因此把某个表家族的一组分区称作一个chunk。
3OracleSharding路由选择
●直接路由
应用程序初始化时，在应用层/中间件层建立连接池，连接池获取所有shard节点的shardingkey范围，并且保存在连接池中，形成shardtopologycache（拓扑缓存），Cache提供了一个快速的方法直接将请求路由到具体的shard。
客户端请求时指定shardkey，直接从连接池获取连接，这种情况下不经过shard
director/catalog数据库，直接连接到对应的shard。
●代理路由
如果客户端执行select或者DML时不指定shardkey或者执行聚合操作（比如groupby），那么请求发送到Catalog数据库，根据matadata信息，由SQL编译器决定访问哪些shards。
为了实现sharding，Oracle在连接池和驱动方面都做了增强，提供了新的API（UCP,JDBC,OCI等等）在连接创建时来传递shardingkeys。
4OracleSharding限制
根据Oracle官方描述，OracleSharding主要适用以下场景：
●面向
OLTP应用场景；
●为了优化性能应用程序应该使用分片键；
●业务场景中
80%的事务都基于单个分片操作。
OracleSharding推出的时间不长，已知的一些限制包括：
●对分片键的严重依赖；
●不支持createtable…asselect…；
●跨节点查询不支持where条件中用in或or；
●同一Schema下的分片表必须有主外键关系；
●Catalog库会成为瓶颈，业务加大会需创建多个catalog。
五、MySqlFabric
Mysql官方在2014年5月推出的MysqlFabric，意在“组织”多个MySQL服务，提供高可用和基于分片的可扩展性和负载均衡。
一般认为，MySQLFabric是一套数据库服务器场（DatabaseServerFarm）的架构管理系统。
1MysqlFabric架构
在分片环境下，需要保证客户端的数据操作发送到合适的服务器节点。
通常的做法是在应用程序和数据库服务器间增加一层Proxy或Switch（如前面介绍的PostgreSQLCitus和OracleSharding），应用程序所有对数据库的操作指令先送到proxy，再由proxy判断要转到哪个数据库。
这可以解决应用程序的维护性，但是，这个Proxy很容易成为容量及性能的瓶颈和单点故障，而且数据操作指令均需要传两次，会造成额外的负担。
MySQLFabric采用了不同的做法，把Proxy合并到各应用端的connector中，以解决单一Proxy的单点故障和性能瓶颈。
架构图如下：
2MysqlFabric构成及作用
MySQLFabric由三个部分构成：
1.MySQLFabric管理节点：
管理节点是整个架构的核心。
主要功能是管理整个数据库服务器场（DatabaseServerFarm），它启动时根据f配置文件，由它指定fabric背后当成存放ServerFarm架构和配置之repository的MySQL数据库位置、端口和连接账号等信息。
Fabric在初始化时（执行mysqlfabricmanagesetup命令），会在MySQL数据库上开一个schema（通常是名称为fabric的database），存放ServerFarm的配置相关信息，如哪些服务器组由哪些数据库构成，各服务器组中的主从服务器分别是哪些，等等。
MySQLFabric节点在设置配置时，会对ServerFarm中各数据库下达建立主从复制的命令（上图的红色线条）。
在正常运行时定期ping各组的主服务器，当发现主数据库没有正常运行时，它会启动故障转移程序，在该serverfarm的从数据库中找一个合适的提升为主服务器。
其他的从数据库则转向新的主数据库继续复制数据。
2.数据库服务器场（databaseserverfarm）
这是整个架构中的工作引擎，在传统的数据库应用中这是单一的MySQL数据库，MySQLFabric则是以多个数据库支持大数据量表（TB级以上）和高可用性数据库的需求。
这些数据库分成几个高可用组（HAGroup），每个组包含一个以上的数据库服务器，上图中最下面的几个灰色和浅蓝色的方块代表高可用组。
如果高可用组中有多个数据库，MySQLFabric会挑选（使用命令mysqlfabricgrouppromote命令）一个提升为主数据库（Master），其他数据库则成为从数据库（Slave），从数据库复制主数据库的变化，完成设定同一高可用组内的主从复制。
以后，Fabric会定期监视这个主数据库。
当主数据宕掉之后，Fabric会从高可用组内挑选一个提升为主数据库，其他的数据库会转向这个新的主数据库继续复制。
另一方面，MySQLFabric也会只是应用端的conector对这些主从数据库做读写分离，当应用程序对数据库做读写兼有的操作时，connector会将该指令提交给主数据库。
如果应用程序只会对数据库进行读操作，且连线的read_only参数设置为“ON”，则所有的查询均轮流传送到这几个数据库。
借助读写分离，应用系统的资料处理能力得以增加。
此外，如前面所述，MySQLFabric还能处理需要拆分到多个数据库服务器的表（shardingtables），每一个高可用组都可能存放shardtable的部分数据。
应用端的connector会将对shardtable的指令依MySQLFabric的管理节点的设定送到不同的高可用组，这样可使数据库的容量随着高可用组的数量增加而增长。
同时，对非拆分的表所下的指令和所有的DDL会由connector送到全局高可用组（globalgroup），全局高可用组的主数据库被MySQLFabric设置为其他高可用组的主数据库。
所有存拆分表的高可用组的主数据库复制globalgroup的变化，这么一来其他高可用组都有一份非拆分表的资料。
从而使得SQL中拆分表对非拆分表的JOIN操作变得更简单。
3.Connector
应用系统在运行时，每个SQL指令都会经由connector发送到数据库。
MySQLFabric所搭配的connector和一般使用单机的MySQL数据库一样，只是在较新版的connector是fabricawareconnector多了一些能处理数据库服务器场（databaseserverfarm）的功能。
使他们能在建立数据库连接时，以XML-RPC协议检查MySQLFabric的管理节点中serverfarm的配置，然后通过该连接下的查询可依fabric的指示送到适合的数据库。
如此一来，常见的databaseshard方案中可能造成性能瓶颈的proxy放到connector中，从而解决了这个问题。
目前MySQLFabric支持的技术有java、python、PHP，即Connector/J、Connector/Python和Connector/PHP都是Fabric-aware。
以java为例，JDBCdriver必须是Connector/J5.1.30以后的版本，Fabric的Java程序和一般对单机MySQL的查询的Java程序差不多，只是在建立databaseconnectionobject时databaseconnectionURL不是指向数据库，改为指向MySQLFabric管理节点（服务器的IP和端口通常是32274）。
当查询的表时全局表（不做tableshard）或DDL（例如建表或改表结构）时，建立connectionobject的要加上'
'
fabricServerGroup="
参数，之后通过这个connectionobject所下的SQL指令会送到GlobalGroup的主数据库，再由数据库复制到其他的高可用组（shard）中。
如果SQL命令所要操作的表时分区表（shardtable），则建立connectionobject时要在参数加上'
fabricShardTable="
参数，之后通过这个connectionobject所下的SQL命令会根据MySQLFabric所设定的分表（shard）原则送到各分区（shard）的高可用组。
这样一来，应用程序对这些shardtable下的SQL指令时，不需要在SQL中判断要送到哪个数据库，完全由connector在建立数据库连接时向MySQLFabric所查到的serverfarm的配置信息（哪个数据库属于哪个shardgroup，各shardtable的拆分原则等）所决定。
而且这个配置在建立主连接后就缓存在Connector所在的应用端。
这样，在每次下SQL指令时就不需要重复查询MySQLFabric管理节点，而依存于应用端的分表配置直接送到正确的数据库。
而应用程序的效率不会因为做了表的拆分而有任何降低。
3MysqlFabric限制
MySQLFabric的功能也不是很完善，已知的限制包括：
●采取了异步复制方案，但复制延迟比较明显；
●自增长键不能作为分片的键；
●事务中更新的数据不能跨分片，查询语句返回的数据也不能跨分片；
●若有涉及跨分片的事务、查询需求，须由应用程序解决。
六、分库、分片中间件MyCat
1MyCat简介
从定义和分类来看，MyCat是一个开源的分布式数据库系统，是一个实现了MySQL协议的Server，前端用户可以把它看做是一个数据库代理，用MySQL客户端工具和命令行访问，而其后端可以用MySQL原生（Native）协议与多个MySQL服务器通信，也可以用JDBC协议与大多数主流数据库服务器通信，其核心功能是分库分表，即将一个大表水平分割为N个小表，存储在后端MySQL服务器里或者其他数据库里。
MyCat本身不存储数据，其原理可用“拦截”一词形容，它拦截用户发送的SQL语句，首先对SQL语句做一些特定的分析，如分片分析、路由分析、读写分离分析、缓存分析等，然后将此sql发往后端的真实数据库，并将返回的结果做适当处理，最终返回给用户。
MyCat的经典应用场景包括：
●单纯的读写分离：
此时配置极为简单，支持读写分离、主从切换；
●多租户应用：
每个应用一个库，但应用程序只连接Mycat，无须改造程序；
●报表系统：
借助于Mycat的分表能力，处理大规模报表的统计；
●替代Hbase：
用于分析大数据；
●海量数据实时查询有效替代方案：
在海量数据中进行实时查询（除了基于主键的查询，还包括范围查询或其他属性查询）时，Mycat可能是最简单有效的选择。
2MyCat的基本概念
首先介绍MyCat的一些基本概念：
●逻辑库（Schema）：
在物理上由一个独立或共享的多个数据库组成，但对应用而言进行任何操作只针对一个逻辑数据库；
●逻辑表（table）：
与逻辑库同理，可以是多个分片表，也可以是一个非分片表；
●ER表：
基于实体关系（E-R）模型，MyCat将子表与父表按同一分片策略进行分片，通过表分组（TableGroup）保证符合ER模型的数据Join不会跨库操作。
●分片节点（dataNode）：
数据切分后，一个大表被分到不同的分片数据库，每个表分片所在的数据库就是分片节点（dataNode）。
●节点主机（dataHost）：
数据切分后，每个分片节点（dataNode）不一定都会独占一台机器，同一机器上面可以有多个分片数据库，这样一个或多个分片节点（dataNode）所在的机器就是节点主机（dataHost）。
●数据源（dataSource）：
某个物理库的访问地址，用于捆绑到dataNode上；
●分片规则：
按照某种业务规则把数据分到某个分片的规则就是分片规则，数据切分选择合适的分片规则非常重要，将极大的避免后续数据处理的难度。
3MyCat的配置文件
MyCat依靠三个配置文件：
rule.xml,schema.xml和server.xml来实现分库。
●rule.xml配置文件
该文件主要定义了分片的规则，这个文件里面主要有tableRule和function这两个标签。
在
升级会员 