数据库Sharding的基本思想和切分策略

标签: 数据库 sharding 思想 | 发表时间:2014-09-17 00:24 | 作者:yaochunhui_1986
出处:http://www.iteye.com

本文着重介绍sharding的基本思想和理论上的切分策略,关于更加细致的实施策略和参考事例请参考我的另一篇博文: 数据库分库分表(sharding)系列(一) 拆分实施策略和示例演示 

 

一、基本思想

      Sharding的基本思想就要把一个数据库切分成多个部分放到不同的数据库(server)上,从而缓解单一数据库的性能问题。不太严格的讲,对于海量数据的数据库,如果是因为表多而数据多,这时候适合使用垂直切分,即把关系紧密(比如同一模块)的表切分出来放在一个server上。如果表并不多,但每张表的数据非常多,这时候适合水平切分,即把表的数据按某种规则(比如按ID散列)切分到多个数据库(server)上。当然,现实中更多是这两种情况混杂在一起,这时候需要根据实际情况做出选择,也可能会综合使用垂直与水平切分,从而将原有数据库切分成类似矩阵一样可以无限扩充的数据库(server)阵列。下面分别详细地介绍一下垂直切分和水平切分.

      垂直切分的最大特点就是规则简单,实施也更为方便,尤其适合各业务之间的耦合度非
常低,相互影响很小,业务逻辑非常清晰的系统。在这种系统中,可以很容易做到将不同业
务模块所使用的表分拆到不同的数据库中。根据不同的表来进行拆分,对应用程序的影响也
更小,拆分规则也会比较简单清晰。(这也就是所谓的”share nothing”)。



      水平切分于垂直切分相比,相对来说稍微复杂一些。因为要将同一个表中的不同数据拆
分到不同的数据库中,对于应用程序来说,拆分规则本身就较根据表名来拆分更为复杂,后
期的数据维护也会更为复杂一些。



      让我们从普遍的情况来考虑数据的切分:一方面,一个库的所有表通常不可能由某一张表全部串联起来,这句话暗含的意思是,水平切分几乎都是针对一小搓一小搓(实际上就是垂直切分出来的块)关系紧密的表进行的,而不可能是针对所有表进行的。另一方面,一些负载非常高的系统,即使仅仅只是单个表都无法通过单台数据库主机来承担其负载,这意味着单单是垂直切分也不能完全解决问明。因此多数系统会将垂直切分和水平切分联合使用,先对系统做垂直切分,再针对每一小搓表的情况选择性地做水平切分。从而将整个数据库切分成一个分布式矩阵。

 

