当前位置:首页 » 操作系统 » 数据库垂直拆分水平拆分

数据库垂直拆分水平拆分

发布时间: 2023-07-30 22:14:54

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)进行分库,或者按照业务功能块进行分库。
水平分库方式主要根据用户属性(如地市)拆分物理数据库。一种常见的方式是将全省划分为个大区。
垂直分库方式:根据业务维度和数据的访问量等,进行数据的分离,剥离为多个数据库。例如,将一些公用的配置信息存储到一个数据库中进行单独维护。

热点内容
低温存储测试 发布:2025-03-14 12:10:22 浏览:244
c语言二维数组的输出 发布:2025-03-14 11:58:10 浏览:25
安卓脚本自动运行 发布:2025-03-14 11:49:35 浏览:354
yii页面缓存 发布:2025-03-14 11:45:51 浏览:798
c语言算法书 发布:2025-03-14 11:45:26 浏览:264
安卓动漫插件在哪里 发布:2025-03-14 11:41:11 浏览:660
linux复制系统文件到 发布:2025-03-14 11:29:45 浏览:40
腰2椎体压缩性骨折多久能干活 发布:2025-03-14 11:29:34 浏览:168
脚本挖图全自动 发布:2025-03-14 11:28:51 浏览:77
redis缓存有效期 发布:2025-03-14 11:28:45 浏览:739