数据库分库分表中间件 数据库为什么要分库分表

很多朋友对于数据库分库分表中间件和数据库为什么要分库分表不太懂，今天就由小编来为大家分享，希望可以帮助到大家，下面一起来看看吧！

分库分布的几件小事(一)数据库如何拆分

1.为什么要分库分表

①分库分表说白了，就是因为数据量太大了，如果你的单表数据量都到了千万级别，那么你的数据库就无法承受高并发的要求，数据库操作性能就会出现极大的下降。

②数据库并发量太大了，一般而言，一个数据库最多支撑并发到2000，这时候一定要进行扩容，不然性能会出现严重下降。而且一个健康的单库并发值你最好保持在每秒1000左右，不要太大。那么你可以将一个库的数据拆分到多个库中，访问的时候就访问一个库好了。

2.有哪些分库分布中间件

比较常见的中间件有cobar、TDDL、atlas、sharding-jdbc、mycat。

①cobar：阿里b2b团队开发和开源的，属于proxy层方案。已经好几年没有进行更新了，基本没啥人用。而且不支持读写分离、存储过程、跨库join和分页等操作。

②TDDL:淘宝团队开发的，属于client层方案，不支持join，但是支持读写分离。目前使用的也不多，因为还依赖淘宝的diamond配置管理系统。

③atlas：360开源的，属于proxy层方案，以前有一些公司在用，但是已经好几年没有更新了，所以现在用的也不多。

④sharding-jdbc：当当开源的，属于client层方案。SQL语法支持多，没有太多的限制，从2.0版本开始支持分库分表、读写分离、分布式id生成、柔性事务(最大努力送达型事务、TCC事务)。而且现在使用较多。

⑤myCat：基于cobar改造，属于proxy层方案，支持的功能完善，而且目前应该是非常火的而且不断流行的数据库中间件，社区很活跃，也有一些公司开始在用了。

3.分布式中间件类型

①proxy类型

proxy类型的中间件就是一个客户端，需要直接部署一个中间件，去进行分库分表。服务端将sql发送到中间件客户端去进行不同表库的操作。如果中间件客户端不可用将直接导致无法进行分库分表，而且要走网络耗时。

②client

client不需要单独部署中间件客户端，运维成本低，中间件就是一个jar包，直接在项目中导入、配置就可以完成分库分表，而且不需要代理层的二次转发，性能高点，但是遇到升级等操作需要重新发布版本，各个系统都需要耦合sharding-jbdc的依赖。

4.垂直拆分与水平拆分

①垂直拆分

垂直拆分的意思，就是把一个有很多字段的表给拆分成多个表，或者是多个库上去。每个库表的结构都不一样，每个库表都包含部分字段。一般来说，会将较少的访问频率很高的字段放到一个表里去，然后将较多的访问频率很低的字段放到另外一个表里去。因为数据库是有缓存的，你访问频率高的行字段越少，就可以在缓存里缓存更多的行，性能就越好。这个一般在表层面做的较多一些。

这个其实挺常见的，不一定我说，大家很多同学可能自己都做过，把一个大表拆开，订单表、订单支付表、订单商品表。

②水平拆分

水平拆分的意思，就是把一个表的数据给弄到多个库的多个表里去，但是每个库的表结构都一样，只不过每个库表放的数据是不同的，所有库表的数据加起来就是全部数据。水平拆分的意义，就是将数据均匀放更多的库里，然后用多个库来抗更高的并发，还有就是用多个库的存储容量来进行扩容。

③表的拆分

还有表层面的拆分，就是分表，将一个表变成N个表，就是让每个表的数据量控制在一定范围内，保证SQL的性能。否则单表数据量越大，SQL性能就越差。一般是200万行左右，不要太多，但是也得看具体你怎么操作，也可能是500万，或者是100万。你的SQL越复杂，就最好让单表行数越少。

一般来说，垂直拆分，你可以在表层面来做，对一些字段特别多的表做一下拆分；水平拆分，是并发承载不了，或者是数据量太大，容量承载不了，你给拆了，按什么字段来拆，你自己想好；分表，你考虑一下，你如果哪怕是拆到每个库里去，并发和容量都ok了，但是每个库的表还是太大了，那么你就分表，将这个表分开，保证每个表的数据量并不是很大。

5.两种分库分表方式

①range方式

就是每个库一段连续的数据，这个一般是按比如时间范围来的，但是这种一般较少用，因为很容易产生热点问题，大量的流量都打在最新的数据上了。

range来分，好处在于说，后面扩容的时候，就很容易，因为你只要预备好，给每个月都准备一个库就可以了，到了一个新的月份的时候，自然而然，就会写新的库了；缺点，但是大部分的请求，都是访问最新的数据。实际生产用range，要看场景，你的用户不是仅仅访问最新的数据，而是均匀的访问现在的数据以及历史的数据

②hash方式

按照某个字段hash一下均匀分散，这个较为常用。

