閱讀854 返回首頁    go 阿裏雲 go 技術社區[雲棲]


一些存儲引擎存儲結構簡介

概述

本文簡要介紹了一些存儲引擎存儲結構,包括InnoDB, TokuDB, RocksDB, TiDB, CockroachDB, 供大家對比分析

InnoDB

InnoDB 底層存儲結構為B+樹,結構如下
image.png

B樹的每個節點對應innodb的一個page,page大小是固定的,一般設為16k。
其中非葉子節點隻有鍵值,葉子節點包含完成數據。
每個節點page節點結構如下
InnoDB Page Structure.jpg

數據記錄record按行存儲,record具體格式由row_format決定.

TokuDB

TokuDB 底層存儲結構為Fractal Tree
屏幕快照 2017-10-16 下午2.38.11.png

Fractal Tree的結構與B+樹有些類似, 在Fractal Tree中,每一個child指針除了需要指向一個child節點外,還會帶有一個Message Buffer ,這個Message Buffer 是一個FIFO的隊列,用來緩存更新操作。

例如,一次插入操作隻需要落在某節點的Message Buffer就可以馬上返回了,並不需要搜索到葉子節點。這些緩存的更新會在查詢時或後台異步合並應用到對應的節點中。

RocksDB

RockDB的存儲結構如下
xx.png

RocksDB寫入數據時,先寫到memtable中,memtable一般為skiplist, memtable寫滿時轉為immutable memtable並刷入Level 0.

Level0中的SST文件中的數據都是有序的,Level0中SST文件之間的數據範圍可能存在重疊。
其他Level中的SST文件之間的數據範圍不重疊。

RocksDB會以一定的機製從低level compact數據到高level中。

RocksDB中SST文件的結構如下
image.png

MyRocks使用的存儲引擎就是RocksDB, MyRocks的中RocksDB的數據映射關係參考之前的月報
image.png

TiDB

TiDB的存儲結構

image.png

TiDB是分布式存儲,分為兩個部分TiKV和Placement Driver server。
TiKV用於存儲真正的數據,TiKV由分布在不同機器上的RocksDB實例組成。
數據按範圍劃分為一個個Region. 並且會盡量保持每個 Region 中保存的數據不超過一定的大小(這個大小可以配置,目前默認是 64MB). 同一Region分布在不同的RocksDB實例中,一個RocksDB實例包含多個Region.
圖中,Region4有三個副本分布在三個RocksDB實例中,這三個Region副本組成一個RaftGroup,副本間通過Raft協議保證一致性。
Placement Driver server(PD), 也是一個集群,也通過Raft協議保證一致性。PD主要有以下作用:

  • 存儲region的位置等元數據信息
  • 調度和rebalance regions, TiKV中的Raft leader等信息
  • 分配全局事務ID

TiDB的數據映射關係
以下表為例

create table user(user_id int primary key, name varchar(100), email varchar(200));
INSERT INTO user VALUES (1, “bob”, “huang@pingcap.com”);
INSERT INTO user VALUES (2, “tom”, “tom@pingcap.com”);

對應到RocksDB中的KV結構如下

Key Values
user/1 bob huang@pingcap.com
user/2 tom tom@pingcap.com

CockroachDB

CockroachDB的存儲結構

image.png

image.png

CockroachDB的也是分布式存儲,其結構和TiDB類似。CockroachDB按範圍劃分為Range,Range默認為64M,Range的存儲為RocksDB, CockroachDB的一個node包含多個RocksDB實例。
Range副本分布在不同的node中,通過Raft協議保證一致。

Range的元數據信息也保存在Range中(靠前的Range中).

System keys come in several subtypes:

  • Global keys store cluster-wide data such as the "meta1" and "meta2" keys as well as various other system-wide keys such as the node and store ID allocators.
  • Store local keys are used for unreplicated store metadata (e.g. the StoreIdent structure). "Unreplicated" indicates that these values are not replicated across multiple stores because the data they hold is tied to the lifetime of the store they are present on.
  • Range local keys store range metadata that is associated with a global key. Range local keys have a special prefix followed by a global key and a special suffix. For example, transaction records are range local keys which look like: \x01ktxn-.
  • Replicated Range ID local keys store range metadata that is present on all of the replicas for a range. These keys are updated via Raft operations. Examples include the range lease state and abort cache entries.
  • Unreplicated Range ID local keys store range metadata that is local to a replica. The primary examples of such keys are the Raft state and Raft log.

CockroachDB的數據映射關係

以下表為例

create table mydb.customers(name varchar(100) primary key, address varchar(100) , URL varchar(100));
insert into mydb.customers values('Apple','1 Infinite Loop, Cupertino, CA','https://apple.com/');

表結構信息

Key Values
/system/databases/mydb/id 51
/system/tables/customer/id 42
/system/desc/51/42/address 69
/system/desc/51/42/url 66

表中的數據

Key Values
/51/42/Apple/69 1 Infinite Loop, Cupertino, CA
/51/42/Apple/66 https://apple.com/

最後

本文簡要介紹了各存儲引擎的結構,供大家參考,有錯誤之處請指正.

參考文檔

最後更新:2017-10-17 10:03:35

  上一篇:go  《時代周刊》文章: 那些泄密的技術宅
  下一篇:go  阿裏雲承建國家級工業雲平台 目標服務10萬家製造企業