MySQL · 特性介绍 · 一些流行引擎存储格式简介

概述

本文简要介绍了一些存储引擎存储结构，包括InnoDB, TokuDB, RocksDB, TiDB, CockroachDB, 供大家对比分析

InnoDB

InnoDB 底层存储结构为B+树，结构如下

B树的每个节点对应innodb的一个page，page大小是固定的，一般设为16k。
其中非叶子节点只有键值，叶子节点包含完整数据。
InnoDB按segment, extent, page方式管理page

每个数据节点page结构如下

数据记录record按行存储，record具体格式由row_format决定.
详情可以参考数据内核月报

TokuDB

TokuDB 底层存储结构为Fractal Tree

Fractal Tree的结构与B+树有些类似, 在Fractal Tree中，每一个child指针除了需要指向一个child节点外，还会带有一个Message Buffer ，这个Message Buffer 是一个FIFO的队列，用来缓存更新操作。

例如，一次插入操作只需要落在某节点的Message Buffer就可以马上返回了，并不需要搜索到叶子节点。这些缓存的更新会在查询时或后台异步合并应用到对应的节点中。

RocksDB

RockDB的存储结构如下

RocksDB写入数据时，先写到memtable中,memtable一般为skiplist, memtable写满时转为immutable memtable并刷入Level 0.

Level0中的SST文件中的数据都是有序的，Level0中SST文件之间的数据范围可能存在重叠。
其他Level中的SST文件之间的数据范围不重叠。

RocksDB会以一定的机制从低level compact数据到高level中。

RocksDB中SST文件的结构如下

MyRocks使用的存储引擎就是RocksDB, MyRocks的中RocksDB的数据映射关系参考 之前的月报

TiDB

TiDB的存储结构

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的存储结构

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','http://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 http://apple.com/

最后

本文简要介绍了各存储引擎的结构，供大家参考，有错误之处请指正.

参考文档

时间： 2024-10-27 10:35:27

MySQL · 特性介绍 · 一些流行引擎存储格式简介的相关文章

PgSQL · 引擎介绍 · 向量化执行引擎简介

摘要 本文为大家介绍一下向量化执行引擎的引入原因,前提条件,架构实现以及它能够带来哪些收益. 希望读者能够通过对这篇文章阅读能够对向量化执行引擎的应用特征与架构有一个概要的认识. 关键字 向量化执行引擎, MonetDB,Tuple, 顺序访问,随机访问, OLAP, MPP,火山模型,列存表,编译执行 背景介绍 过去的20-30年计算机硬件能力的持续发展,使得计算机的计算能力飞速提升.然后,我们很多的应用却没有做到足够的调整到与硬件能力配套的程度,因此也就不能够充分的将计算机强大的计算能力转换

MySQL数据库三种常用存储引擎特性对比_Mysql

MySQL 的存储引擎可能是所有关系型数据库产品中最具有特色的了,不仅可以同时使用多种存储引擎,而且每种存储引擎和MySQL之间使用插件方式这种非常松的耦合关系. 由于各存储引擎功能特性差异较大,这篇文章主要是介绍如何来选择合适的存储引擎来应对不同的业务场景. MyISAM 特性 不支持事务:MyISAM存储引擎不支持事务,所以对事务有要求的业务场景不能使用 表级锁定:其锁定机制是表级索引,这虽然可以让锁定的实现成本很小但是也同时大大降低了其并发性能 读写互相阻塞:不仅会在写入的时候阻塞读取,M

ITTC数据挖掘平台介绍（综述）——平台简介

数据挖掘方兴未艾,大量新事物层出不穷.本系列将介绍我们自主设计的数据挖掘软件平台.与大家共同分享对知识,微博,人际等复杂网络的分析,以及对自然语言处理的见解. 一.我们需要怎样的数据挖掘系统       一直以来,以高校为代表的学术界和以公司为代表的商业界,都有很大的隔阂.学术界普遍不会做产品,商业界普遍不会搞研究.如果两者都强,那就是美国军方了.        在数据挖掘领域更是如此,大量关于复杂网络,自然语言处理的牛文层出不穷,却被研究机构和大公司养在深闺人未识.绝大多数智能机器学习算法被封

