共勉
"诸君离学校而去了。在社会上立身的困难,恐怕比在学校里求学还要加甚。若非立志奋斗,则以前所受的教育,反足以增加人生的苦恼,或转为堕落的工具。这是诸君所当特别注意的。事业的成功,须经过长时间的辛苦艰难——成功的代价,走过了许多荆棘的路,方才能寻获康庄大道。立志是砍荆棘斧斤,奋斗是劳力。万不可希望以最少的劳力,获最大的成功。" -- 蒋梦麟
Knight's Blog
滴滴海浪技术主管, 前百度资深研发工程师,现居上海。 擅长于大规模的系统平台服务架构。在

- 亿级别搜索平台(sov5.cn)
- 大规模分布式爬虫
- 中间件架设(disconf,CanalX)
- 广告平台(百度联盟广告)
- 租车平台(滴滴租车)
- 语言招聘平台(51tra.com)
- 内容平台(100weidu.com)
- 社区平台(python88.com)
- 资源下载平台(misou.com)
- 计算机图形图像技术(一篇一作)
- 机器学习(一篇一作)

等领域具有颇有经验。
联系方式: knightliao AT gmail.com
联系
Knight's Blog » 工作

分布式 数据库表 sharding 综述

2015-08-20 08:33

数据库表 sharding 综述

数据库sharding

基本思路

  • 表多:垂直划分
  • 表不多但表的数据很多:水平划分

切分策略

先垂直后水平

  • 垂直:“聚集“,聚合
  • 水平:聚合根

举例:

  • 社交网站:根据用户区分
  • 论坛:
    • 垂直shard:用户和论坛
    • 水平shard:Form是聚合根

Tips:

  • 只读字典或变化较小的表:每个shard里维护一份,可以加速读取速度(join)
  • 同时进行垂直和水平切分时,在垂直方向上的切分将不再以“功能模块”进行划分,而是需要更加细粒度的垂直切分,而这个粒度与领域驱动设计中的“聚合”概念不谋而合,甚至可以说是完全一致,每个shard的主表正是一个聚合中的聚合根!
  • 这样切分下来你会发现数据库分被切分地过于分散了(shard的数量会比较多,但是shard里的表却不多),为了避免管理过多的数据源,充分利用每一个数据库服务器的资源,可以考虑将业务上相近,并且具有相近数据增长速率(主表数据量在同一数量级上)的两个或多个shard放到同一个数据源里,每个shard依然是独立的,它们有各自的主表,并使用各自主表ID进行散列,不同的只是它们的散列取模(即节点数量)必需是一致的。

问题

  • 事务问题
    • 使用分布式事务
      • 优点:交由数据库管理,简单有效
      • 缺点:性能代价高,特别是shard越来越多时
    • 由应用程序和数据库共同控制
      • 将一个跨多个数据库的分布式事务分拆成多个仅处 于单个数据库上面的小事务,并通过应用程序来总控 各个小事务。
      • 优点:性能上有优势
      • 缺点:需要应用程序在事务控制上做灵活设计。如果使用
        了spring的事务管理,改动起来会面临一定的困难。
  • 跨节点Join的问题
    • 只要是进行切分,跨节点Join的问题是不可避免的。但是良好的设计和切分却可以减少此类情况的发生。解决这一问题的普遍做法是分两次查询实现。在第一次查询的结果集中找出关联数据的id,根据这些id发起第二次请求得到关联数据。
  • 跨节点的count,order by,group by以及聚合函数问题
    • 这些是一类问题,因为它们都需要基于全部数据集合进行计算。多数的代理都不会自动处理合并工作。解决方案:与解决跨节点join问题的类似,分别在各个节点上得到结果后在应用程序端进行合并。和join不同的是每个结点的查询可以并行执行,因此很多时候它的速度要比单一大表快很多。但如果结果集很大,对应用程序内存的消耗是一个问题。

拆分实施策略和示例演示

image

准备阶段

领域模型

