MySQL · 引擎特性 · Infobright 列存数据库

本文涉及的产品
云原生数据库 PolarDB MySQL 版,Serverless 5000PCU 100GB
云原生数据库 PolarDB 分布式版,标准版 2核8GB
云数据库 RDS MySQL Serverless,0.5-2RCU 50GB
简介: 简介 系统架构 存储引擎 优化器和执行器 数据装载和卸载 领域知识 查询优化 简单场景的示例 小结 存储结构 Data Pack Knowledge Node 数据压缩 总结简介Infobright 是一个面向 OLAP 场景的开源列

简介

Infobright 是一个面向 OLAP 场景的开源列存数据库。比较容易找到代码的版本是 Infobright Community Edition 4.0.7,大概是 2006 年前后的代码。2016 年6 月,Infobright 决定停止开源1。由于它同时提供企业版和社区版,开源版本的功能相比企业版而言,肯定是存在一些明显限制的,例如对查询的并行执行、查询的并发数都有一定的限制。Infobright 不仅有 MySQL 版本,也有 PostgreSQL 版本,是比较典型的走开源软件兼容生态路线的产品。深入了解它的最好途径是阅读它的文档以及源代码。Infobright 在 VLDB 2008 年的“Industrial, application, and experience sessions: query optimization”主题下有一篇 paper 2,比较详细的介绍了它的整体架构,以及查询优化、数据压缩等显著的特点。

系统架构

img

Infobright 的整体架构如上图。 相对于原生的 MySQL 而言,它主要做的改动为:

存储引擎

图中右下角的两个大长方形分别为“Knowledge Grid”和“Compressor/Decompressor”,二者共同组成了新的一个存储引擎 BrightHouse。这也是列存数据库区别于 InnoDB 等 OLTP 存储引擎的地方。知识网格可以简单理解为数据的元信息,例如记录数、最大值、最小值等等。压缩解压缩器代表了 Infobright 在数据压缩上做了很多工作,具备很高的压缩比。知识网格的好处是数据量相对原始数据而言很小,可以放到内存。

优化器和执行器

图中中间标记为“Infobright Optimizer and Executor”的是另一个重要的模块,负责处理 SQL 查询的优化和执行。与传统架构中查询优化与执行是分开的两个阶段不同,这里的优化器和执行器是紧耦合的。这也是 Infobright 比较特殊的地方。

数据装载和卸载

OLAP 通常要处理大量的输入数据,没有快速的数据装载和卸载能力,系统就无法发挥真正的价值。对应的是图中右上角的“Infobright Loader/Unloader”。

领域知识

图中还有一个比较特殊的模块,称为“Domain Injections/Decomposition Rules”。Infobright 提供了一些扩展的 SQL 和存储过程,允许用户定义取值规则,并且将规则应用到某些列上,从而使得存储模块在存储/压缩数据前可以将一个数据块内的数据分成更多的子类,并提供针对性的编码。可以简单理解为用户将领域知识通过自定义的规则告诉系统,从而采取针对性的压缩和存储优化。

查询优化

按照论文中的说法,Infobright 的查询优化基于粗糙集的理论,这一点很有特色。粗糙集是波兰数学家提出的理论,而 Infobright 公司是由波兰人创办的,看来把粗糙集应用到系统中也不是偶然的。不过要理解 Infobright 的查询优化,并不需要太多粗糙集的数学知识。其核心概念是利用数据的元信息来过滤需要真正访问的数据块。例如:对于范围查询,可以根据查询条件将数据块分为相关、不相关、可能相关三大类,从而减少真正的数据访问。这三种数据块的分类是粗糙集理论在该系统中用到的核心概念。更进一步,考虑到 OLAP 的数据是批量加载,而不是像 OLTP 那样实时写入的。对于 COUNT、SUM 等聚集操作,甚至可以通过预先计算好的统计值进行简单的运算得出。类似的,数据的批量加载以及只读假设也给数据的快速加载以及压缩提供了极大的便利。

简单场景的示例

后面通过一个简单的场景来体会一下知识网格的优势。假设我们要执行下面的查询:

SELECT count(*)
FROM   employees
WHERE salary > 100000
	AND age    < 35
	AND job    = ‘DBA’
	AND state  = ‘TX’

