[转帖]【TiDB】快速起步

tidb,快速,起步 · 浏览次数 : 0

小编点评

**存储引擎的特性** 1. **数据存储引擎**负责存储和检索数据。 2. **计算引擎**负责执行 SQL 查询并返回结果。 3. **placement driver**负责管理数据分布,并提供对数据库的透明访问。 4. **事务支持**确保多个 SQL 查询之间的隔离性和一致性。 5. **数据分片**将数据分发到多个区域,以提高性能和容错性。 **HTAP 的关键技术** 1. **分布式存储引擎**(TiDB-Server)提供高性能的写入和读取。 2. **Hash Join**允许在读取数据时进行快速匹配。 3. **Placements Driver**提供对数据分布的动态管理。 4. **Range Partitioning**用于高效的扫描数据记录。 **NewSQL 的优势** 1. **跨平台支持**,可用于各种编程语言。 2. **数据一致性**,确保数据的一致性。 3. **高性能**,提供响应式查询。 4. **可扩展性**,可以轻松扩展到多个节点。 **关系型数据库的四大特性** 1. **原子性**:所有事务性操作都是同步执行的。 2. **隔离性**:每个事务操作独立执行,不影响其他事务。 3. **持久性**:数据在系统崩溃时会持久化到磁盘中。 4. **多维度支持**:可以处理具有多个数据类型的查询。 **数据扩展性** 1. **数据分片**将数据分发到多个区域,以提高性能。 2. **动态自动扩展**根据需求自动扩展数据处理能力。

正文

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>

与[转帖]【TiDB】快速起步相似的内容:

[转帖]【TiDB】快速起步

1. 存储引擎的的功能 提供数据存储接口并持久化存储数据 2. LSM-tree 的特性 LSM-tree 结构本质上是一个用空间置换写入延迟,用顺序写入替换随机写入的数据结构 3. 数据库技术的发展 20世纪80年代,关系数据库发展2000年左右,NoSQL 发展2010年左右,NewSQL 发展

[转帖]TiKV & TiDB相关笔记

https://www.jianshu.com/p/1141be233bb2 一、TiKV存储 简述 通过单机的 RocksDB,TiKV 可以将数据快速地存储在磁盘上;通过 Raft,将数据复制到多台机器上,以防单机失效。数据的写入是通过 Raft 这一层的接口写入,而不是直接写 RocksDB。

[转帖]TiKV & TiDB相关笔记

https://www.jianshu.com/p/1141be233bb2 一、TiKV存储 简述 通过单机的 RocksDB,TiKV 可以将数据快速地存储在磁盘上;通过 Raft,将数据复制到多台机器上,以防单机失效。数据的写入是通过 Raft 这一层的接口写入,而不是直接写 RocksDB。

[转帖]Lightning 实操指南

2.2.2 Lightning 实操指南 这一节将介绍如何使用 Lightning 导入数据的实操 2.2.2.1 TiDB Lightning 快速开始 注意 TiDB Lightning 运行后,TiDB 集群将无法正常对外提供服务。 若 tidb-lightning 崩溃,集群会留在“导入模式

[转帖]TIKV扩容之刨坑填坑​

01 背景 某tidb集群收到告警,TIKV 节点磁盘使用率85%以上,联系业务无法快速删除数据,于是想到扩容TIKV 节点,原先TIKV 节点机器都是6TB的硬盘,目前只有3TB的机器可扩,也担心region 均衡后会不会打满3TB的盘,PD 调度策略来看应该是会根据不同存储机器的资源配置和使用情

[转帖]【SOP】最佳实践之 TiDB 业务写变慢分析

https://zhuanlan.zhihu.com/p/647831844 前言 在日常业务使用或运维管理 TiDB 的过程中,每个开发人员或数据库管理员都或多或少遇到过 SQL 变慢的问题。这类问题大部分情况下都具有一定的规律可循,通过经验的积累可以快速的定位和优化。但是有些情况下不一定很好排查

[转帖]使用 Dumpling 导出数据

16 Contributors 使用数据导出工具 Dumpling,你可以把存储在 TiDB 或 MySQL 中的数据导出为 SQL 或 CSV 格式,用于逻辑全量备份。Dumpling 也支持将数据导出到 Amazon S3 中。 要快速了解 Dumpling 的基本功能,建议先观看下面的培训视频

[转帖]TiDB损坏多副本之有损恢复处理方法

https://tidb.net/blog/b1ae4ee7 TiDB分布式数据库采用多副本机制,数据副本通过 Multi-Raft 协议同步事务日志,确保数据强一致性且少数副本发生故障时不影响数据的可用性。在三副本情况下,单副本损坏可以说对集群没什么影响,但当遇到多副本损坏的损坏丢失的时候,如何快

[转帖]TiDB 适配应用实践:MyBatis 3.5.X 在 JDK8 中性能问题的排查与优化

https://zhuanlan.zhihu.com/p/371638037 作者介绍:PingCAP Tech Center,于旸。 最近有金融客户使用 TiDB 适配批处理场景,数据量在数亿级。对于相同数据量的处理耗时,TiDB 要 35 分钟,而某商业数据库只要 15 分钟,足足相差 20 分

[转帖]tidb集群部署

http://blog.itpub.net/29785807/viewspace-2789852/ 一.安装规划 1 2 3 4 5 6 使用15台服务器 5台tidb服务器:每台3个tidb实例+1个pd+1个pump 10台tikv服务器:每台4个tikv实例 drainer_servers 安