分析阶段

  • 垂直切分
  • 水平切分
    • 垂直切分后,需要对shard内表格的数据量和增速进一步分析,以确定是否需要进行水平切分
      • 若划分到一起的表格数据增长缓慢,在产品上线后可遇见的足够长的时期内均可以由单一数据库承载,则不需要进行水平切分
      • 若划分到一起的表格数据量巨大,增速迅猛,需要进一步进行水平分割
        • 结合业务逻辑和表间关系,将当前shard划分成多个更小的shard,通常情况下,这些更小的shard每一个都只包含一个主表(将以该表ID进行散列的表)和多个与其关联或间接关联的次表。这种一个shard一张主表多张次表的状况是水平切分的必然结果。
        • 这样切分下来,shard数量就会迅速增多。如果每一个shard代表一个独立的数据库,那么管理和维护数据库将会非常麻烦,而且这些小shard往往只有两三张表,为此而建立一个新库,利用率并不高,因此,在水平切分完成后可再进行一次“反向的Merge”,即:将业务上相近,并且具有相近数据增长速率(主表数据量在同一数量级上)的两个或多个shard放到同一个数据库上,在逻辑上它们依然是独立的shard,有各自的主表,并依据各自主表的ID进行散列,不同的只是它们的散列取模(即节点数量)必需是一致的。这样,每个数据库结点上的表格数量就相对平均了。
      • 所有表格均划分到合适的shard之后,所有跨越shard的表间关联都必须打断,在书写sql时,跨shard的join、group by、order by都将被禁止,需要在应用程序层面协调解决这些问题。

实施阶段

如果项目在开发伊始就决定进行分库分表,则严格按照分析设计方案推进即可。如果是在中期架构演进中实施,除搭建实现sharding逻辑的基础设施外(关于该话题会在下篇文章中进行阐述),还需要对原有SQL逐一过滤分析,修改那些因为sharding而受到影响的sql.

全局主键生成策略

一些常见的主键生成策略

  • UUID
    • 索引慢问题
  • Sequence表:
    • nextId
    • tableName
    • 单点问题:使用master-slave
    • 访问压力问题:暂没有好的解决方案

一种极为优秀的主键生成策略

flickr

常见分库方式

无单一主键生成方式

假设分成N个 shard,那么 为每个shard的表采用 auto increase N 方式.

  • 优点:不必使用主键生成中间件
  • 缺点:
    • 由于是在数据库上进行increase控制,因此 扩展非常困难,迁移数据很坑爹
    • 无法生成连续ID

单一主键生成方式

使用某种主键中间件生成主键,通过hash取余将数据分配。

  • 优点:可以生成连续ID,在迁移时比“无单一主键生成方式”稍微简单
  • 缺点:迁移困难

单一主键生成方式 + 路由表

使用某种主键中间件生成主键,随机散列到shard里,将关联关系放到 路由表里

  • 优点:没有迁移问题
  • 缺点:路由表将成为瓶颈
    • 改进方式:将路由表读取通过分布式缓存进行控制(解决读慢的问题),但还是无法解决写的压力(多次写和数据库表大引起的写压力)

增量区间进行路由

按增量区间进行路由(如每1千万条数据或是每一个月的数据存放在一个节点上 ),虽然可以避免数据的迁移,却有可能带来“热点”问题,也就是近期系统的读写都集中在最新创建的节点上(很多系统都有此类特点:新生数据的读写频率明显高于旧有数据),从而影响了系统性能。面对这种两难的处境,Sharding扩容显得异常困难。

散列路由 + 增量区间路由

常见路由层算法实现

  • DAO层实现:大部分技术团队采用
    • 优点:快速、简单
    • 缺点:与业务代码耦合
  • 在ORM框架层实现
    • 实现O-R Mapping的前提下同时提供sharding支持
  • 在JDBC API层实现:实现难度大
  • 在介于DAO与JDBC之间的Spring数据访问封装层实现:
    • 优点:spring提供了很多方便的连接管理
  • 在应用服务器与数据库之间通过代理实现

多数据源的事务处理

  • 分布式事务:两阶段提交
  • 基于Best Efforts 1PC模式的事务
  • 事务补偿机制: pikaq
2346 次点击