kingshard简介
kingshard(https://github.com/flike/kingshard)是一个由Go开发高性能MySQL Proxy项目,kingshard在满足基本的读写分离的功能上,致力于简化MySQL分库分表操作;能够让DBA通过kingshard轻松平滑地实现MySQL数据库扩容。
主要功能:
|
|
kingshard sharding介绍
现在开源的MySQL Proxy已经有几款了,并且有的已经在生产环境上广泛应用。但这些proxy在sharding方面,都是不能分子表的。也就是说一个node节点只能分一张表。但我们的线上需求通常是这样的:
我有一张非常大的表,行数超过十亿,需要进行拆分处理。假设拆分因子是512。
如果采用单node单数据库的分表方式,那其实这512个子表还是存在一个物理节点上,意义不大。
如果采用他们的sharding功能,就需要512个物理节点,也不现实。
面对这种需求,现有的proxy就不能很好地满足要求了。通常我们希望将512张子表均分在几个MySQL节点上,从而达到系统的横向扩展。
然而kingshard较好地实现了这种典型的需求。简单来说,kingshard的分表方案采用两级映射的方式:
|
|
sharding支持的操作
目前kingshard sharding支持insert, delete, select, update和replace语句, 所有这五类操作都支持跨子表。但写操作仅支持单node上的跨子表,select操作则可以跨node,跨子表。
sharding方式
range方式
基于整数范围划分来得到子表下标。该方式的优点:基于范围的查询或更新速度快,因为查询(或更新)的范围有可能落在同一张子表中。这样可以避免全部子表的查询(更新)。缺点:数据热点问题。因为在一段时间内整个集群的写压力都会落在一张子表上。此时整个mysql集群的写能力受限与单台mysql server的性能。并且,当正在集中写的mysql 节点如果宕机的话,整个mysql集群处于不可写状态。基于range方式的分表字段类型受限。
hash方式
kingshard采用(shardKey%子表个数)的方式得到子表下标。优点:数据分布均匀,写压力会比较平均地落在后端的每个MySQL节点上,整个集群的写性能不会受限于单个MySQL节点。并且当某个分片节点宕机,只会影响到写入该节点的请求,其他节点的写入请求不受影响。分表字段类型不受限。因为任何一个类型的分表字段,都可以通过一个hash函数计算得到一个整数。缺点:基于范围的查询或更新,都需要将请求发送到全部子表,对性能有一定影响。但如果不是基于范围的查询或更新,则性能不会受到影响。
sharding相关的配置介绍
在配置文件中,有关sharding设置是通过scheam设置:
`
schemas :
|
|
`
一个kingshard实例只能有一个schemas,从上面的配置可以看出,schema可以分为三个部分:
|
|
kingshard架构图
基于kingshard的子表迁移方案
通过kingshard可以非常方便地动态迁移子表,从而保证MySQL节点的不至于负载压力太大。大致步骤如下所述:
- 通过自动数据迁移工具开始数据迁移。
- 数据差异小于某一临界值,阻塞老子表写操作(read-only)
- 等待新子表数据同步完毕
- 更改kingshard配置文件中的对应子表的路由规则。
- 删除老节点上的子表。
Exaple
简单演示一下kingshard的相关操作,感兴趣的同学可以自己试一试。:)
|
|
反馈
目前kingshard还是1.0版本,比较核心的功能已经实现了。但还有很多地方不完善。如果您在使用kingshard的过程中发现BUG或者有新的功能需求,非常欢迎您发邮件至flikecn#126.com与作者取得联系,或者加入QQ群(147926796)交流。