二、切分策略

      如前面所提到的,切分是按先垂直切分再水平切分的步骤进行的。垂直切分的结果正好为水平切分做好了铺垫。垂直切分的思路就是分析表间的聚合关系,把关系紧密的表放在一起。多数情况下可能是同一个模块,或者是同一“聚集”。这里的“聚集”正是领域驱动设计里所说的聚集。在垂直切分出的表聚集内,找出“根元素”(这里的“根元素”就是领域驱动设计里的“聚合根”),按“根元素”进行水平切分,也就是从“根元素”开始,把所有和它直接与间接关联的数据放入一个shard里。这样出现跨shard关联的可能性就非常的小。应用程序就不必打断既有的表间关联。比如:对于社交网站,几乎所有数据最终都会关联到某个用户上,基于用户进行切分就是最好的选择。再比如论坛系统,用户和论坛两个模块应该在垂直切分时被分在了两个shard里,对于论坛模块来说,Forum显然是聚合根,因此按Forum进行水平切分,把Forum里所有的帖子和回帖都随Forum放在一个shard里是很自然的。

      对于共享数据数据,如果是只读的字典表,每个shard里维护一份应该是一个不错的选择,这样不必打断关联关系。如果是一般数据间的跨节点的关联,就必须打断。

 

      需要特别说明的是:当同时进行垂直和水平切分时,切分策略会发生一些微妙的变化。比如:在只考虑垂直切分的时候,被划分到一起的表之间可以保持任意的关联关系,因此你可以按“功能模块”划分表格,但是一旦引入水平切分之后,表间关联关系就会受到很大的制约,通常只能允许一个主表(以该表ID进行散列的表)和其多个次表之间保留关联关系,也就是说:当同时进行垂直和水平切分时,在垂直方向上的切分将不再以“功能模块”进行划分,而是需要更加细粒度的垂直切分,而这个粒度与领域驱动设计中的“聚合”概念不谋而合,甚至可以说是完全一致,每个shard的主表正是一个聚合中的聚合根!这样切分下来你会发现数据库分被切分地过于分散了(shard的数量会比较多,但是shard里的表却不多),为了避免管理过多的数据源,充分利用每一个数据库服务器的资源,可以考虑将业务上相近,并且 具有相近数据增长速率(主表数据量在同一数量级上)的两个或多个shard放到同一个数据源里,每个shard依然是独立的,它们有各自的主表,并使用各自主表ID进行散列,不同的只是它们的散列取模(即节点数量)必需是一致的。(

本文着重介绍sharding的基本思想和理论上的切分策略,关于更加细致的实施策略和参考事例请参考我的另一篇博文: 数据库分库分表(sharding)系列(一) 拆分实施策略和示例演示 


1.事务问题:
解决事务问题目前有两种可行的方案:分布式事务和通过应用程序与数据库共同控制实现事务下面对两套方案进行一个简单的对比。
方案一:使用分布式事务
    优点:交由数据库管理,简单有效
    缺点:性能代价高,特别是shard越来越多时
方案二:由应用程序和数据库共同控制
     原理:将一个跨多个数据库的分布式事务分拆成多个仅处
           于单个数据库上面的小事务,并通过应用程序来总控
           各个小事务。
     优点:性能上有优势
     缺点:需要应用程序在事务控制上做灵活设计。如果使用   
           了spring的事务管理,改动起来会面临一定的困难。
2.跨节点Join的问题
      只要是进行切分,跨节点Join的问题是不可避免的。但是良好的设计和切分却可以减少此类情况的发生。解决这一问题的普遍做法是分两次查询实现。在第一次查询的结果集中找出关联数据的id,根据这些id发起第二次请求得到关联数据。

3.跨节点的count,order by,group by以及聚合函数问题
      这些是一类问题,因为它们都需要基于全部数据集合进行计算。多数的代理都不会自动处理合并工作。解决方案:与解决跨节点join问题的类似,分别在各个节点上得到结果后在应用程序端进行合并。和join不同的是每个结点的查询可以并行执行,因此很多时候它的速度要比单一大表快很多。但如果结果集很大,对应用程序内存的消耗是一个问题。

 

参考资料:

《MySQL性能调优与架构设计》

 

注:本文图片摘自《MySQL性能调优与架构设计》一 书



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [数据库 sharding 思想] 推荐:

数据库sharding

- - 数据库 - ITeye博客
当团队决定自行实现sharding的时候,DAO层可能是嵌入sharding逻辑的首选位置,因为在这个层面上,每一个DAO的方法都明确地知道需要访问的数据表以及查询参数,借助这些信息可以直接定位到目标shard上,而不必像框架那样需要对SQL进行解析然后再依据配置的规则进行路由. 另一个优势是不会受ORM框架的制约.

数据库Sharding的基本思想和切分策略

- - BlogJava-qileilove
 本文着重介绍sharding的基本思想和理论上的切分策略,关于更加细致的实施策略和参考事例请参考我的另一篇博文:. 数据库分库分表(sharding)系列(一) 拆分实施策略和示例演示.   Sharding的基本思想就要把一个数据库切分成多个部分放到不同的数据库(. server)上,从而缓解单一数据库的性能问题.

你的数据库过度 Sharding 了吗

- VonNeumann - Sky.Jian 朝阳的天空
数据库 Sharding 目前已经是数据层架构的家常便饭了,随着越来越多的人不断的通过 Sharding 技术来提升数据层的扩展能力,Sharding 本身所带来的各种弊端也开始不断的显露出来了. 最近和朋友聊天的时候针对 Sharding 带来的问题做了一些交流,记录之:. 急于 Sharding,分区键考虑不充分,影响业务发展.

数据库分库分表(sharding)系列

- - 数据库 - ITeye博客
(一) 拆分实施策略和示例演示. (三) 关于使用框架还是自主开发以及sharding实现层面的考量. (四) 多数据源的事务处理. (五) 一种支持自由规划无须数据迁移和修改路由代码的Sharding扩容方案. (一) 拆分实施策略和示例演示. 图1.数据库分库分表(sharding)实施策略图解.

方案虽好,成本先行:数据库Sharding+Proxy实践解析

- -
(葱头巴巴),PingCAP 资深解决方案架构师,前美团数据库专家、美团云 CDS 架构师、前搜狗、百度资深 DBA,擅长研究各种数据库架构,NewSQL 布道者. 本文系作者原创投稿,未经 . DBAplus社群 允许,不得擅自转载和使用. 在谈论数据库架构演变和优化时,我们经常会听到分片、分库分表(Sharding)这样的关键词,在很长一段时间内,在各个公司、各中技术论坛里都很热衷谈论各种分片方案,尤其是互联网非常普及的 MySQL 数据库.

MongoDB的分片Sharding

- - 博客园_首页
一、         分片簇综述. 分片是mongoDB扩展的一种方式. 分片分割一个collection并将不同的部分存储在不同的机器上. 当一个数据库的collections相对于当前空间过大时,你需要增加一个新的机器. 分片会自动的将collection数据分发到新的服务器上. 分片自动的均衡数据并在机器间进行负载.

基于Redis Sentinel的Redis集群(主从&Sharding)高可用方案

- - 开源软件 - ITeye博客
本文主要介绍一种通过Jedis&Sentinel实现Redis集群高可用方案,该方案需要使用Jedis2.2.2及以上版本(强制),Redis2.8及以上版本(可选,Sentinel最早出现在Redis2.4中,Redis2.8中Sentinel更加稳定),Redis集群是以分片(Sharding)加主从的方式搭建,满足可扩展性的要求;.

基于jedis、redis-sentinel的redis主从、高可用、sharding架构

- - 开源软件 - ITeye博客
最近项目上需要对Redis(目前redis用的是2.8版本)做高可用、集群等优化,就扩展了jedis客户端(MasterSlaveJedis、MasterSlaveJedisPool、ShardedMasterSlaveJedis、ShardedMasterSlaveJedisPool),以满足以下几个需求:.

kingshard--一个支持sharding的MySQL Proxy项目

- - SegmentFault 最新的文章
kingshard是一个由Go开发高性能MySQL Proxy项目,kingshard在满足基本的读写分离的功能上,致力于简化MySQL分库分表操作;能够让DBA通过kingshard轻松平滑地实现MySQL数据库扩容. 4.平滑上线DB或下线DB,前端应用无感知. kingshard sharding介绍.