数据库控制：何时使用分片？ 支撑大体量数据的例子

1 简介

数据库的数据量达到一定程度之后，为避免带来系统性能上的瓶颈。 需要进行数据的处理，采用的手段是分区、分片、分库、分表。

分片策略，分片也叫做Sharding，或是水平分库分表，都是相同的概念，与上面所讲到的水平分表的概念类似，唯一不同点就在于将这些拆分出来的子表保存在不同的数据库服务器中

	RANGE：按照范围划分，比如按照日期或者自增键进行范围划分。
	HASH： 采用 hash+mod 的组合划分数据。

2 分片实现方式

• 客户端：

在客户端实现分片，如比较流行的分库分表框架Sharding-JDBC，就是在驱动层实现了分片功能，对上层应用保持透明。

• 中间层：

通过在应用与DB之间接入中间件(Proxy)，如DBLE、MaxScale等开源中间件，用于实现后端数据分片与路由查询，对上层应用保持透明。

• 服务端：

使用某些分布式数据库，如TiDB、SequoiaDB等开源NewSQL，其在存储引擎层实现了数据分片功能，对上层应用保持透明。

分片能够有效的缓解单机、单库、单表的性能瓶颈，突破IO、连接数、硬件资源等瓶颈。但是我们一旦将数据分片后，那么整个数据库架构就转换成了分布式架构，也会引发诸多问题：

• 分布式事务:

数据分片后，原先的本地事务就演变成了分布式事务了，一般需要通过二阶段或三阶段提交来保证分布式事务的ACID特性，性能也因此会有一定损耗。

• 跨库join:

分库分表后，不同的表分布在不同的服务器上，所以无法直接通过sql join来进行查询，这时候通常会建立冗余字段或全局表来实现跨库join。

• SQL问题:

数据分片后，SQL的运行需要分发到各个节点计算，然后将结果合并后再返回，性能会有所下降。

并且当SQL较为复杂时，结果准确性也有可能出现问题。

这个问题也是数据分片实现中最为关键的点，只能不断优化完善，无法完全解决。

• 自增主键:

数据分片后，我们将不能再依赖数据库自身的自增键生成机制，需要配置额外的全局序列来保证自增主键的全局唯一。

分片（Sharding）会为数据库维护和业务逻辑带来一系列复杂性和性能损耗，所以除非业务量大到万不得已，否则切莫过度设计、过早优化。

3 小结

面对数据库性能问题，我们可以先尝试用以下方式来解决：

	数据优化：优化SQL、索引及相关数据库参数配置。

	硬件扩展：提升服务器CPU、内存、磁盘IOPS等硬件配置。

	读写分离：通过读写分离架构提高数据库的整体性能。

	数据拆分：通过垂直拆分库表，或水平分表来解决大表性能问题

如果上述方式仍未能奏效，才考虑最复杂的方案：数据分片.