1. 数据库技术发展的顺序
关系型数据库 ( RDBMS ) -> NOSQL -> NewSQL -> HTAP
2. 相较于NoSQL,NewSQL的亮点
OLTP
NewSQL目标是将SQL的ACID保证与NoSQL的可扩展性和高性能相结合
3. MapReduce能解决什么问题
解决了在分布式文件系统和分布式 KV 存储上如何做分布式计算和分析的问题
关于MapReduce通过分治法解决问题的详细介绍:
Google MapReduce到底解决什么问题?_架构师之路-CSDN博客
4.分布式系统最多能满足一致性(Consistency)、可用性(Availability)和分区容错性(Partition Tolerance)中的哪几项
CAP理论指的是一个分布式系统最多只能同时满足一致性(Consistency)、可用性(Availability)和分区容错性(Partition tolerance)这三项中的两项。
- 满足CA舍弃P,也就是满足一致性和可用性,舍弃容错性。但是这也就意味着你的系统不是分布式的了,因为涉及分布式的想法就是把功能分开,部署到不同的机器上。
- 满足CP舍弃A,也就是满足一致性和容错性,舍弃可用性。如果你的系统允许有段时间的访问失效等问题,这个是可以满足的。就好比多个人并发买票,后台网络出现故障,你买的时候系统就崩溃了。
- 满足AP舍弃C,也就是满足可用性和容错性,舍弃一致性。这也就是意味着你的系统在并发访问的时候可能会出现数据不一致的情况。
大多数软件都选择了牺牲一致性。
5. 开源软件模式的特点
- 开放源码:吸引开发者共同参与,加快产品的迭代速度。
- 开放态度:更容易建立用户信任,在早期获取第一批使用者尤为重要,完成产品市场匹配度验证。
- 开源社区治理:通过社区方式构建人才生态、产品生态
6. TiDB 的分布式存储引擎
TiKV
7. TiKV系统采用的数据分片算法
range
8.TiKV 的整体架构由下向上为
RocksDB - > Raft 层 -> Transaction -> TiKV API + Corprocessor API
9. TiDB-Server 的内部结构由上到下
MySQL 协议层 - >SQL 核心层 ->数据获取的 API
10.TiDB Online DDL算法中异步在线 DDL 的核心是 Multi schema versions
TiDB 根据 Google F1 的在线异步 schema 变更算法实现,在 DDL 过程中并不会阻塞读写
11.TiDB-Server 的前台功能
- 管理连接和账号权限
- Golang 版本的 MySQL 协议的 SQL 解析
- 标准 SQL 语法
- 独立的SQL执行
12. 使得TiDB 可以支持数据中台的特性
- 支持数据实时同步和多数据源汇聚
- 支持标准 SQL
- TiDB 在表关联上的优势
13.TiDB 数据库在 HTAP 的技术方向上已经实现的功能
- 列式存储实现了实时写入能力
- MPP 解决节点的扩展性与并行计算
- 使 Spark 运行在 TiKV 上
14.TiKV中使用的MultiRaft的特点:
- 打散复制的分片
- 写入线性扩张
- 跨 IDC 单表多节点写入
15.TiDB 5.0 提供的分布式授时服务能够实现的功能
- 多地部署支持,低访问延时
- 数据安全合规,符合数据不出境场景
- 支持异地多活容灾
- 支持冷热数据分离
16.传统的数据库分表分库中间件无法支持的特性
- 强一致性分布式事务
- 全局 ID 的支持
17.TiDB的数据架构的特点
- 稳定
- 效率
- 成本
- 安全
- 开源
- 18.TiSpark 的特点
- 可以识别 TiKV 的数据格式、统计信息、索引、执行器等
- 在面对大批量数据报表和重量级 Adhoc 时提供了可行的方案
- 只能提供低并发的重量级查询
- 模型重,资源消耗高
19.数据库技术发展内在驱动
- 业务发展
- 场景创新
- 硬件与云计算的发展
业务发展需求最主要体现在数据容量持续爆发增长,数据容量不仅包括数据存储量,更重要的包括数据的吞吐量、读写 QPS 等。
场景创新主要体现数据的交互效率与数据模型多样性,比如查询语言、计算模型、数据模型、读写延时等。
硬件与云计算主要体现在数据架构的变迁上,比如读写分离、一体机、云原生等。
20.NewSQL 满足的需求
既要求支持事务(OLTP 场景)又同时兼容多种数据模式的可扩展需求
21.分布式系统定义
分布式系统是一种其组件位于不同的联网计算机上的系统,然后通过互相传递消息来进行通信和
协调。为了达到共同的目标,这些组件会相互作用
22.分布式系统的历史
2006 年,谷歌推出了 GFS(Google File System)、Google Bigtable、Google MapReduce 三大组件。
- Google File System 解决了分布式文件系统问题
- Google Bigtable 解决了分布式 KV(Key-Value)存储的问题
- Google MapReduce 解决了在分布式文件系统和分布式 KV 存储上面如何做分布式计算和分析的问题
23. 分布式技术的主要挑战
- 如何最大程度的实现分治;
- 如何实现全局的一致性,包括序列化与全局时钟;
- 如何进行故障与部分失效的容错;
- 如何应对不可靠的网络与网络分区;
24. CAP 理论补充
- 一致性指即所有节点在同一时间的数据完全一致。
- 可用性指服务在正常响应时间内一直可用。
- 分区容错性指分布式系统在遇到某节点或网络分区故障的时候,仍然能够对外提供满足一致性或可用性的服务
25. ACID 四个特性
- 原子性(Atomicity):事务包含的全部操作是一个不可分割的整体,要么全部执行,要么全部都不执行。
- 一致性( Consistency):事务前后,所有的数据都保持一致的状态,不能违反数据的一致性检查。
- 隔离性(Isolation):主要规定了各个事务之间相互影响的程度,主要用于规定多个事务访问同一数据资源,各个事务对该数据资源访问的行为。不同的隔离性是应对不同的现象,比如脏读、可重复读、幻读等
- 持久性(Durability):事务一旦完成,要将数据所做的变更记录下来(冗余存储或多数据网络备份)。
26. 分布式关系系统二个比较重要的基础
- 基于 2013 年 Google Spanner/ F1 论文
- 基于 2014 年 Stanford 工业级分布式一致性协议实现 Raft 博士论文
TiDB 就是在这两个理论基础上,通过开源社区的方式,涌现的一款很有代表性的原生分布式关系型数据库。它采取了兼容 MySQL 的策略,最初定位就是一个可以横向扩展的 MySQL,是一款分库分表的替代方案。它有很多标签,开源、原生分布式关系型数据库、HTAP 等等
27. 对数据库开发提出的要求:
- 扩展性
- 扩展性
- 标准 SQL 与事务(ACID)的支持
- 云原生数据库
- HTAP
- 兼容主流生态与协议
28. 对存储引擎的要求
- 更细粒度的弹性扩容、缩容
- 高并发读写
- 数据不丢不错
- 多副本保障一致性及高可用
- 支持分布式事务
参考资料: