海量数据存储解决方案之分库分表原理解析及mycat安装及使用

Posted 2021-12-07 踩踩踩从踩

数据库的海量数据的存储解析_踩踩踩从踩的博客-CSDN博客

前言

上篇文章主要介绍的海量数据的简介，介绍传统的数据库及nosql数据库；如何使用分区进行对数据库数据进行缓解压力，但是单单利用分区进行缓解，远远不够；效率还是达不到生产使用。这篇文件开始介绍比较常用，也是我在项目中使用的分库分表对海量数据存储的另一种解决方案，如果真的想解决tb级别的，还是得使用clickhouse mongdbdb等列式数据库，这个会在后面进行解析。

用分区，提升数据库的性能 

海量数据分片之分库分表

随着业务的发展，业务越来越复杂，应用的模块越来越多，总的数据量很大，高并发读写操作均超过单个数据库服务器的处理能力怎么办？

对于读压力，我们可以想什么办法？

集群，多个从库

2.对于写压力呢？ 能集群，多个主库吗？

不能多个相同的主库 那到底怎么办？

对于读的方式，可以采用这种方式

 但平常中，解决这种方式采用分片 之分库分表的方式；更不能采用多主多从

分片

数据分片指按照某个维度将存放在单一数据库中的数据分散地存放至多个数据库或表中，让写数据库的缓冲压力进行降低。

数据分片的有效手段是对关系型数据库进行分库和分表

分库 

分库又叫垂直拆分，或者纵向拆分，指的是按照业务模块将数据分散到不同的数据库服务器

就是把原本存储于一个库的表拆分存储到多个库上，通常是将表按照功能模块、关系密切程度划分出来，部署到不同的库上。

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

按业务模块垂直拆分

优点：

• 拆分后业务清晰，拆分规则明确；
• 系统之间整合或扩展容易；
• 数据维护简单。

缺点：

        

• 部分业务表无法join，只能通过接口方式解决， 提高了系统复杂度；
•  受每种业务不同的限制存在单库性能瓶颈，不易 数据扩展跟性能提高；
• 事务处理复杂。

 多表 ，特别式分库过后的表 并且  group by  在加聚合函数等都会出现问题， 一般数据库中间件都会现在分库中 group by  在进行函数，这就会出现问题的。 因此 需要先group by完毕，在进行函数处理。

这都是我在项目中出现的问题。

而且事务处理的话，麻烦的情况。

分表

垂直拆分可以缓冲数据量和访问量带来的问题，但无法根治。

如果单个表的数量很大，超出了单表的存储上限，如电商网站的商品表、订单表等该怎么办？

如果垂直拆分之后，表中的数据量依然超过单节点所能承载的阈值，则需要水平分片来进一步处理。

分表又叫水平切分，它不再将数据根据业务逻辑分类，而是通过某个字段（或某几个字段），根据某种
规则或逻辑，将一个表的数据拆分成多份，分别存储在多个表结构一样的表中，这多个表可以存在一到
多个库中，每个分片仅包含数据的一部分。

 

 

分表又分成垂直分表和水平分表：

• 垂直分表：将本来可以在同一个表的内容，划分为多个表。（按照关系型数据库的第三范式要求，是应该在同一个表的。）
•  水平分表：是把一个表复制成同样表结构的不同表，然后把数据按照一定的规则划分，分别存储到这些表中，从而保证单表的容量不会太大，提升性能；当然这些结构一样的表，可以放在一个或多个数据库中。

例如我在 记录用户时，使用用户的hash值，将用户表分成多个，这就是垂直拆分表

对海量数据的表进行分表分库存储-水平拆分

 

优点：

• 拆分规则抽象好，join 操作基本可以数据库做；
• 不存在单库大数据，高并发的性能瓶颈；
• 应用端改造较少；
• 提高了系统的稳定性跟负载能力。

缺点：

• 拆分规则难以抽象；
•  分片事务一致性难以解决；
•  数据多次扩展难度跟维护量极大；
• 跨库join 性能较差。

分片规则

水平对数据进行拆分最重要的是分片规则—拆分规则

可以如何来拆分？
 范围：时间、数值；
 列表：按地域、按组织、分类；
 散列：hash(某个字段) % 分片数、一致性hash；  复合多种方式。

按照时间进行拆分， 也好数值拆分，一旦涉及到分库过后，进行很多函数就会有问题。不只是效率慢，有可能导致数据都不正确了。