**关于mysql5.7版本新特性介绍 ------数据类型 JSON**

关于mysql5.7版本新特性介绍 ------数据类型 JSON 测试环境: Win10.mysql 5.7.14 内容简介:随着mysql5.7版本的到来,大家对其的热情也越来越高涨,身为mysql圈子里的一员,我本身也对mysql5.7的一些新特性有所了解,通过学习了解到了很多新的特性,今天给大家介绍一下它在灵活性方面的一个新的功能:提供对JSON的支持 JSON介绍 首先介绍一下什么是JSON: > JSON(JavaScript Object Notation, JS 对象标记) 是一

在应用中加入全文检索功能——基于Java的全文索引引擎Lucene简介

全文检索|索引 内容摘要: Lucene是一个基于Java的全文索引工具包. 基于Java的全文索引引擎Lucene简介:关于作者和Lucene的历史 全文检索的实现:Luene全文索引和数据库索引的比较 中文切分词机制简介:基于词库和自动切分词算法的比较 具体的安装和使用简介:系统结构介绍和演示 Hacking Lucene:简化的查询分析器,删除的实现,定制的排序,应用接口的扩展 从Lucene我们还可以学到什么 基于Java的全文索引/检索引擎--Lucene Lucene不是一个完整的全

MySql中启用InnoDB数据引擎的方法

1.存储引擎是什么? Mysql中的数据用各种不同的技术存储在文件(或者内存)中.这些技术中的每一种技术都使用不同的存储机制.索引技巧.锁定水平并且最终提供广泛的不同的功能和能力.通过选择不同的技术,你能够获得额外的速度或者功能,从而改善你的应用的整体功能.这些不同的技术以及配套的相关功能在MySQL中被称作存储引擎(也称作表类型).MySql默认配置了许多不同的存储引擎,可以预先设置或者在MySql服务器中启用. 2.MYSQL支持的数据引擎 MyISAM:默认的MySQL插件式存储引擎,它是

《Java数字图像处理：编程技巧与应用实践》——1.4　Swing Java 2D的其他高级特性介绍

1.4 Swing Java 2D的其他高级特性介绍 1 . Stroke接口 Stroke是Graphics2D的API接口,用来实现图形的描边修饰,在Java 2D中只有一个完成Stroke接口的类BasicStroke,如果有需要,可以自己完成Stroke接口,实现自定义的Stroke类.如何使用Stroke的实现类?方法如下: 1)调用Graphics2D 的setStroke()方法,传入一个实例化的Stroke对象. 2)调用draw()方法,传入要绘制的几何形状. BasicStr

MYSQL 浅谈MyISAM 存储引擎_Mysql

思维导图      介绍          mysql中用的最多存储引擎就是innodb和myisam.做为Mysql的默认存储引擎,myisam值得我们学习一下,以下是我对<高性能MYSQL>书中提到的myisam的理解,请大家多多指教.    特点   > 不支持事务     证明如下:      >> 表记录:t2表的engine是myisam.       >> 操作 注意:如果你在数据库进行事务操作,但是事务无法成功,你就要看你的表引擎了,看这种引擎是否

MYSQL 浅谈MyISAM 存储引擎

思维导图    介绍        mysql中用的最多存储引擎就是innodb和myisam.做为Mysql的默认存储引擎,myisam值得我们学习一下,以下是我对<高性能MYSQL>书中提到的myisam的理解,请大家多多指教.  特点 > 不支持事务   证明如下:     >> 表记录:t2表的engine是myisam. >> 操作 注意:如果你在数据库进行事务操作,但是事务无法成功,你就要看你的表引擎了,看这种引擎是否支持事务.>> 下面请