这是一个简单的带过滤条件的聚集查询。OLTP 数据库的通用做法是利用 salary 等列上可能存在的索引进行数据的过滤,减少 IO。实际的执行计划可能会用到多个索引。Infobright 没有索引,它依靠的是知识网格中的元信息。下图展现了 employees 表中各列数据的存储。每个菱形代表一个数据块。其中紫色的表示数据块中的所有值都不满足查询条件,蓝色的表示部分值满足查询条件,绿色的表示全部值都满足条件。

img

因为第 1、2、4 行中都存在紫色的菱形,说明它们代表的行都不符合查询条件,进一步处理的时候可以将它们忽略掉。只有第三行的数据块需要进一步处理。而查询的结果集是要计算符合条件的行数(COUNT),我们只需要选择那些部分匹配的数据块进行处理。本查询中只有 state 列的数据块满足条件如下图所示。这样最终需要解压并逐行进行 state > 10000 条件判断的数据量就少了很多。

img

小结

上面的例子虽然很简单,但可以看到 Infobright 查询优化的几个重要特点:

  1. 查询优化和执行时融合在一起的,一边优化边执行。这样的好处是可以充分利用知识网格来筛选数据,缺点是处理的查询种类有限,通用性不够。遇到不能通过知识网格有效筛选的查询,性能就会明显下降。
  2. 知识网格起到了典型数据库中索引的作用,可以筛选掉部分数据块。显然,它的选择性没有索引的针对性那么强。

论文2中还有一些更具体更复杂的例子,有兴趣的读者建议直接阅读原文,可以获得更加深入的理解。

存储结构

Infobright 的存储结构主要包括:

Data Pack

简称 DP,也就是数据块,用于存放实际的数据。需要注意的是,它采用的是列存格式,为每一个列产生一个或多个数据文件。这种数据格式与 OLTP 存储引擎的定长页面格式截然不同,倒是与 NoSQL 中的 SSTable 有几分神似。数据块中保存的是实际的数据以及空值的位图;数据在写出前会用多种压缩算法进行压缩;数据是没有经过排序的,按照实际加载的顺序保存。数据块在逻辑上是等长的,即每个数据块保存 65536 条记录,但是物理上不是等长的。

Knowledge Node

简称 KN,用于存放数据块对应的元数据,它又可以细分为以下几种。

  1. Data Pack Node

    简称 DPN,DP 的元信息存放在对应的 DPN 中。元信息包括:DP 中列值的最大值、最小值、SUM 值;非 NULL 的记录数,NULL 的记录数;压缩方式;占用的字节数等。

  2. Histograms

    数值类型列还会保存基本的统计信息,以直方图的形式存在。具体做法是将 DP 的最小值到最大值分为 1024 段,每段占用一个 bit,表示是否含有该段的数据。查询时可以快速判断该列数据是否满足条。可以看出,这个直方图的组织与 OLTP 数据库中的存在很大的区别,而且是每个 DP 的局部信息。

  3. Character Map

    简称 CMAP,这是一个字符类型列的映射表,映射表中每个格子占用一个 bit,表示字符在字符串的该位置是否存在。查询时可以快速判断该列数据是否满足条件。

    img

  4. Pack to Pack

    简称 P2P,这是一种很特殊的元数据,它存储两个表在列上的 JOIN 关系。形式有些类似 CMAP,也是一个二维矩阵。每个格子占用一个 bit,表示表 1 中某列的第 i 个 DP 与表 2 中某列的第 j 个 DP 至少有一个值相等,满足等值 JOIN 条件。可以看出,这种信息是与具体的 JOIN 条件相关的,数量可能很大,比较适合动态按需生成,不持久化。

  5. 小结

    下图将所有的概念都整合到了一起,是一个不错的整体视图。

img

值得一提的是,与 OLTP 引擎以及其他很多 OLAP 引擎不同的是,Infobright 中没有索引,它通过 DPN 等元信息以及特殊的查询优化来替代索引的功能。这样可以省去索引占用的存储空间,还可以较好的支持 ad-hoc 的查询,避免管理员调优等代价。其列存引擎也不需要用户定义数据块的大小,数据的存储顺序就是加载的顺序,避免了某些系统需要耗费大量资源到数据的排序上。

数据压缩

在当时的情况下,Infobright 的数据压缩算法也是很新颖的。号称平均可以达到 10:1 的压缩比,最高可以达到 40:1。实测的时候需要注意,压缩比的计算是与原始的文本数据比还是与 InnoDB 比。Infobright 会采用链式压缩,也就是对同样的数据块采用多种算法依次压缩,尽可能达到最大的压缩比。也针对数字和字符串采用多种具体的压缩算法。例如:让所有数字减去最小值,获得更小的数字;所有数字除以最大公约数,获得更小的数字;计算数字之间的差值,获得更小的数字等等。最终采用 PPM 以及 Carryless RangeCoder 等具体的编码。

