数据库分片知识分享Word格式.docx
- 文档编号:16649305
- 上传时间:2022-11-25
- 格式:DOCX
- 页数:12
- 大小:142.12KB
数据库分片知识分享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这两个标签。
在
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 数据库 分片 知识 分享