옛날 옛적에 "동시성이 높을 때 데이터베이스를 분할하고 데이터가 클 때 테이블"은 MySQL 데이터 증가 문제를 다루는 성경이 되었습니다.
면접관은 질문하기를, 블로거는 글쓰기를 좋아하고, 지원자는 암기하기를 좋아하는 등 폐쇄 루프가 형성되어 있는 것 같습니다.
그러나 하위 데이터베이스 하위 테이블이 시스템에 정말 적합한 지 생각해 본 적이 있습니까?
하위 테이블
비즈니스가 막 개발되었을 때 모든 트래픽은 MySQL로 전송되었고 모든 사용자 정보는 사용자 테이블에 떨어졌습니다.
나중에 사용자 테이블의 데이터 양이 점점 더 많아졌습니다.
따라서 수직 분할을 수행하여 원래 사용자 테이블을 새 사용자 테이블과 user_details 테이블로 분할합니다.
이러한 분할 후 사용자의 정보는 두 개의 테이블로 흩어지고 사용자 테이블의 데이터 볼륨은 작아지고 사용자 테이블의 데이터 볼륨이 너무 큰 문제는 일시적으로 해결됩니다.
그러나 비즈니스의 발전과 함께 온라인 트래픽은 점점 더 커지고 있으며 단일 MySQL은 더 이상 트래픽의 압력을 견딜 수 없습니다.
단일 라이브러리가 압력을 견딜 수 없을 때 라이브러리를 분할해야 합니다.
지점 도서관
이름에서 알 수 있듯이 하위 라이브러리는 라이브러리를 여러 라이브러리로 분할하여 여러 라이브러리가 트래픽의 압력을 공유할 수 있도록 하는 것입니다.
여러 라이브러리로 분할한다는 것은 테이블이 분할된다는 의미이기도 합니다. 즉, 하위 라이브러리는 테이블로 분할되어야 하며, 하위 테이블은 반드시 라이브러리로 분할되지 않을 수 있습니다.
_partial application_ 또는 _partial DB_에 따라 하위 데이터베이스와 하위 테이블의 구현을 세 가지 유형으로 나눌 수 있습니다.
-
JDBC 프록시 모드
-
DB 프록시 모드
-
MySQL DB 모드에서 샤딩
JDBC 프록시 모드
JDBC 프록시 패턴은 분산 아키텍처 패턴입니다. ShardingSphere-JDBC는 JDBC 프록시 모드의 일반적인 구현입니다.
서비스는 일반적으로 클라이언트가 데이터베이스에 직접 연결할 수 있도록 jar 패키지 형태로 제공되며, 이 모드는 추가 배포 및 종속성이 필요하지 않으며 JDBC 드라이버의 향상된 버전으로 이해할 수 있습니다.
JDBC 프록시 모드는 단순하지만 DB 투명성의 원칙에 위배되고 침입성이 높아 언어별로 다른 드라이버를 작성해야 합니다.
Meituan의 Zebra, MTDDL 및 Ali의 TDDL은 모두 이 모델을 기반으로 합니다.
DB 프록시 모드
DB 프록시 패턴은 중앙 집중식 아키텍처 패턴입니다. ShardingSphere-Proxy는 DB 프록시 모드의 고전적인 구현입니다.
이 모드는 투명한 데이터베이스 프록시를 달성하는 것을 목표로 하며 응용 프로그램 배포와 독립적입니다.독립 배포로 인해 이기종 언어에 대한 제한이 없으며 응용 프로그램에 대한 침입을 일으키지 않습니다.
DB 代理模式比 JDBC 代理模式消耗的连接数会少，相对来说性能也会更好。
但中心化的设计也带来了单点的问题，为了保持高可用和高性能，还需要引入 LVS/F5 等 VIP 来实现流量的负载均衡，如果跨 IDC，还依赖诸如 DNS 进行 IDC 分发，大大拉长了应用到数据库的链路，进而提高了响应时间。
阿里的 MyCat、美团的 Meituan Atlas 和百度 Heisenberg 就是基于 DB 代理模式的实现。
Sharding On MySQL
Sharding On MySQL 相当于屏蔽了分库分表的操作，是运维和中间件结合的沉淀，比较典型例子是阿里的 DRDS。
这种模式让分库分表变得模糊，对应用来说，更像是一个封装了 MySQL 的新型数据库。
虽然用户使用变得更简单了，但简单的背后是运维的沉淀，分库分表该存在的问题它依然存在。
分库分表的成本
实现分库分表的方式有很多，但不同模式的实现似乎都是在弥补 MySQL 不支持分布式的缺陷。
分库分表这种强行让 MySQL 达到一个伪“分布式”的状态，也带来了一些新的问题，比如：
-
功能限制问题：分库分表后跨维度 join、聚合、子查询不复存在，唯一键、外键等全局约束也只能靠业务保障，DB 慢慢弱化为存储。
-
运维复杂度问题：分库分表后的多个库表的管理麻烦，运维成本非常高，数据查询也很麻烦。
-
Sharding Key 问题：非 Sharding key 的查询需要做额外的冗余处理，需要引入 Elasticsearch、ClickHouse 等其他节点，进一步提高了系统的复杂度。
-
唯一 ID 问题：分库分表后唯一 ID 得不到保障，需要对唯一 ID 进行改造。
-
分布式事务问题：MySQL 自带的 XA 柔性事务性能太低，需要引入新的分布式事务解决方案。
NewSQL
从上文得知，分库分表需要牺牲 MySQL 的一些功能，还带来许多新的问题。
那有没有一种方案，既能拥有 MySQL 的功能，又能支持数据的可扩展？
有。那就是 NewSQL。
NewSQL 是一类关系数据库管理系统，旨在为在线事务处理(OLTP) 工作负载提供 NoSQL 系统的可扩展性，同时保持传统数据库系统的 ACID 保证。
国内比较知名的 NewSQL 有阿里的 OceanBase、腾讯的 TDSQL、PingCAP 的 TiDB。它们既有 MySQL 的功能，又有分布式可扩展的能力。
笔者对阿里的 OceanBase 只能说是略懂皮毛，就不过多描述。
我们重点看一下腾讯的 TDSQL 和 PingCAP 的 TiDB。
从两者的架构图（省略了部分模块）上可以看出，TDSQL 和 TiDB 的架构只有一些命名差别，可以说几乎一模一样。
两者整体来说分为三个部分：
-
计算：负责接受客户端的连接，执行 SQL 解析和优化，最终生成分布式执行计划转发给底层的存储层执行。（TDSQL：SQL Engine 、TiDB：TiDB-Server）
-
存储：分布式_KV 存储_，类似 NoSQL 数据库，支持弹性扩容和缩容。（TDSQL：TDStore 、TiDB：TiKV）
-
管控：整个集群的元信息管理模块，是整个集群的大脑。（TDSQL：TDMetaCluster 、TiDB：Placement Driver ）
两者核心的存储模块（TDStore/TiKV），都是基于 RocksDB 开发而来，都是_KV 存储_的模式。
RocksDB 是由 Facebook 基于 LevelDB 开发的一款提供键值存储与读写功能的 LSM-tree 架构引擎。
底层利用了_WAL(Write Ahead Log)技术_和_Sorted String Table_，比 B 树类存储引擎更高的写吞吐。
NewSQL 平滑接入方案
因为笔者落地过 TiDB，所以会以 TiDB 为例描述如何接入 NewSQL，做到不影响线上使用的平滑迁移。
第一步：初始状态，所有线上读和写都落到 MySQL。
第二步：将 TiDB 作为 MySQL 的从节点接入系统，所有线上读写还是都落到 MySQL，日末通过脚本或者任务验证 MySQL 的数据和 TiDB 的数据是否一致，这一步主要验证 MySQL 数据同步到 TiDB 没有问题。
第三步：将部分读切换到 TiDB，这一步主要验证 TiDB 同步的数据读没有问题，验证系统 SQL 能正常在 TiDB 执行。
第四步：断掉 MySQL 和 TiDB 之间的同步，双写 MySQL 和 TiDB，所有的线上读流量都落到 MySQL。
第五步：将部分读流量切到 TiDB，验证 TiDB 写入的数据能够正常读取。这一阶段可以将部分幂等任务同时在两个数据源上执行，验证两者数据是否一致。
第六步：将所有的线上读流量切到 TiDB，同时保持双写，如果出问题随即切到 MySQL。
第七步：断掉 MySQL 的写流量，将 MySQL 作为 TiDB 的一个从库，作为降级使用。
整个方案的基础是：TiDB 兼容 MySQL 协议和 MySQL 生态。
这个方案是建立在完全不信任 TiDB的基础上设计的，验证了 TiDB 和 MySQL 的契合点，所以整体会比较繁琐，实际落地的时候可以根据情况省略一部分步骤。
NewSQL 真的有那么好吗？
NewSQL 并是不万能的，也不必去过于神化 NewSQL，国内比较知名的几种 NewSQL 或多或少都存在部分功能缺陷，以 TiDB 为例：
-
TiDB 的自增 ID 只能保证单个 TiKV 上的自增，并不能保证全局自增。
-
由于 TiKV 存储是根据 key 的二进制顺序排列的，使用自增 ID 可能会造成热块效应。
-
TiDB 默认 RC（读已提交）的事务隔离级别，并且不支持 RR（可重复读）隔离级别，虽然提供了基本等价于RR的SI（Snapshot Isolation），但还是存在_写偏斜_问题
-
TiDB 的点查（select point）性能比 MySQL 要差不少，在几个亿级别的数据量才能勉强和 MySQL 打平。
-
因为底层基于 Raft 协议做数据同步，所以 TiDB 延迟会比 MySQL 要高。
-
...
所以说，NewSQL 也并不是屠龙刀，需要根据实际应用去评估这些缺陷带来的影响。
NewSQL 的应用
NewSQL 在国内其实已经发展了很多年，OceanBase 诞生于 2010 年，TDSQL 可追溯到 2004 年，TiDB 诞生于 2015 年。
三者在国内外积累了不少的客户案例。
OceanBase
-
OceanBase 已经覆盖蚂蚁集团100%核心链路，支撑全部五大业务板块。目前运行数十亿条不同的 SQL、数据量达数百 PB、服务器核数过百万。
-
中国工商银行全行业务都使用 OceanBase，包含不限于存、贷、支付结算及创新业务等。
-
OceanBase 凭借混合云架构、高可用、Oracle 兼容等特性，通过分布式中间件、金融套件、移动开发平台集成解决方案，支撑网商银行核心系统数字化转型。
-
招商银行的“海量行情系统”和“历史收益系统”就是采用 OceanBase 作为底层数据库。
TDSQL
-
微众银行实现了 TDSQL 私有化部署，是一个典型的两地多中心架构。
-
富途证券的港股交易系统、东吴证券新一代核心交易系统底层存储都是 TDSQL。
-
数字广东粤省事、深圳地铁码上乘车等业务都是在 TDSQL 上面跑的。
-
平安银行、中国农业银行、华夏银行、中国银行都有相关业务在 TDSQL 上。
TiDB
-
北京银行的网联支付业务，所有北京银行的银行卡绑定在比如支付宝、微信上的支付操作，后端的数据库就是运行在 TiDB，而且是一个典型的两地三中心同城双活的架构，这个业务非常的关键，如果业务中断超过一定时间，就是需要上报银监会的。
-
日本排名第一的支付公司——Paypay，钱包和支付的业务都在 TiDB 上面。
-
中国人寿的寿财险业务，正在用 TiDB 陆续替换 Oracle 。
-
肯德基所有的会员登录系统，包括 KFC 的 APP 以及第三方登录，后台数据库都是用的 TiDB ，这套业务 2020 年 4 月份上线，已经经历过多次肯德基的大促等活动，目前肯德基的后台支付系统也已经切换到 TiDB 上。
-
맥도날드 의 계정과 주문 시스템은 모두 TiDB를 기반으로 하고 있어 TiDB에 문제가 있을 경우 온·오프라인 주문 시스템을 포함한 중국 내 모든 맥도날드 매장이 정상 운영되지 않을 수 있다.
-
백그라운드에서 전체 배치 처리 비즈니스인 WeBank의 핵심이자 가장 수익성이 높은 소액 대출 비즈니스는 TiDB에서 실행됩니다 .
하위 데이터베이스 하위 테이블과 NewSQL을 선택하는 방법은 무엇입니까?
하위 데이터베이스 하위 테이블은 무거운 솔루션이며 많은 새로운 문제를 가져올 것이며 인프라 및 운영 및 유지 관리에 대한 요구 사항도 매우 높습니다.
NewSQL은 강력하지만 결함도 있습니다.
시스템의 현황과 기업의 상황에 따라 어떻게 판단할 것인지 종합적으로 판단해야 합니다.
하위 라이브러리 및 하위 테이블은 무거운 솔루션입니다._읽기-쓰기 분리_, 콜드 및 핫 분리_와 같은 경량 솔루션 이 문제를 해결할 수 있다면 _ 하위 라이브러리 및 하위 테이블이 필요하지 않습니다 .
캐시 분류 및 읽기-쓰기 분리가 처리할 수 없고 인터넷 회사에 있는 경우 인프라를 계속 유지 관리할 수 있고 운영 및 유지 관리를 유지할 수 있습니다. _ 데이터베이스 및 테이블 _이 여전히 첫 번째 선택입니다.
그러나 인프라가 열악하거나 전혀 없는 기존 기업에 있다면 _NewSQL_을 고려할 수 있습니다.
높거나 낮은 기술은 없다 문제를 해결할 수 있는 기술은 좋은 기술이다 기술 솔루션을 선택할 때 기술을 과시하지 말고 과도하게 설계하지 마십시오!
참고문헌
Nuggets Technology Community의 작성자 서명 프로그램 모집에 참여하고 있습니다. 링크를 클릭하여 등록하고 제출 하십시오.