数据库中间件

分库分表会出现的难点

无论垂直拆分、水平拆分，都有共同的 技术难点:

• 分布式事务的问题；
• 跨节点Join的问题；
• 跨节点合并排序分页问题；
• 多数据源管理问题。

需要处理的

• 要能解析SQL
• 能支持读写分离
• 能支持从库读的负载均衡
• 支持分库操作
• 支持分表操作
• 支持跨库关联查询
• 对事务处理的支持
• 主键ID生成
• 数据源管理

两种实现模式

分为客户端模式和服务端代理模式

客户端

 

客户端模式 ，在应用程序中集成数据库中间件模块，通过该模块来配置管理应用需要的一个（或

者多个）数据源，以及访问各个数据源，在模块内完成数据的整合。

服务端模式

 

服务端（代理）模式 ，通过中间代理层来统一管理所有的数据源，后端数据库集群对前端应用程

序透明，同时易于数据库扩展。独立的服务能提供更强的处理能力。适用于大型复杂系统。

这也是常用的mycat的模式

常见的数据中间件 

简介

 解决业务场景，最多的还是mycat的把，但是根据不同的功能，支持性，以及解决分库分表问题的支撑度来选择。

Mycat

MyCAT 是一个彻底开源的，面向企业应用开发的“大数据库集群” 支持事务、ACID、可以替代mysql的加强版数据库 ? 一个可以视为“Mysql”集群的企业级数据库，用来替代昂贵的Oracle集群 ? 一个融合内存缓存技术、Nosql技术、HDFS大数据的新型SQL Server ? 结合传统数据库和新型分布式数据仓库的新一代企业级数据库产品 ? 一个新颖的数据库中间件产品。

官网地址：Mycat1.6

MyCATApache (github.com)

• 一个彻底开源的，面向企业应用开发的大数据库集群
•  支持事务、ACID、可以替代MySQL的加强版数据库
•  一个可以视为MySQL集群的企业级数据库，用来替代昂贵的Oracle集群
•  一个融合内存缓存技术、NoSQL技术、HDFS大数据的新型SQL Server
•  结合传统数据库和新型分布式数据仓库的新一代企业级数据库产品
•  一个新颖的数据库中间件产品。

关键特性

支持前端作为MySQL通用代理

后端JDBC方式支持Oracle,DB2,SQL Server,mongodb,巨杉

基于心跳的自动故障切换，支持读写分离

支持MySQL Cluster,Galera,Percona,cluster集群

支持数据的多片自动路由与聚合

支持sum,count,max等常用的聚合函数,支持跨库分页

支持库内分表,支持单库内部任意join全局表，支持跨库2表join

基于caltlet的多表join

支持通过全局表，ER关系的分片策略，实现了高效的多表join查询

支持多租户方案 

支持弱XA,XA分布式事务

支持全局序列号，解决分布式下的主键生成问题

分片规则丰富，插件化开发，易于扩展

支持命令行监控,支持密码加密,支持IP白名单

支持SQL黑名单、sql注入攻击拦截

支持prepare预编译指令

支持非堆内存(Direct Memory)聚合计算

支持oracle存储过程，out参数

支持zookeeper协调主从切换、zk序列、配置zk化

Mycat 由来

2013年阿里的Cobar在社区使用过程中发现存在一些比较严重的问题，及其使用限制，经过Mycat发起人第一次改良，第一代改良版——Mycat诞生。 Mycat开源以后，一些Cobar的用户参与了Mycat的开发，最终Mycat发展成为一个由众多软件公司的实力派架构师和资深开发人员维护的社区型开源软件。

Mycat 安装

环境准备

1 JDK1.7+ Mycat是用java开发
2 MySQL统一5.7 镜像地址： http://mirrors.163.com/mysql/Downloads/MySQL- 5.7/mysql-5.7.24-1.el7.x86_64.rpm-bundle.tar
3 Mycat安装包 下载地址： http://dl.mycat.io 当前最新版本：1.6.6.1

Mycat使用说明

1 源码方式导入到IDE，源码地址：https://github.com/MyCATApache/Mycat-Server
 2 安装包方式安装，下载地址： http://dl.mycat.io

解压过后

• /etc/profile/  配置环境变量 

• 基本关键的 logs包 及 lib bin包