hash分法，好处在于说，可以平均分配没给库的数据量和请求压力；坏处在于说扩容起来比较麻烦，会有一个数据迁移的这么一个过程

分库分布的几件小事（一）数据库如何拆分

标签：常用缓存分布式客户频率代理服务端支持表结构

数据库中间件是什么意思

数据库中间件是位于平台(硬件和操作系统)和应用之间的通用服务，这些服务具有标准的程序接口和协议。

而数据库中间件(Distributed Database Middleware)是解决数据库容量、性能瓶颈和分布式扩展问题的中间件服务，提供分库分表、读写分离、弹性扩容等能力，应对海量数据的高并发访问场景，有效提升数据库读写性能。

数据库为什么要分库分表

1基本思想之什么是分库分表？

从字面上简单理解，就是把原本存储于一个库的数据分块存储到多个库上，把原本存储于一个表的数据分块存储到多个表上。

2基本思想之为什么要分库分表？

数

据库中的数据量不一定是可控的，在未进行分库分表的情况下，随着时间和业务的发展，库中的表会越来越多，表中的数据量也会越来越大，相应地，数据操作，增

删改查的开销也会越来越大；另外，由于无法进行分布式式部署，而一台服务器的资源（CPU、磁盘、内存、IO等）是有限的，最终数据库所能承载的数据量、

数据处理能力都将遭遇瓶颈。

3分库分表的实施策略。

分库分表有垂直切分和水平切分两种。

3.1

何谓垂直切分，即将表按照功能模块、关系密切程度划分出来，部署到不同的库上。例如，我们会建立定义数据库workDB、商品数据库payDB、用户数据

库userDB、日志数据库logDB等，分别用于存储项目数据定义表、商品定义表、用户数据表、日志数据表等。

3.2

何谓水平切分，当一个表中的数据量过大时，我们可以把该表的数据按照某种规则，例如userID散列，进行划分，然后存储到多个结构相同的表，和不同的库

上。例如，我们的userDB中的用户数据表中，每一个表的数据量都很大，就可以把userDB切分为结构相同的多个userDB：part0DB、

part1DB等，再将userDB上的用户数据表userTable，切分为很多userTable：userTable0、userTable1等，

然后将这些表按照一定的规则存储到多个userDB上。

3.3应该使用哪一种方式来实施数据库分库分表，这要看数据库中数据量的瓶颈所在，并综合项目的业务类型进行考虑。

如果数据库是因为表太多而造成海量数据，并且项目的各项业务逻辑划分清晰、低耦合，那么规则简单明了、容易实施的垂直切分必是首选。

而

如果数据库中的表并不多，但单表的数据量很大、或数据热度很高，这种情况之下就应该选择水平切分，水平切分比垂直切分要复杂一些，它将原本逻辑上属于一体

的数据进行了物理分割，除了在分割时要对分割的粒度做好评估，考虑数据平均和负载平均，后期也将对项目人员及应用程序产生额外的数据管理负担。

在现实项目中，往往是这两种情况兼而有之，这就需要做出权衡，甚至既需要垂直切分，又需要水平切分。我们的游戏项目便综合使用了垂直与水平切分，我们首先对数据库进行垂直切分，然后，再针对一部分表，通常是用户数据表，进行水平切分。

4分库分表存在的问题。

4.1事务问题。

在执行分库分表之后，由于数据存储到了不同的库上，数据库事务管理出现了困难。如果依赖数据库本身的分布式事务管理功能去执行事务，将付出高昂的性能代价；如果由应用程序去协助控制，形成程序逻辑上的事务，又会造成编程方面的负担。

4.2跨库跨表的join问题。

在执行了分库分表之后，难以避免会将原本逻辑关联性很强的数据划分到不同的表、不同的库上，这时，表的关联操作将受到限制，我们无法join位于不同分库的表，也无法join分表粒度不同的表，结果原本一次查询能够完成的业务，可能需要多次查询才能完成。

4.3额外的数据管理负担和数据运算压力。

额

外的数据管理负担，最显而易见的就是数据的定位问题和数据的增删改查的重复执行问题，这些都可以通过应用程序解决，但必然引起额外的逻辑运算，例如，对于

一个记录用户成绩的用户数据表userTable，业务要求查出成绩最好的100位，在进行分表之前，只需一个order

by语句就可以搞定，但是在进行分表之后，将需要n个order

by语句，分别查出每一个分表的前100名用户数据，然后再对这些数据进行合并计算，才能得出结果。

数据库算不算中间件

不算。

数据库是底层，作用是保存数据。中间件通常用于协议适配转换或业务处理，数据库中间件是与业务无关的可以实现数据库的一些功能的组件。

数据库中间件包括：分布式数据库分表分库，数据增量订阅与消费，数据库同步（全量，增量，跨机房，复制），跨数据库（数据源）迁移。

如果你还想了解更多这方面的信息，记得收藏关注本站。