转：浅谈高性能数据库集群: 分库分表

时间 2019-11-11

标签浅谈高性能数据库集群分库分表栏目 SQL 繁體版

原文原文链接

https://www.toutiao.com/i6573966496777634312/算法

本文主要介绍高性能数据库集群分库分表相关理论，基本架构，涉及的复杂度问题以及常看法决方案。数据库

分库分表概述

基本思想：

把一个数据库切分红多个部分放到不一样的数据库服务器(server)上，从而缓解单一数据库的性能问题。缓存

单台数据库的瓶颈：

数据量太大，读写性能降低，即便有索引，索引变的很大，性能一样降低；
数据文件变的很大，数据库的备份和恢复须要消耗很长时间；
数据文件越大，极端状况下丢失数据的风险越高；

读写分离分散数据库读写操做压力，分库分表分散存储压力服务器

适用场景

分库分表是在肯定没有其余优化空间以后，才采起的方案；微信

优化顺序:架构

硬件优化；
数据库调优，例如增长索引，优化慢查询；
引入缓存，减小数据库压力；
程序与数据库表优化、重构；
读写分离或分库分表；

相似读写分离，分库分表也是肯定没有其余优化空间以后才采起的优化方案。那若是业务真的发展很快岂不是很快要进行分库分表了？那为什么不一开始就设计好呢？性能

按照架构设计的“三原则”（简单原则，合适原则，演化原则），简单分析一下：优化

首先，这里的“若是”事实上发生的几率比较低，作10个业务有一个业务能活下去就很不错了，更况且快速发展，和中彩票的几率差很少。若是咱们每一个业务上来就按照淘宝、微信的规模去作架构设计，不但会累死本身，还会害死业务。架构设计

其次，若是业务真的发展很快，后面进行分库分表也不迟。由于业务发展好，相应的资源投入就会加大，能够投入更多的人和更多的钱，那业务分库带来的代码和业务复杂问题就能够经过加人来解决，成本问题也能够经过增长资金来解决。设计

业务分库

业务分库的基本思想：

按照业务模块将数据将数据分散到不一样的数据库服务器。

分库带来的问题：

一、join操做

问题：数据库分散在不一样的数据库中，没法作join查询。

解决：经过业务代码进行join查询，而后结果合并。

二、事务

问题：表分散在不一样的数据库中，没法经过事务统一修改。

解决：经过业务代码实现。

三、成本

服务器成本、开发成本。

业务分库示意图：

业务分表

业务分表的基本思想：

将单表切分红多个不一样的表。

业务分表的拆分方式：

一、垂直拆分：基于列字段进行拆分，拆分后的表结构不同。

二、水平拆分：基于数据记录进行拆分，拆分后的表结构同样。

业务分表示意图：

带来的问题

一、垂直分表：

增长表操做的次数

二、水平分表

路由问题：

某条数据具体属于哪一个切分获得子表，须要增长路由算法进行计算，这个算法会致使必定的复杂性。

解决方案：

一、范围路由

选取有序的数据做为路由条件，不一样分段分散到不一样的数据表中。

优势：能够随着数据的增长平滑地扩充新的表。

缺点：可能存在数据分布不均匀。

二、Hash路由

选择某个列（或者几个列的组合）的值进行Hash运算，而后根据运算结果分散到不一样的数据库表中。

优势：表数据分布比较均匀。

缺点：初始表数量很差选取，扩充新的表数据须要从新分布。

三、配置路由

使用独立的表（或者配置文件等）记录路由配置信息。

优势：使用起来简单灵活，扩充表时只须要迁移指定的数据，而后修改路由表。

缺点：路由表自己太多影响系统总体性能。

数据库操做问题

一、join操做

问题：数据分散在不一样的数据库中，没法作join查询。

解决：经过业务代码join查询，而后结果合并。

二、count操做

问题：数据分散在不一样的数据库中，没法作count()操做。

解决：

（1）count相加

在业务代码或者数据库中间件对每一个表进行count操做，而后将结果相加。

优势：实现简单。

缺点：性能较低。

（2）记录数表

新建一张表，保存数据记录的数量，每次插入和删除子表数据成功后，都更新记录数表。

优势：性能较好。

缺点：实现复杂。

三、order by操做

问题：数据分散在不一样的数据库中，没法作order by操做。

解决：业务代码实现或者中间件查询每一个子表中的数据，而后汇总进行排序。

实现方法

实现方法：

程序代码封装；
中间件封装；

相似读写分离，具体实现也是“程序代码封装”和“中间件封装”，但具体实现复杂一些，由于还有要判断SQL中具体操做的表，具体操做(例如count、order by、group by等)，根据具体操做作不一样的处理。