你的数据库过度 Sharding 了吗

数据库 Sharding 目前已经是数据层架构的家常便饭了，随着越来越多的人不断的通过 Sharding 技术来提升数据层的扩展能力，Sharding 本身所带来的各种弊端也开始不断的显露出来了。最近和朋友聊天的时候针对 Sharding 带来的问题做了一些交流，记录之：

1. 急于 Sharding，分区键考虑不充分，影响业务发展

Sharding 本身是一个需要慎重对待的事情，尤其是分区键的选择。好的分区键会让整个系统基本上对应用没有影响，但是如果选择了一个不合适的分区键，就可能给应用程序带来巨大的麻烦，甚至让有些功能变得几乎不可实现。因为不合适的分区键可能会让本来需要 分组/排序/连接 的数据被拆分分到不同的物理节点，迫使很多原本在一个 Instance 内部的简单处理都无法完成，不得不让应用程序进行大批量IO运算，反而增大的处理成本。应用程序的开发成本上升了，开发效率下降了，业务发展可能就受阻了。

2. 过于 Sharding，单机性能过低，造成节点数量过大，维护成本倍增

从与一些 DBA 朋友们的交流中了解到，过度 Sharding 也是现在非常常见的一个问题。由于 MySQL 的免费，大家就觉得节点的增加成本较低，扩充节点的性价比非常高，因为不用像 Oracle 那样需要按照 CPU 个数来付 Licence 费用嘛。

但事实真的如此吗？可能并不是这么简单。首先，在很多人的意识中，扩展成本只是一个节点的购买成本，而忽略了该节点所占用的IDC资源（机架/电力/布线…）。如果从 IDC 资源角度来考虑，单机性能越高，成本也越低。也就是说节点数越少，IDC 资源消耗也越少（曾今就由朋友说笑：我们使用一台大型机搞定所有业务，成本一定是最低的）。那这就和我们的 Sharding 方向相违背了不是？毕竟单节点的扩展能力一定是有限的嘛，咱也不可能真整一台大型机是吧 。

除了显性的财务支持成本， Sharding 同时也给运维工作带来了维护成本的增加。节点数多了，需要维护的机器也就增多了，一个节点发生故障的概率也增加了。维护变更的重复工作量增大了，操作失误的可能性也就增大了。所以我们又不得不考虑平衡节点数和单机性能。

这时候我们就不得不考虑，到底我们该 Sharding 到何种程度，才能既有效的提升了Scale Out能力，又能控制总体成本尽可能低。既能让维护成本可控，又能分散可用性故障点。

3. 为了 Sharding 而 Sharding

“Sharding 如此流行，要事咱的数据层不做 Sharding，都不好意思见人了”，很多架构师/DBA可能都有此想法。在还没有弄清楚 Sharding 的好处与弊端的时候，在系统都还没有一点压力的时候，甚至都还不清楚为何要 Sharding 的时候就开始做 Sharding 了，最终很可能就将自己埋葬在 Sharding 中了。

您可能也喜欢：

数据水平切分的主键全局唯一方案

核心业务系统数据库平台迁移： Oracle -> MySQL

不要过度迷信小型机

管理数据库链接

无觅