TiDB学习笔记01-分布式数据库

TiDB学习笔记01-分布式数据库

一代系统：数据库中间件

● 二代系统：NoSQL 数据库

● 三代系统(2013)：

○ Google Spanner 及其类似的 NewSQL (TiDB 3.0, CockroachDB)

○ AWS Aurora 及其类似架构的云数据库

● 新一代趋势：HTAP 数据库（以 TiDB 4.0 为代表）

数据库管理员(Database Administrator，简称DBA)

1.1 数据库中间件

两种实现模式：● 业务层手动分库分表（手动）● 通过中间件指定 Sharding Key 的模式水平分表（半自动）常见分片Key选择: user id、城市、时间常见分片规则：哈希分片、范围分片

数据库中间件的优点：● 架构相对简单● 对底层的关系型数据库改动不大，运维经验可以复用

缺点：● 只适用于简单业务，同时对业务有侵入性，需要改造● 很难支持跨分片的高性能复杂查询● 分布式事务性能损失　　○ 扩展问题：为什么会有性能牺牲？● 水平扩展能力差，只能按照选定的分片规则横向扩展● 大型集群运维困难　　○ 表结构变更（DDL）操作困难，容易出现失误　　○ 只能按照分片进行维护（备份、恢复等操作）

1.2 NoSQL - Not Only SQL

● 放弃高级 SQL 能力，追求强水平扩展能力（反过来意味着业务兼容的成本高）　　○ 放弃复杂 SQL 查询　　○ 放弃分布式事务（ACID）● 通常的数据访问模型：　　○ 键值对 (Key-Value)　　○ 文档型 (Document)● 代表系统：　　○ ***　　○ CouchBase　　○ ***　　○ ***● 在互联网行业比较活跃：2006 ~ 2012

NoSQL系统的优点：● 水平扩展能力强● 针对特殊类型数据效果好，可以作为关系型数据库的很好补充● 对于一致性要求不强的场景，可能会有更好的性能

缺点：● 由于不支持 SQL 业务需要进行较大的改造● 普遍无法支持事务，强一致场景比较难实现● 复杂查询受限

1.2.1 典型系统分析：***

● 文档型数据库● 仍然是通过选择 Sharing Key 的方式进行分片　　○ Range 或 Hash 分片● 优点：　　○ Scheme-less，对文档型数据比较友好● 缺点：　　○ 跨分片聚合能力差　　○ Rebalance 过程中会占用大量带宽　　○ 无跨分片事务

1.3 第三代分布式数据库 NewSQL

两种流派○ 以 Google Spanner 为代表的 Shared Nothing 架构○ 以 AWS Aurora 为代表的 Shared Everything 架构

1.3.1 Shared Nothing 流派

● 特点：　　○ 无限的弹性水平扩展　　○ 强 SQL 支持（几乎不需要妥协，无需指定分片策略，系统自动扩展）　　○ 和单机数据库一样的事务支持　　○ 跨数据中心故障自恢复级别的高可用能力● 代表产品　　○ Google Spanner　　○ TiDB 3.0 及之前版本　　○ CockroachDB

● 优点：　　○ 无限水平扩展，没有容量上限， 对海量数据场景友好　　○ 对金融级别的一致性 ACID 事务支持，业务改动代价小　　○ 故障自恢复的高可用能力，运维省事　　○ SQL 能力强，和单机数据库的体验基本一致■ 例如：TiDB 支持 MySQL 的绝大多数语法和网络协议 (覆盖度超过 92%)　　○ 无限扩展的吞吐能力（和业务负载有关）● 缺点：　　○ 并非 100% 兼容传统数据库的语法(不支持存储过程)　　○ 对于一些极端场景（秒杀），延迟不如单机数据库（跨机，跨地域的分布式事务必然带来更高延迟）　　　　■ 例子：小事务平均 latency： 2ms（单机） vs 5ms （分布式）

1.3.2 Shared Everything 流派

代表产品：AWS Aurora、*** ***Cloud-Native● 通常由公有云提供　　○ 为什么？存储计算分离● 无状态 SQL 计算节点　　○ 计算节点通常直接复用MySQL，但是不存储数据● 远程存储（数据文件层）

优点：● 易用，100% 兼容 MySQL，业务兼容性好（最大优势）● 对一致性要求不高的场景，读可以水平扩展（但是有上限）缺点：● 本质上还是单机数据库，如果要支持大数据量，仍然需要分库分表● 内存和容量不匹配，在单表数据量大后，性能抖动严重● 跨机的事务一致性问题（存在同步延迟）● 分析能力受限于单点，几乎没有分布式 OLAP 能力

1.4 分布式 HTAP 数据库

● HTAP 的定义：Hybrid Transactional/Analytical Processing，混合事务分析处理● 分布式 HTAP 的标准　　○ 业务透明的无限水平扩展能力　　○ 分布式事务的支持　　○ 多数据中心故障自恢复的高可用能力　　○ 提供高性能的分析能力　　　　■ 提供列式存储能力　　○ 在混合负载下，实时 OLAP 分析不影响 OLTP 事务● 目前业界仅有 TiDB 4.0 能达到上述的要求　　○ TiDB + TiFlash (TiDB 的列存扩展)

OLTP 系统强调数据库内存效率，强调内存各种指标的命令率，强调绑定变量，强调并发操作；OLAP 系统则强调数据分析，强调SQL执行市场，强调磁盘I/O，强调分区等。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。