【笔记】TiDB技术内幕--说存储

原文地址:三篇文章了解 TiDB 技术内幕——说存储

保存数据

待解决的问题

  • 基本要求:保证数据不丢不错
  • 能否支持跨数据中心的容灾
  • 写入速度是否够快?
  • 数据保存下来后,是否方便读取?
  • 保存的数据如何修改?如何支持并发的修改?
  • 如何原子地修改多条记录?

数据的存储模型

Key-Value

TiKV选择的是Key-Value模型,并提供有序的便利方法。

简单来讲,可以将 TiKV 看做一个巨大的 Map,其中 Key 和 Value 都是原始的 Byte 数组,在这个 Map 中,Key 按照 Byte 数组总的原始二进制比特位比较顺序排列。

因为键值对是按照Key的二进制顺序来存储的,所以也就是找到某一个Key的位置后,可以不断的调用Next方法递增的获取比这个Key大的Key-Value。

RocksDB

任何持久化的存储引擎,数据终归要保存在磁盘上,TiKV 也不例外。

TiKV 没有选择直接向磁盘上写数据,而是把数据保存在 RocksDB 中,具体的数据落地由 RocksDB 负责。

RocksDB是一个非常优秀的开源单机存储引擎,有Facebook的团队在做持续的优化,可以认为RocksDB是一个单机的Key-Value Map。

Raft

前述已经已经解决了数据高效可靠的本地存储。但如何保证单机失效的情况下,数据不丢失,不出错?

简单来说,我们需要想办法把数据复制到多台机器上,这样一台机器挂了,我们还有其他的机器上的副本;复杂来说,我们还需要这个复制方案是可靠、高效并且能处理副本失效的情况。听上去比较难,但是好在我们有 Raft 协议。Raft 是一个一致性算法,它和 Paxos 等价,但是更加易于理解。

在分布式系统的Raft算法中详细说明了Raft算法的原理,并做了动画演示,文末也有Raft论文的地址。
PingCAP的首席架构师唐刘的文章详细的解释了他们对Raft协议所做的大量优化。

总结一下,通过单机的 RocksDB,我们可以将数据快速地存储在磁盘上;通过 Raft,我们可以将数据复制到多台机器上,以防单机失效。数据的写入是通过 Raft 这一层的接口写入,而不是直接写 RocksDB。

Region
MVCC
事务

你可能感兴趣的:(【笔记】TiDB技术内幕--说存储)