1. 存储引擎的的功能
- 提供数据存储接口并持久化存储数据
2. LSM-tree 的特性
- LSM-tree 结构本质上是一个用空间置换写入延迟,用顺序写入替换随机写入的数据结构
3. 数据库技术的发展
- 20世纪80年代,关系数据库发展
- 2000年左右,NoSQL 发展
- 2010年左右,NewSQL 发展
- 2020年后, HTAP 成为强需求
4. Google BigTable 解决的问题
- 分布式 key-value 存储
5. 分布式存储引擎 TiKV 的特性
- 负责数据的存储和持久化
6. TiDB 的 MVCC
- 通过在 Key 后面添加版本号来实现
- 有了 MVCC 版本控制后,TiKV 得以实现并发控制、SI 的隔离级别、事务支持、历史数据恢复等功能
- TiDB 的 MVCC 数据与当前数据存储在同一个 Region
7. TiDB-Server 的后台功能
- 垃圾回收(GC)
- 执行 DDL
- 统计信息管理
- SQL 优化器与执行器
8. CAP 理论中的一致性和 ACID 的一致性的比较
- CAP 理论中的一致性:所有副本的一致性
- ACID 一致性:事务的一致性
9. TiDB 的哪个组件在 2018 年捐献给了 CNCF 基金会,并于 2020 年正式毕业
- TiKV
10. 列式存储引擎 TiFlash 采用了什么样的数据结构支持准实时更新
- Delta tree
11. 下推计算
- 减少了节点之间的网络交互成本
- 充分利用 TiKV 分布式的存储节点的并行计算能力
- 在每个节点都需要一个计算模块——协作处理器(Coprocessor)
12. TiDB 集群在本地环境部署时用到的命令
- tiup playground
13. 基于成本优化器的特点
- 基于成本的优化器将 CPU、内存、网络、I/O 等资源进行等价的公式转化
14. TiDB-Server 对于 OLAP 查询会有的问题
- 对于那些 ORAP 中间结果过大的查询,会出现内存过度使用甚至 OM 的问题
15. 关于 TiDB 的 Region 的数据
- 尽量保证每个 Region 中保存的数据不超过一定的大小,TiKV 默认大小限制为 96MB
- Region 是 StartKey 到 EndKey 一个左闭右开的区间
- 当某个 Region 大小超过了某个限制时,TiKV 会把它分裂成两个甚至更多的 Region。
- 当某个 Region 因为大量的删除请求导致 Region 的大小变得更小时,TiKV 会将两个小的相邻的 Region 合并为一个
- PD 负责将 Region 尽可能均匀地、离散地分布在集群的所有节点上
16. 存储引擎的特定范畴
- 支持分布式事务
- 保证数据不丢失不出错
- 多副本保障一致性和高可用性
- 弹性扩容和缩容
17. TiSpark 的特点
- 可以识别 TiKV 的数据格式、统计信息、索引、执行器等
- 在面对大批量数据报表和重量级 Adhoc 时提供了可行的方案
- 只能提供低并发的重量级查询
- 模型重,资源消耗高
18. TiDB 技术架构的特点
- 自动分片技术是更细维度弹性的基础
- 弹性的分片构建了动态的系统
- Multi-Raft 将复制组更离散
- 基于 Multi-Raft 实现写入的线性扩展
- 基于 Multi-Raft 实现跨 IDC 单表多节点写入
- 去中心化的分布式事务
- Local Read and Geo-partition
- 更大数据容量下的 TP 与 AP 融合
- 数据服务的统一
19. CAP 理论
- 一致性:所有的节点在同一时间的数据完全一致
- 可用性:服务在正常响应时间内的可用
- 分区容忍性:分布式系统在遇到某节点或网络分区故障的时候仍然能够对外提供满足一致性或可用性的服务
20. 哪个客户端可以进行 TiDB 的连接
- Tiup client
- mysql
21. 哪些 TiDB 的特性使得其可以支持数据中台
- 海量存储允许多数据源汇聚,数据实时同步
- 支持标准 SQL,多表关联快速出结果
- 透明多业务模块,支持分表聚合后可以任务维度查询
- TiDB 最大下推机制、以及并行 hash join 等算子,决定的 TiDB在表关联上的优势
22. 关于 TiDB 的 MPP 结构
- MPP 架构将任务并行地分散到多个服务器和节点上,在每个节点上计算完成后将各自部分的结果汇总到一起得到最终结果
- 本质上是通过网络与存储成本来置换计算资源
- MPP 下,TiDB-Server 作为入口节点,通过代价决定是否经由 MPP 模式计算
- MPP 模式下,TiFlash 作为 MPP 计算节点
23. TiDB 分布式事务
- 默认乐观事务模型,也支持悲观事务模型
- 默认隔离级别:Snapshot Isolation,也支持 RC(提交读的隔离级别)
24. TiDB 数据库在 HTAP 的技术方向上已经实现的功能
- 分布式数据库是在更大数据规模下提供 HTAP 的基础
- TiDB-Server 最大程度下推算法与 Hash Join 关键算子提供了 OLAP 能力
- 借助生态,让 Spark 跑在 TiKV 上
- 行列混合引擎,列式引擎提供了实时写入能力
- 行列引擎采取 Raft-Base replication,解决了数据同步效率
- TiDB-Server 既支持标准 SQL,又可以自动路由行列引擎,逐渐形成了一个统一的数据查询服务
- MPP 并行计算模型解决了多表 Join 场景下的计算节点的扩展性以及并行计算能力
25. Placement Driver 的特性
- 管理分片的数据分布以及集群拓扑结构等元数据信息
- 负责 TiKV 节点的调度
- 通过 Raft 进行三副本复制
26. HTAP
- 场景的多样性会驱动细分技术的发展,而从使用以及业务副本成本的角度看,又希望数据服务具有统一性
- 2005年,Gartner 提出了 HTAP 的概念
- HTAP 数据库需要同时支持 OLTP 和 OLAP 场景
- 基于创新的计算存储框架在同一份数据上保证了事务的同时又支持实时分析,省去了费时的 ETL 的过程
27. 随着硬件性能的提升,传统的计算与存储强耦合的方式有哪些弊端
- 计算与存储强绑定,意味着两种资源总有一个是浪费的
- 我们在对服务器进行选型的过程中,开始纠结是计算型、还是存储型,大大增加复杂度和降低通用性
- 在云计算场景下,弹性的颗粒度是机器,不能真正做到资源的弹性
28. 分布式技术的主要挑战
- 如何最大程度实现分治
- 如何实现全局的一致性,包括全局序列化与全局时钟
- 如何进行故障与部分失效的容错
- 如何应对不可靠的网络与网络分区
29. TiDB 的数据分片采用的技术
- 使用自动分片(动态)而非预先分片(静态)
- 采取范围(range)分片方式,可以更高效地扫描数据记录,也可以简单实现自动完成分裂与合并,弹性优先,分片需要可自由调度
30. TiDB 数据库三层架构
- TiDB-Server:支持SQL的计算引擎
- TiKV:分布式存储引擎
- Placement Driver:负责元信息管理与调度的引擎
31. NewSQL 技术目前可以认为是哪两种技术的组合
- 关系型数据库和非关系型数据库
32. 关系型数据库四大特性
- 原子性
- 一致性
- 隔离性
- 持久性
33. TiDB 事务支持
- 用户可以一次性写入多个 key-value,而不必关心这些 key-value 是否处于同一个 Region 上,是否在同一个物理节点上
- TiDB 参考了 Google Percolator 事务模型,并在该模型基础上做了大量的优化与改进
- 默认隔离级别是 Snapshot Isolation
34. TiDB 数据库的两个比较重要的理论基础
- 2013年谷歌推出的 Spanner 和 F1 论文
- 2014年工业级分布式一致性协议实现的 Raft 博士论文
35. TiDB-Server 连接
- TiDB-Server 是一个对等、无状态的,可横向扩展的,支持多点写入的,直接承接用户 SQL 的入口
36. TiDB-Server 的特性
- 兼容 MySQL 协议的编码以及解码
- 每个 TiDB-Server 可以独立地进行 SQL 的执行
37. 传统的数据库分表分库中间件无法支持的特性
- 强一致的分布式事务
- 水平扩展
- 复杂查询
- 无人工介入的高可用
- 业务兼容性(低)
- 多维度支持(不友好)
- 全局 ID 支持 (不友好)
- 机器容量(很浪费)
38. 关于 TiDB 数据扩展性
- 数据支持自动分裂和合并分片
- TiDB 安装 range 进行分片
- 数据的存储、访问、复制、调度都是以 Region 为单位
- 为了保证上层客户端能访问所需要的数据,TiKV 中有一个组件记录 Region 在节点上面的分布情况,也就是说,通过任何一个 key,就能查询到这个 key 所在的 Region,以及这个 Region 所在的存储节点
39. TiDB 的两地三中心容灾方案
- 支持 RPO 为 0
- 基于 Raft
- 支持强一致性
40. 数据库技术发展的内在驱动
- 业务发展,主要体现在数据容量的持续爆发增长,其中数据容量包括数据存储量、吞吐量和读写QPS
- 场景创新,体现在数据模型与交互效率,如查询语言、计算模型、数据模型、读写延迟等
- 硬件与云计算的发展,主要体现在数据架构的变迁上,如计算与存储分离(读写分离)、一体机、云原生等
</article>