• bin下面就存在包括 window 和linux版本

•  其中比较重要的 rule.xml 以及server.xml  schema.xml；定义 规则，以及数据源 的配置文件。

 启动 mycat包

• 连接mycat 在server.xml中有端口号及  用户名等信息

 

 

 并且在testdb中会创建默认的表信息数据

核心概念

数据库中间件 ：对应用，mycat就是数据库服务，mycat是后端数据库集群的代理

 schema.xml

• 逻辑库：mycat数据库服务中定义、管理的数据库
• 逻辑表：逻辑库中包含的需分库分表存储的表
• dataNode：数据节点（分片节点），逻辑表分片的存放节点。
•  dataHost: 数据主机（节点主机），数据节点所在的主机。
• writeHost：写主机，真实的数据库服务主机描述
•   readHost：读主机，真实的数据库服务主机描述

<mycat:schema> 
 <schema name="testdb">
 <table name="orders" primaryKey="ID" 
 type="global" dataNode="dn1,dn2" />
 </schema>
 <dataNode name="dn1" dataHost="dhost1" database="db1" />
 <dataHost name="dhost1" ...>
 <heartbeat>select user()</heartbeat>
 <writeHost host="hostM1" url="localhost:3306"...>
<readHost host="hostS2" url="192.168.1.2:3306".../>
 </writeHost>
 </dataHost>
</mycat:schema>

 

server.xml

配置对应的 用户名和密码 及 是否只读

<mycat:server xmlns:mycat="http://io.mycat/">
	<user name="user">
		<property name="password">user</property>
		<property name="schemas">mydb1</property>
		<property name="readOnly">false</property>
	</user>

</mycat:server>

rule.xml

配置对应的规则 包括 mod-long  根据 uuid 取模

分库分表的优缺点和原则

 分片优点

• 解决磁盘系统最大文件限制，比如常见的有：

FAT16(最大分区2GB,最大文件2GB)

FAT32(最大分区32GB，最大容量2TB，最大文件32G)

NTFS(最大分区2TB，最大容量，最大文件2TB)

EXT3(最大文件大小: 2TB，最大文件极限: 仅受文件系统大小限制，最大分区/文件系统大小: 4TB，最大文件名长度: 255 字符)

•  减少增量数据写入时的锁对查询的影响，减少长时间查询造成的表锁，影响写入操作等锁竞争的情况， 节省排队的时间开支，增加呑吐量。
• 由于单表数量下降，常见的查询操作由于减少了需要扫描的记录，使得单表单次查询所需的检索行数变少，减少了磁盘IO，时延变短。

分库原则

基本的思路就是分析业务功能，以及表间的聚合关系，把关系紧密的表放在一起。

分库的粒度指的是在做切分时允许几级的关联表放在一起，这个问题对应用程序实现有着很大的影响。关联打断的越多，则受影响的join操作越多。

实际的粒度掌控需要结合“业务紧密程度”和“表的数据量”两个因素综合考虑

•  若划归到一起的表关系紧密，且数据量并不大，增速也非常缓慢，则适宜放在一起，不需要再进行水平切分；
•  若划归到一起的表的数据量巨大且增速迅猛，则势必要在分库的基础上再进行分表，这就意味着原单一的库还可能会被拆分成多个库，这会导致更多的复杂性，一开始最好就要考虑进去

分表原则

对于垂直分表，通常是按照业务功能的使用频次，把主要的、热门的字段放在一起做为主要表；然后把不常用的，按照各自的业务属性进行聚集，拆分到不同的次要表中；主要表和次要表的关系一般都是一对一的。

对于水平分表，通常是按照具体的业务规则和数据的格式，选择能够把数据进行合理拆分的业务数据做为拆分标准，以此来对数据进行拆分。

水平对数据进行拆分最重要的是分片规则—拆分规则

可以如何来拆分？

•  范围：时间、数值；
• 列表：按地域、按组织、分类；
•  散列：hash(某个字段) % 分片数、一致性hash；
•  复合多种方式。

第一原则：能不切分尽量不要切分

第二原则：如果要切分一定要选择合适的切分规则，提前规划好。

第三原则：数据切分尽量通过数据冗余或表分组（Table Group）来降低跨库Join 的可能。

第四原则：由于数据库中间件对数据Join实现的优劣难以把握，而且实现高性能难度极大，业务读取尽量少使用多表Join。