从 Shard 到 Sharding
Shard这个词英文的意思是碎片而作为数据库相关的技术用语似乎最早见于大型多人在线角色扮演游戏(MMORPG)中的Sharding 姑且称之为分片
Sharding 不是一门新技术而是一个相对简朴的软件理念如您所知MySQL 之后才有了数据表分区功能那么在此之前很多 MySQL 的潜在用户都对 MySQL 的扩展性有所顾虑而是否具备分区功能就成了衡量一个数据库可扩展性与否的一个关键指标(当然不是唯一指标)数据库扩展性是一个永恆的话题MySQL 的推广者经常会被问到如在单一数据库上处理应用数据捉襟见肘而需要进行分区化之类的处理是如何办到的呢? 答案是Sharding
Sharding 不是一个某个特定数据库软件附属的功能而是在具体技术细节之上的抽象处理是水平扩展(Scale Out亦或横向扩展向外扩展)的解决方案其主要目的是为突破单节点数据库服务器的 I/O 能力限制解决数据库扩展性问题
事关数据库扩展性
说起数据库扩展性这是个非常大的话题目前的商业数据都有自己的扩展性解决方案在过去相对来说比较成熟但是随着互联网的高速发展不可避免的会带来一些计算模式上的演变这样很多主流商业系统也难免暴露出一些不足之处比如 Oracle 的 RAC 是采用共享存储机制对于 I/O 密集型的应用瓶颈很容易落在存储上这样的机制决定后续扩容只能是 Scale Up(向上扩展) 类型对于硬件成本开发人员的要求维护成本都相对比较高
Sharding 基本上是针对开源数据库的扩展性解决方案很少有听说商业数据库进行 Sharding 的目前业界的趋势基本上是拥抱 Scale Out逐渐从 Scale Up 中解放出来
Sharding 的应用场景
任何技术都是在合适的场合下能发挥应有的作用 Sharding 也一样联机游戏IMBSP 都是比较适合 Sharding 的应用场景其共性是抽象出来的数据对象之间的关联数据很小比如IM每个用户如果抽象成一个数据对象完全可以独立存储在任何一个地方数据对象是 Share Nothing 的再比如 Blog 服务提供商的站点内容基本为用户生成内容(UGC)完全可以把不同的用户隔离到不同的存储集合而对用户来说是透明的
这个 Share Nothing是从数据库集群中借用的概念举例来说有些类型的数据粒度之间就不是 Share Nothing 的比如类似交易记录的历史表信息如果一条记录中既包含卖家信息与买家信息如果随着时间推移买卖家会分别与其他用户继续进行交易这样不可避免的两个买卖家的信息会分布到不同的 Sharding DB 上而这时如果针对买卖家查询就会跨越更多的 Sharding 开销就会比较大
Sharding 并不是数据库扩展方案的银弹也有其不适合的场景比如处理事务型的应用就会非常复杂对于跨不同DB的事务很难保证完整性得不偿失所以采用什么样的 Sharding 形式不是生搬硬套的
Sharding与数据库分区(Partition)的区别
有的时候Sharding 也被近似等同于水平分区(Horizontal Partitioning)网上很多地方也用 水平分区来指代 Sharding但我个人认为二者之间实际上还是有区别的的确Sharding 的思想是从分区的思想而来但数据库分区基本上是数据对象级别的处理比如表和索引的分区每个子数据集上能够有不同的物理存储属性还是单个数据库范围内的操作而 Sharding 是能够跨数据库甚至跨越物理机器的
[] []