数据库垂直拆分水平拆分

A. 关于数据库的水平分割和垂直分割的几点介绍

水平切分估计是指按照时间切分，垂直切分是指按照设备ID切分，这样切分后，设备的状态日志会以记录的形式存储在不同的数据文件中，数据库对这些文件的访问可以通过设备ID和时间快速地查找到。而且应用中只是存储日志数据，不需要进行频繁的实时查询和统计，所以基本上数据库的任务就是接收数据，写入到文件中，文件对应的分片满了就再创建新的分片文件。这样整体的性能没有任何变化，系统的负载也是维持在一个常量的水平。
如果要对日志进行统计和分析，则会随着日志数量增加，性能显着下降，但这里没有这样的需求，即使有，也是用另外一组离线分析服务器进行处理。

B. 浅谈mysql数据库分库分表那些事-亿级数据存储方案

mysql分库分表一般有如下场景

其中1，2相对较容易实现,本文重点讲讲水平拆表和水平拆库,以及基于mybatis插件方式实现水平拆分方案宽兄落地。

在 《聊一聊扩展字段设计》 一文中有讲解到基于KV水平存储扩展字段方案,这就是非常典型的可以水平分表的场景。主表和kv表是一对N关系,随着主表数据量增长,KV表最大N倍线性增长。

这里我们以分KV表水平拆分为场景

对于kv扩展字段查询,只会根据id + key 或者 id 为条件的方式查询,所以这里我们可以按照id 分片即可

分512张表(实际场景具体分多少表还得根据字段增加的频次而定)

分表后表名为kv_000 ~ kv_511

id % 512 = 1 .... 分到 kv_001,

id % 512 = 2 .... 分到 kv_002

依次类推!

水平分表相对比较容易,后面会讲到基于mybatis插件实现方案

场景:以下我们基于博客文章表分库场景来分析

目标:

表结构如下(节选部分字段):

按照user_id sharding

假如分1024个库,按照user_id % 1024 hash

user_id % 1024 = 1 分到db_001库

user_id % 1024 = 2 分到db_002库

依次类推

目前是2个节点,假如后期达到瓶颈,我们可以增加至4个节点

最多可以增加只1024个节点,性能线性增长

对于水平分表/分库后,非shardingKey查询首先得考虑到

基于mybatis分库分表,一般常用的一种是基于spring AOP方式, 另外一种基于mybatis插件。其实两种方式思路差不多。

为了比较直观解决这个问题,我分别在Executor 和StatementHandler阶段2个晌陵拦截器

实现动态数据源慎谨袭获取接口

测试结果如下

由此可知,我们需要在Executor阶段 切换数据源

对于分库:

原始sql:

目标sql:

其中定义了三个注解

@useMaster 是否强制读主

@shardingBy 分片标识

@DB 定义逻辑表名 库名以及分片策略

1)编写entity

Insert

select

以上顺利实现mysql分库,同样的道理实现同时分库分表也很容易实现。

此插件具体实现方案已开源: https://github.com/bytearch/mybatis-sharding

目录如下:

mysql分库分表,首先得找到瓶颈在哪里(IO or CPU),是分库还是分表,分多少？不能为了分库分表而拆分。
原则上是尽量先垂直拆分 后 水平拆分。
以上基于mybatis插件分库分表是一种实现思路,还有很多不完善的地方,
例如:

C. 数据库水平拆分和垂直拆分 怎么实现

垂直拆分

垂直拆分是指数据表列的拆分，把一张列比较多的表拆分为多张表

通常我们按以下原则进行垂直拆分:

把不常用的字段单独放在一张表;
把text，blob等大字段拆分出来放在附表中;
经常组合查询的列放在一张表中;垂直拆分更多时候就应该在数据表设计之初就执行的步骤，然后查询的时候用join关键起来即可;
水平拆分

水平拆分是指数据表行的拆分，表的行数超过200万行时，就会变慢，这时可以把一张的表的数据拆成多张表来存放。

水平拆分的一些技巧
1. 拆分原则
通常情况下，我们使用取模的方式来进行表的拆分;比如一张有400W的用户表users，为提高其查询效率我们把其分成4张表

users1，users2，users3，users4
通过用ID取模的方法把数据分散到四张表内Id%4+1 = [1,2,3,4]
这里是个小哈希，然后查询,更新,删除也是通过取模的方法来查询

$_GET['id'] = 17,
17%4 + 1 = 2,
$tableName = 'users'.'2'
Select * from users2 where id = 17;
在insert时还需要一张临时表uid_temp来提供自增的ID,该表的唯一用处就是提供自增的ID;

