解决的问题
1.关于
其实不用担心，直接手动选择iso文件所在地址就可以点击下一步继续操作了
2.安装虚拟机后一启动就出现蓝屏，显示您的设备遇到问题需要重启，当时我安装的是VMware15.5版本，后来更新到VMware16版本运行虚拟机就不会蓝屏了
TiDB管理基础
基于分布式数据库的HTAP数据服务
HTAP发展的必然性，InfoQ官网：为什么是HTAP
1、OLAP 和 OLTP 系统间通常会有几分钟甚至几小时的时延，OLAP 数据库和 OLTP 数据库之间的一致性无法保证，难以满足对分析的实时性要求很高的业务场景。
2、企业需要维护不同的数据库以便支持两类不同的任务，管理和维护成本高。
TiDB被“意外”用于数据中台
- 海量存储允许多数据源汇聚,数据实时同步
- 支持标准SQL,多表关联快速出结果
- 透明多业务模块、支持分表聚合后可以任务维度查询
- TiDB最大下推机制、以及并行hash join等算子决定的 TiDB,在表关联上的优势
引入spark来缓解数据中台算力问题
Spark只能提供低并发的重量级查询，在从应用场景，很多中小规模的轻量AP查询，也需要高并发、相对低延迟技术能力，在这种场景下，Spark的技术模型重，资源消耗高的缺点就会暴露。
物理隔离是最好的资源隔离
列存天然对OLAP查询类友好,所以我们选择将这个副本放到一个列式引擎上。（越接近物理机的隔离隔离性会越好）（对实时更新不友好，引入了DeltaMerge实现了列存储的实时更新）
行列数据同步，Raft-base最佳方案
TiFlash 以 Raft Learner方式接入Multi-Raft组，使用异步方式传输数据，对TikKV产生非常小的负担。
当数据同步到TiFlash时，会被从行格式拆解为列格式。（保证了写入效率，又避免了极低延时同步）
（一部分通过行存进行了过滤，一部分通过列存实现了列聚合）
分布式里面一个很重要的优化就是最大程度的下推，就是利用分布式节点上进行本地寻址过滤
TiDB关键技术创新
- 分布式的KV存储系统
- 分布式SQL计算系统
- 分布式的HTAP架构系统
1.自动分片技术是更细维度弹性的基础
- 全局有序的KV map
- 按照等长大小策略自动分片(96 M)每个分片是连续的KV，通过
- Start/End Key来寻址
- 每个分片seek成本固定
- 我们称该分片为 Region，它是复制、调度的最小单位
2.弹性的分片构建成了动态的系统
3.Multi-Raft将复制组更离散
- Raft、Multi - raft
- leader、follower、learner
- 目前是强主模式、读写在leader 上4.0版本开启follower read
4.基于Multi-Raft实现写入的线性扩展
当我们新增一个物理节点时，也就意味着整个集群的写入容量会进行线性增长。
5.基于Multi-Raft 实现跨IDC单表多节点写入
Region base Multi-Raft的机制，实现了一个表可以同时有多个写入点，TiKV的调度机制，可以识别单个节点的物理信息，比如IDC、REC、Host等(机房、机柜、宿主机等)，并进行约束与绑定。
(最终可以实现一个表可以跨IDC多个写入)
6.去中心化的分布式事务
7.Local Read and Geo-partition(多地多活跨地域事务式分布)
提高场景的数据性能以及降低延迟
- 多地部署支持,低访问延时
- 数据安全合规,符合数据不出境场景
- 支持异地多活容灾
- 支持冷热数据分离
冷热数据分离，所谓的冷热数据，其实就是根据访问频次来划分的，访问频次较多的数据是热数据，访问频次少的数据是冷数据。 冷热数据分离就是把这两类数据分离到不同的表中，从而减少热数据表的大小。 其实在很多地方大家都能看到类似的实现，比如去一些网站查询订单或者交易记录，默认只允许查询1到3个月，3个月之前的数据，基本上大家都很少关心，访问频次较少，所以可以把3个月之前的数据保存到冷库中。
8.更大数据容量下的TP与AP融合
TiDB引入了实时更新的列式引擎，即解决了资源隔离，又提升了AP效率。
- TiDB引入了实时更新的列式引擎，即解决了资源隔离，又提升了AP效率
- 在列存上引入 MPP模型，实现了SQLjoin的下推与并行处理
- 通过Raft-base replication实现了更时效性
- 融合大数据生态，比如TiSpark
9.数据服务的统一
TiDB的CBO可以采集行列Cost模型进行配置，并同步收集不同引擎的统计信息，统一进行最佳执行路径的选择。
课后问题：TiDB在HTPA服务领域的下一步创新可能是什么？
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
