分库分表与newSQL(TiDB)方案调研

0 目前存在20张表单表的数据量在百万、千万级别，最大的是2千万级别.

1 业务扩充，后期大概率是重点业务，原本8个城市，22年开始扩充到三十余个城市。预计数据量以每年4-8倍的数据量增加。

保证调整后在未来3-5年左右依旧比较合理，数据库层面不成为整体架构的瓶颈，在数据量、高并发写上来后，能较方便的扩展。

1 单表单库数据量过大，磁盘占用过大，甚至磁盘不够使用，导致索引效率逐渐变低、查询过于耗费cpu io等资源。-- 目前问题

2 业务关联性低或者绝对并发量高，数千级别，数据库读写压力大，太多slave，已经达到单个库实例的极限。-- 后期问题

0 分区 -- 单机限制，且mysql对分区的支持越来越弱，新版本已弃用。不推荐

1 分库分表，使用sharding sphere和mycat等。  –  后期可能需要多次处理，一般推荐。

2 使用分布式数据库(newSQL)，如TiDB，PolarDB ,drds等。 --从根本上确保后期数据库不再成为系统架构瓶颈，最推荐

分库分表工具与newSQL详细对比如下：

数据库的三个发展阶段：
传统mysql、oracle：并不是面向分布式环境而设计，只能基于简单的分库分表或者中间件来做 Data Sharding 和 水平扩展。缺点：大型运维困难 分片等不能满足复杂的业务。业务的侵入性高
NoSQL的MongoDB、Cassandra、Hbase为代表，一般多为互联网公司在使用，拥有很好的水平弹性扩展能力。缺点：跨分片的聚合麻烦 acid支持比较差。业务的侵入性

newSQL：一套系统拥有既能做交易也能处理高并发事务的特性，同时又能结合一些数据仓库或者分析型数据库的能力
newSQl-sharedNothing,TiDBGoogle Spanner为代表，易用性高，不侵入业务，支持事务、支持无限水平的扩展。
newSQl-Shared Everything,AWS Aurora、阿里云的 PolarDB为代表的，由公有云服务商来提供的，计算与存储是彻底分离的，计算节点与存储节点跑在不同机器上。
Aurora优化： 只通过 redo log 的形式来做复制，而不是通过整个 IO 链路打到最后 Binlog，再发到另外一台机器上，然后再 apply 这个 Binlog，所以 Aurora 的 IO 链路减少很多，这是一个很大的创新。

分布式HTAP：
既可以做事务，又可以在同一套系统里面做实时分析。HTAP 数据库的优势是可以像 NoSQL 一样具备无限水平扩展能力，像 NewSQL 一样能够去做 SQL 的查询与事务的支持，更重要的是在混合业务等复杂的场景下，OLAP 不会影响到 OLTP 业务，同时省去了在同一个系统里面把数据搬来搬去的烦恼。目前基本只有 TiDB 4.0 加上 TiFlash 这个架构能够符合上述要求。

TiDB好处：
1 零业务侵入性，sharding有侵入性
2 支持join，且支持多维度查询，sharding仅支持按照分片的维度字段处理
3 支持永远的水平扩展和高可用；sharding不支持，后期可能成为整个架构的瓶颈，需要水平分库
4 大表修改秒级别；mysql十分钟级别
5 单表存在唯一主键；sharding的水平分库后主键、唯一索引都不能确保唯一性
6 可以直接支持数据分析(需要则直接可用)；sharding针对答题结果的分以已经比较慢了

drds：架构上和mysql+mycat类似，本质上并不是分布式数据库
prolardb ：单节点写入，资料很少，社区一般，2k的star
TiDB ： 架构更先进(多节点写入），资料丰富，社区很活跃，30k的star

可参考官网文档：TiDB 简介 | PingCAP Docs

简介：支持水平弹性扩展、ACID 事务、标准 SQL、MySQL 语法和 MySQL 协议，具有数据强一致的高可用特性，是一个不仅适合 OLTP 场景还适合OLAP 场景的混合数据库。

Tidb场景：一是 MySQL 分片与合并；二是直接替换 MySQL；三是用做数据仓库；四是作为其他系统的一个模块。

TiDB 在架构上将计算和存储层进行高度的抽象和分离，对混合负载的场景通过 IO 优先级队列，智能副本调度，行列混合存储等技术使其支持事务、且可以很好的做水平扩展。
数据(行和索引)都是由一个或多个region存储，行数据为例：region中是一个map，key 由 table_id表id、rowid主键组成。如：
t[table_id]_r[row_id]
map的value为表中每行数据的真实数据。

好处：
按region切分，所以不需要研发考虑分表算法。
提高索引效率：假设按照userid做分表，又用code做查询，此时mysql需要所有表分表查询后做聚合。
Tidb因为直接有按照索引为key存储的Region，所以不需要全量表的索引查找。

TiDB的存储：
key value结构，RocksDB实现持久化。Raft实现数据副本和一致性。Region实现水平扩展和负载均衡。mvcc实现乐观锁(事务的执行过程中，不会检测写写冲突，只有在提交过程中，才会做冲突检测，冲突的双方中比较早完成提交的会写入成功，另一方会尝试重新执行整个事务)

Tidb的计算
tableId indexId rowId实现key value到关系型数据的映射。key是有序的。
因为region在不同机器，所以可以实现天生的按照region、分布式的SQL运算。

TiDB的调度
PD中心节点：整体调控，处理如Region分裂、节点加入、节点失效、访问热点变化等情况，且维持热点分布、节点存储容量、控制balance速度等。
主要基于Raft。
信息收集：
TiKV会定期向PD汇报节点的磁盘使用状况、region状况、写入速度等。
RaftGroup会定期向PD汇报，如Leader位置、followers位置、掉线replica个数、数据写入、读取速度。
具体调度策略：
region的replica数量正确
replica分布在不同位置
副本、leader、热点数据在store上分布均匀
控制调度速度，不影响在线服务
支持手动下线节点

TiDB的不足：
对机器配置门槛要求较高，特别是内存和CPU的要求很高，当数据量不大时会增加机器的资源使用成本。
TiDB技术较新，尚在不断优化中，因此也容易踩坑。
对大规模的集群，网络也会有一些要求。参考TiDB 集群安装_linuxheik的专栏-CSDN博客
对网路要求的原因：
作为一个分布式集群，TiDB 对时间的要求还是比较高的，尤其是 PD 需要分发唯一的时间戳，如果 PD 时间不统一，如果有 PD 切换，将会等待更长的时间。2 块网卡可以做 bond，保证数据传输的稳定

参考：tidb使用坑记录&TiDB和Mysql的sql差异总结_荒野求生的博客-程序员ITS203_tidb缺点 - 程序员ITS203 tidb使用坑记录
tidb缺点 - 程序员ITS203 tidb汇总

TiDB blog: 博客 | PingCAP
tiDB官方文档 操作系统性能参数调优 | PingCAP Docs

三篇文章了解 TiDB 技术内幕 - 谈调度 | PingCAP 三篇文章了解 TiDB 技术 - 谈调度
TiDB 最佳实践 | PingCAP Docs tidb最佳实践： 存储 计算 调度原理
云原生数据库设计新思路 | PingCAP 数据库发展过程(sql noSQL newSQL)，云原生数据库设计新思路，
TiDB 在小米的应用实践 - 云+社区 - 腾讯云 TiDB 在小米的应用实践
TiDB 在知乎万亿量级业务数据下的实践和挑战_qianshanding0708的博客-CSDN博客 TiDB 在知乎万亿量级业务数据下的实践和挑战
网易互娱的数据库选型和 TiDB 应用实践-技术圈 网易互娱的数据库选型和 TiDB 应用实践
滴滴从KV存储到NewSQL实战 - DockOne.io 滴滴从KV存储到NewSQL实战
我们为什么采用TiDB代替MySQL 我们为什么采用TiDB代替MySQL
我们为什么放弃 MongoDB 和 MySQL，选择 TiDB - 用户实践 - AskTUG 伴鱼：我们为什么放弃 MongoDB 和 MySQL，选择 TiDB
分库分表：TIDB，你是来抢生意的？不讲码德？ - 墨天轮 分库分表：TIDB，你是来抢生意的？不讲码德？
https://segmentfault.com/a/1190000022596958 使用TiDB把自己写分库分表方案推翻了
为什么我们要从 MySQL 迁移到 TiDB？ - 墨天轮 360使用
测试阿里云的 PolarDB数据库，模拟高并发减库存 - 知乎 测试阿里云的 PolarDB数据库，模拟高并发减库存 -- 吐槽polarDb
MySQL痿了，放不下这么多数据！ - 掘金 polardb vs Tidb tidb需要自己安装维护，polardb直接可用。

TiDB等费用调研

TiDB技术支持每年收费:
5*8小时提供服务 34-36万
7*24小时提供服务 50万左右

几个收费参考：
oracle：
收费规则：1cpu收费近30万
参考：oracle数据库报价方法价格计算方法 - 墨天轮

阿里的PolarDB-X 与 DRDS 有什么区别？
drds架构上和mysql+mycat 是差不多的,prolardb是一个分布式的兼容mysql的集群（dba-余瑶）
PolarDB-X 与 DRDS 有什么区别？ - 知乎 阿里的PolarDB-X 与 DRDS 有什么区别？ 已认证的prolardb-x官方账号作答。
polardb-x介绍与收费：
PolarDB-X简介 - 云原生分布式数据库 PolarDB-X - 阿里云

polardb vs TiDB
58技术得出的结论：
1）透露个秘密：目前参考PolarDB收费，58TiDB数据库是盈利很多的~
2）开始时PolarDB收费比较低，TiDB收费高；当集群存储达到 1229G 时，TiDB收费与成本几乎相等，随着存储升高，开始产生受益
参考：漫谈TiDB收费与成本 - 用户实践 - AskTUG

现在编程使用的数据库统计：
申请：500G*4(班课库) + 300G*3(竞赛库) = 2900G
实际使用：380*4(班课库) + 230*3(竞赛库) = 2210G
bcy-pm 200G????是否可以删除？
bcy-hive-bigdata 20G？？是否可以删除

0）官方版和社区版主要区别是什么？
企业级最佳实践
企业级别服务支持
全面加强的安全特性

TiDB待确认：
推荐部署在机器还是部署在k8s集群？为什么呢？
如果是k8s集群？有没有在阿里的k8s集群上部署的实践？
推荐部署在k8s集群，如果是需要单独拉一个集群吗，还是建议和现在服务所在的集群直接在一起呢？
企业级都遇到过什么典型的问题？

mysql分区 - 不推荐

分区表是一个独立的逻辑表，但是底层MySQL将其分成了多个物理子表，这对用户来说是透明的，每一个分区表都会使用一个独立的表文件。
MySQL内部将表分成多个物理字表，但是客户端并无感知，仍然认为操作的是一个表。

Hash分区的实例：
mysql> CREATE TABLE IF NOT EXISTS `hash_part` (
-> `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '评论ID',
-> `comment` varchar(1000) NOT NULL DEFAULT '' COMMENT '评论',
-> `ip` varchar(25) NOT NULL DEFAULT '' COMMENT '来源IP',
-> PRIMARY KEY (`id`)
-> ) ENGINE=INNODB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1
-> PARTITION BY HASH(id)
-> PARTITIONS 3;

分区优势：
1）代码完全无需修改
2）可以使用多磁盘，存储更大一点，且跨多个磁盘来分散数据查询，来获得更大的查询吞吐量。

但是：
1）mysql5.7开始，server提供的通用分区处理器已经弃用了；后期mysqlServer彻底不再支持,少数引擎单独支持
2）永远有单机性能的限制，不易于扩展和伸缩

链接：MySQL分区和分表 - 简书
mysql分区和分表_进化的深山猿-CSDN博客_mysql分区和分表哪个好
mysql表分区的缺点_一文看懂mysql数据库分区表概念、类型、适用场景、优缺点及原理..._biu h的博客-CSDN博客

分库分表原理与方案 - 一般推荐

分库
原因：业务关联性低或者绝对并发量高，数千级别，读写压力大，太多slave，分表难以从根本上解决。
分库增加增加机器等，io和cpu的压力自然可以成倍缓解。

垂直分库
题库(9表)，打字练习（7表）-- 待确认是否可以直接拆(user表在用)
统计(4)、社区(8) -- 因为需要班课相关信息，所以不能，直接拆。
可以直接拆的：
题库 打字练习

统计社区需要用到班课相关的数据，所以整体处理过程有两种：
1 先拆库，后拆项目
拆库，项目还在一起，此时需要多数据源
拆项目(微服务化）
多数据源调整为单数据源

2 先拆项目，后拆库
拆项目，此时仍使用相同的库
微服务化
拆库

分表
使用场景：系统绝对并发量并没有上来，只是单表的数据量太多，影响了SQL效率，加重了CPU负担锁事物冲突。一般先垂直分，再考虑水平分。
水平分表
解决单表记录数过多导致的sql执行低效问题
重点梳理记录数量较多的表
如统计表按年分，历史的放到一个表中。某个用户查询某个题目的答题结果时，需要查询所有表并进行聚合
新的数据逻辑都不变
老数据的更新、查询逻辑需要调整与聚合。

垂直分表
解决因大字段IO导致的sql执行低效问题
重点梳理占用磁盘较大的表

实际操作过程：
1 获取较大的数据库(记录数与磁盘占用量)
#记录数
use information_schema;
#TABLE_SCHEMA指定库名
select table_name,table_rows from tables where TABLE_SCHEMA= 'your_db_name' and table_rows > '1000000'
order by table_rows desc ;

# 磁盘占用
select
TABLE_NAME,
concat(truncate(data_length/1024/1024,2),' MB') as data_size,
concat(truncate(index_length/1024/1024,2),' MB') as index_size
from information_schema.tables
#your_db_name
where TABLE_SCHEMA = 'your_db_name'
group by TABLE_NAME
order by data_length desc;

参考：Mysql 查看 数据库/表 磁盘占用_小猪快点跑的博客-CSDN博客
MySQL：互联网公司常用分库分表方案汇总！ - 知乎

分表字段的选择：
课程时间
学生端、教师端：以课程结束时间为准，是哪一年就落在哪个库。
管理端？一个课程的答题数据在一个表就可以？
课下有多个班级，多个班可能对应多个结束时间，且年不同吗？概率较低吧？

某些表(如stats_stu_answer)不需要事务等，所以引擎从InnoDB调整为Myisam,可以提高读效率。
参考：MYSQL 中 MyISAM与InnoDB两者之间区别与选择，详细总结，性能对比 - _成飞 - 博客园

梳理与清理清理无用的表
如user表，待梳理

分库分表工具梳理
主要分为两大类：代理或者应用层依赖类
应用层依赖类中间件
此类中间件的基本思路：重新实现JDBC的API，通过重新实现DataSource、PrepareStatement等操作数据库的接口，让应用层在基本（注意：这里用了基本）不改变业务代码的情况下透明地实现分库分表的能力。
中间件给上层应用提供熟悉的JDBC API，内部通过sql解析、sql重写、sql路由等一系列的准备工作获取真正可执行的sql，然后底层再按照传统的方法（比如数据库连接池）获取物理连接来执行sql，最后把数据结果合并处理成ResultSet返回给应用层。
特点：和应用强耦合，需要应用显示依赖相应的jar包（以Java为例），比如TDDL、sharding-jdbc。

中间层代理类中间件
这类分库分表中间件的核心原理是在应用和数据库的连接之间搭起一个代理层，上层应用以标准的MySQL协议来连接代理层，然后代理层负责转发请求到底层的MySQL物理实例，这种方式对应用只有一个要求，就是只要用MySQL协议来通信即可，天然支持所有的编程语言。
特点：与应用弱耦合，维护起来并不简单，比较有代表性的产品如Mycat。但性能会存在损耗。
参考：分库分表：中间件最全方案对比 - 知乎

mycat
cobar基础上进行二次开发，解决了cobar当时存 在的一些问题，并且加入了许多新的功能在其中。目前MyCAT社区活 跃度很高，目前已经有一些公司在使用MyCAT。总体来说支持度比较高，也会一直维护下去，发展到目前的版本，已经不是一个单纯的MySQL代理了，它的后端可以支持MySQL, SQL Server, Oracle, DB2, PostgreSQL等主流数据库，也支持MongoDB这种新型NoSQL方式的存储，未来还会支持更多类型的存储。
MyCAT是一个强大的数据库中间件，不仅仅可以用作读写分离，以及分表分库、容灾管理，而且可以用于多租户应用开发、云平台基础设施，让你的架构具备很强的适应性和灵活性，借助于即将发布的MyCAT只能优化模块，系统的数据访问瓶颈和热点一目了然，根据这些统计分析数据，你可以自动或手工调整后端存储，将不同的表隐射到不同存储引擎上，而整个应用的代码一行也不用改变。
MyCAT是在Cobar基础上发展的版本，两个显著提高：后端由BIO改为NIO，并发量有大幅提高；增加了对Order By, Group By, Limit等聚合功能（虽然Cobar也可以支持Order By, Group By, Limit语法，但是结果没有进行聚合，只是简单返回给前端，聚合功能还是需要业务系统自己完成）

Sharding-JDBC
是继dubbox和elastic-job之后，ddframe系列开源的第3个项目。
Sharding-JDBC直接封装JDBC API，可以理解为增强版的JDBC驱动，旧代码迁移成本几乎为零：
可适用于任何基于Java的ORM框架，如JPA、Hibernate、Mybatis、Spring JDBC Template或直接使用JDBC。
可基于任何第三方的数据库连接池，如DBCP、C3P0、 BoneCP、Druid等。
理论上可支持任意实现JDBC规范的数据库。
虽然目前仅支持MySQL，但已有支持Oracle、SQLServer等数据库的计划。
Sharding-JDBC定位为轻量Java框架，使用客户端直连数据库，以jar包形式提供服务，无proxy代理层，无需额外部署，无其他依赖，DBA也无需改变原有的运维方式。
Sharding-JDBC分片策略灵活，可支持等号、between、in等多维度分片，也可支持多分片键。
SQL解析功能完善，支持聚合、分组、排序、limit、or等查询，并支持Binding Table以及笛卡尔积表查询。

ShardingSphere:Sharding-JDBC Sharding-Proxy sharding-sidecar
Sharding-Sphere说明，它提供3款产品，以下是其中两款
1.Sharding-JDBC 分库分表、读写分离（参考前两篇文章）
2.Sharding-Proxy 分库分表、读写分离，它和mycat类似，属于中间件代理层，它类似一个数据库，代理后面的分库分表的多个数据库，它屏蔽了后端多个数据库的复杂性，应用开发时直接连接 Sharding-Proxy 即可

Sharding-JDBC与Sharding-Proxy对比
1.如果你的应用只读写分离、或少量的分出了几个库，使用Sharding-JDBC即可，简单、方便
2.如果你的应用有进行服务化，且有很多服务，每个服务连接所有数据库，以MYSQL为例，分库分表后有20个数据库，有100个服务需要连接，每个服务的连接池设置10个连接，那么每个MYSQL实例将要提供 20 * 100 * 10=20000个连接，mysql 默认连接数是 100，最大连接数是 16384，那么连接数不够用，如果你购买的云数据库，只能升级配置，来提供更多的连接数，将来你的服务更多怎么办，使用proxy代理，应用服务只要连接Sharding-Proxy代理层来解决连接数问题，但代理会有点性能损失
3.Sharding-Proxy连接数消耗低，可以支持很多服务进行连接，支持任意开发语言，但是会有一定性能损耗，因为多了一层代理

功能	MyCat	ShardingShpere
联合查询	最多支持2表（Share Join）	不支持
高可用	HaProxy+Keepalived+Mycat	zk方式需要调研
动态建表	不支持	不支持
侵入性	除多表联合查询外，不需要修改代码， 要么修改mycat相关源码， 要么查出相关数据，使用java代码做关联	需要修改代码
代码集成	不需要集成到服务	需要集成到服务中
故障转移	节点自判断，会有误判断操作，若多节点下， 单节点服务存在误判断，其他节点与服务不知道，此时会出现多点写入，若按照时间分片，此时数据错乱。	sharding-ui界面下线，非自动

Sharding-Sphere：Sharding-Proxy分库分表_zhuyu19911016520-CSDN博客 sharding-proxy与Sharding-JDBC对比和使用实例
shardingsphere之sharding-proxy分库分表学习笔记_fly小胖-CSDN博客 shardingProxy使用实例
sharding-jdbc与Sharding-Proxy - 简书 sharding-jdbc vs Sharding-Proxy
参考：Mycat与ShardingSphere如何选择（未完待续） - 攻城狮|悠扬攻城狮|悠扬 mycat vs shardingSphere

借鉴与参考：
MySQL：互联网公司常用分库分表方案汇总！ - 知乎 MySQL：互联网公司常用分库分表方案汇总！
一次 MySQL 分表踩坑实践的探讨！_石杉的架构笔记-CSDN博客 一次 MySQL 分表踩坑实践的探讨！
MySQL分库分表实战 - 简书
Mysql分库分表实战（一）——一文搞懂Mysql数据库分库分表_Amos技术足迹-CSDN博客_mysql 分库分表
MySQL 分库分表方案，总结的非常好！ - 妖星杉木 - 博客园
【MySQL】数据库（分库分表）中间件对比 - leon66666 - 博客园 -- 【MySQL】数据库（分库分表）中间件对比