insert into uid_temp values(null);
得到自增的ID后,又通过取模法进行分表插入;
注意,进行水平拆分后的表,字段的列和类型和原表应该是相同的,但是要记得去掉auto_increment自增长

另外
部分业务逻辑也可以通过地区，年份等字段来进行归档拆分;
进行拆分后的表，只能满足部分查询的高效查询需求，这时我们就要在产品策划上，从界面上约束用户查询行为。比如我们是按年来进行归档拆分的,这个时候在页面设计上就约束用户必须要先选择年,然后才能进行查询;
在做分析或者统计时，由于是自己人的需求,多点等待其实是没关系的,并且并发很低,这个时候可以用union把所有表都组合成一张视图来进行查询,然后再进行查询;

Create view users as select from users1 union select from users2 union.........

D. 整个数据库的dmp文件能拆分出表吗

可以。
数据的切分（Sharding）根据其切分规则的类型，可以分为两种切分模式。一种是按照不同的表（或Schema）来切分到不同的数据库（主机）之上，这种切可以称之为数据的垂直（纵向）切分，另外一种则是根据表中的数据的逻辑关系，将同一个表中的数据按照某种条件拆分到多台数据库（主机）上面，这种切分称之为数据的水平（横向）切分。垂直切分一个数据库由很多表的构成，每个表对应着不同的业务，垂直切分是指按照业务将表进行分类，分布到不同的数据库上面，这样也就将数据或者说压力分担到不同的库上面， 垂直切分的优缺点介绍：
优点：拆分后业务清晰，拆分规则明确。系统之间整合或扩展容易。数据维护简单。
缺点：部分业务表无法join，只能通过接口方式解决，提高了系统复杂度。受每种业务不同的限制存在单库性能瓶颈，不易数据扩展跟性能提高。事务处理复杂。由于垂直切分是按照业务的分类将表分散到不同的库，所以有些业务表会过于庞大，存在单库读写与存储瓶颈，所以就需要水平拆分来做解决。水平切分相对于垂直拆分，水平拆分不是将表做分类，而是按照某个字段的某种规则来分散到多个库之中，每个表中包含一部分数据。简单来说，我们可以将数据的水平切分理解为是按照数据行的切分，就是将表中的某些行切分到一个数据库，而另外的某些行又切分到其他的数据库中，水平切分的优缺点介绍：拆分规则抽象好，join操作基本可以数据库做。
不存在单库大数据，高并发的性能瓶颈。应用端改造较少。提高了系统的稳定性跟负载能力。拆分规则难以抽象。分片事务一致性难以解决。数据多次扩展难度跟维护量极大。跨库join性能较差。垂直切分和水平切分共同的特点和缺点有：引入分布式事务的问题。跨节点Join的问题。跨节点合并排序分页问题。多数据源管理问题。

E. 数据库水平拆分是在单库中拆出多个表，每个表是表名+规则。还是分出多个库，每个库是库名+规则，表名不变

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 应该使用哪一种方式来实施数据库分库分表，这要看数据库中数据量的瓶颈所在，并综合项目的业务类型进行考虑。
如果数据库是因为表太多而造成海量数据，并且项目的各项业务逻辑划分清晰、低耦合，那么规则简单明了、容易实施的垂直切分必是首选。
而如果数据库中的表并不多，但单表的数据量很大、或数据热度很高，这种情况之下就应该选择水平切分，水平切分比垂直切分要复杂一些，它将原本逻辑上属于一体的数据进行了物理分割，除了在分割时要对分割的粒度做好评估，考虑数据平均和负载平均，后期也将对项目人员及应用程序产生额外的数据管理负担。
在现实项目中，往往是这两种情况兼而有之，这就需要做出权衡，甚至既需要垂直切分，又需要水平切分。我们的游戏项目便综合使用了垂直与水平切分，我们首先对数据库进行垂直切分，然后，再针对一部分表，通常是用户数据表，进行水平切分。

F. 数据库水平分库和垂直分库有什么区别

常见的分库方式有水平性和垂直性。一般来说，就是按照用户属性（地市或者ID的hash）进行分库，或者按照业务功能块进行分库。
水平分库方式主要根据用户属性（如地市）拆分物理数据库。一种常见的方式是将全省划分为个大区。
垂直分库方式：根据业务维度和数据的访问量等，进行数据的分离，剥离为多个数据库。例如，将一些公用的配置信息存储到一个数据库中进行单独维护。