总结

Infobright 官网宣传号称 40:1 的压缩率,每小时加载 10TB 数据,单实例支持 150TB 的存储,维护时间 0 小时3。新产品也对 Hadoop 生态有了一定的整合。总之,Infobright 是一个有意思的数据仓库产品,具有明显的特色。它以相对较小的存储空间膨胀达到了较好的处理 ad-hoc 查询的能力,比较适合查询分析语句不是特别复杂的场景。

参考资料

1 The Final Frontiers of ICE https://infobright.com/blog/the-final-frontiers-of-ice/

2 Brighthouse: An Analytic Data Warehouse for Ad-hoc Queries http://www.vldb.org/pvldb/1/1454174.pdf

3 Infobright Website https://infobright.com/infobright-enterprise-edition/

相关实践学习
基于CentOS快速搭建LAMP环境
本教程介绍如何搭建LAMP环境,其中LAMP分别代表Linux、Apache、MySQL和PHP。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助 &nbsp; &nbsp; 相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
相关文章
|
8天前
|
存储 关系型数据库 MySQL
MySQL引擎对决:深入解析MyISAM和InnoDB的区别
MySQL引擎对决:深入解析MyISAM和InnoDB的区别
24 0
|
12天前
|
关系型数据库 MySQL 数据库
卸载云服务器上的 MySQL 数据库
卸载云服务器上的 MySQL 数据库
30 0
|
2天前
|
SQL 关系型数据库 MySQL
MySQL环境搭建——“MySQL数据库”
MySQL环境搭建——“MySQL数据库”
|
2天前
|
SQL NoSQL 关系型数据库
初识MySQL数据库——“MySQL数据库”
初识MySQL数据库——“MySQL数据库”
|
4天前
|
关系型数据库 MySQL 数据库
数据库基础(mysql)
数据库基础(mysql)
|
4天前
|
SQL 关系型数据库 数据库
【后端面经】【数据库与MySQL】SQL优化:如何发现SQL中的问题?
【4月更文挑战第12天】数据库优化涉及硬件升级、操作系统调整、服务器/引擎优化和SQL优化。SQL优化目标是减少磁盘IO和内存/CPU消耗。`EXPLAIN`命令用于检查SQL执行计划,关注`type`、`possible_keys`、`key`、`rows`和`filtered`字段。设计索引时考虑外键、频繁出现在`where`、`order by`和关联查询中的列,以及区分度高的列。大数据表改结构需谨慎,可能需要停机、低峰期变更或新建表。面试中应准备SQL优化案例,如覆盖索引、优化`order by`、`count`和索引提示。优化分页查询时避免大偏移量,可利用上一批的最大ID进行限制。
32 3
|
5天前
|
存储 关系型数据库 MySQL
【后端面经】【数据库与MySQL】为什么MySQL用B+树而不用B树?-02
【4月更文挑战第11天】数据库索引使用规则:`AND`用`OR`不用,正用反不用,范围中断。索引带来空间和内存代价,包括额外磁盘空间、内存占用和数据修改时的维护成本。面试中可能涉及B+树、聚簇索引、覆盖索引等知识点。MySQL采用B+树,因其利于范围查询和内存效率。数据库不使用索引可能因`!=`、`LIKE`、字段区分度低、特殊表达式或全表扫描更快。索引与NULL值处理在不同数据库中有差异,MySQL允许NULL在索引中的使用。
10 3
|
7天前
|
关系型数据库 MySQL 数据库连接
Django(四):Django项目部署数据库及服务器配置详解(MySQL)
Django(四):Django项目部署数据库及服务器配置详解(MySQL)
29 11
|
16天前
|
SQL 数据可视化 关系型数据库
轻松入门MySQL:深入探究MySQL的ER模型,数据库设计的利器与挑战(22)
轻松入门MySQL:深入探究MySQL的ER模型,数据库设计的利器与挑战(22)
|
16天前
|
存储 关系型数据库 MySQL
轻松入门MySQL:数据库设计之范式规范,优化企业管理系统效率(21)
轻松入门MySQL:数据库设计之范式规范,优化企业管理系统效率(21)

相关产品

  • 云数据库 RDS MySQL 版