Infobright构架解析

本文涉及的产品
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
全局流量管理 GTM,标准版 1个月
云解析 DNS,旗舰版 1个月
简介: Infobright构架解析

 Infobright的总体构架图如下:


如上图所示,Infobright采用了和MySQL一致的构架,分为两层。上层是服务及应用管理,下层是存储引擎。Infobright的默认存储引擎是brighthouse,但是Infobright还可以支持其他的存储引擎,比如MyISAM、MRG_MyISAM、Memory、CSV。Infobright通过三层来组织数据,分别是DP(Data Pack)、DPN(Data Pack Node)、KN(Knowledge Node)。而在这三层之上就是无比强大的知识网络(Knowledge Grid)。

  数据块(DP)是存储的最低层,列中每64K个单元组成一个DP。DP比列更小,具有更好的压缩比率;又比单个数据单元更大,具有更好的查询性能。

  数据块节点(DPN),DPN和DP之间是一对一的关系。DPN记录着每一个DP里面存储和压缩的一些统计数据,包括最大值、最小值、null的个数、单元总数count、sum等等。

  KN里面存储着指向DP之间或者列之间关系的一些元数据集合,比如值发生的范围(MIin_Max)、列数据之间的关联。大部分的KN数据是装载数据的时候产生的,另外一些事是查询的时候产生。

  在这三层之上是知识网络(Knowledge Grid),Knowledge Grid构架是Infobright高性能的重要原因。


  Knowledge Grid可分为四部分,DPN、Histogram、CMAP、P-2-P。

  DPN如上所述。Histogram用来提高数字类型(比如date,time,decimal)的查询的性能。Histogram是装载数据的时候就产生的。DPN中有mix、max,Histogram中把Min-Max分成1024段,如果Mix_Max范围小于1024的话,每一段就是就是一个单独的值。这个时候KN就是一个数值是否在当前段的二进制表示。


  Histogram的作用就是快速判断当前DP是否满足查询条件。如上图所示,比如select id from customerInfo where id>50 and id<70。那么很容易就可以得到当前DP不满足条件。所以Histogram对于那种数字限定的查询能够很有效地减少查询DP的数量。

  CMAP是针对于文本类型的查询,也是装载数据的时候就产生的。CMAP是统计当前DP内,ASCII在1-64位置出现的情况。如下图所示


  比如上面的图说明了A在文本的第二个、第三个、第四个位置从来没有出现过。0表示没有出现,1表示出现过。查询中文本的比较归根究底还是按照字节进行比较,所以根据CMAP能够很好地提高文本查询的性能。

  Pack-To-Pack是Join操作的时候产生的,它是表示join的两个DP中操作的两个列之间关系的位图,也就是二进制表示的矩阵。

  Knowledge Grid还是比较复杂的,里面还有很多细节的东西,可以参考官方的白皮书和Brighthouse: an analytic data warehouse for ad-hoc queries这篇论文。

参考

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







目录
相关文章
|
1月前
|
存储 SQL Apache
Apache Doris 开源最顶级基于MPP架构的高性能实时分析数据库
Apache Doris 是一个基于 MPP 架构的高性能实时分析数据库,以其极高的速度和易用性著称。它支持高并发点查询和复杂分析场景,适用于报表分析、即席查询、数据仓库和数据湖查询加速等。最新发布的 2.0.2 版本在性能、稳定性和多租户支持方面有显著提升。社区活跃,已广泛应用于电商、广告、用户行为分析等领域。
Apache Doris 开源最顶级基于MPP架构的高性能实时分析数据库
|
4月前
|
缓存 Cloud Native 关系型数据库
MPP架构数据仓库使用问题之Calcite 是一个什么样的类库,它主要用于什么地方
MPP架构数据仓库使用问题之Calcite 是一个什么样的类库,它主要用于什么地方
|
7月前
|
存储 关系型数据库 MySQL
十八、MySQL数据库引擎
十八、MySQL数据库引擎
86 0
|
存储 SQL 缓存
探秘MySQL底层架构:设计与实现流程一览
Mysql,作为一款优秀而广泛使用的数据库管理系统,对于众多Java工程师来说,几乎是日常开发中必不可少的一环。无论是存储海量数据,还是高效地检索和管理数据,Mysql都扮演着重要的角色。然而,除了使用Mysql进行日常开发之外,我们是否真正了解它的底层架构以及设计实现的流程呢?本篇博客将带您深入探索Mysql底层架构的设计与实现流程,帮助您更好地理解和应用这个强大的数据库系统。让我们一同揭开Mysql底层的神秘面纱,探寻其中的奥秘。
36773 14
探秘MySQL底层架构:设计与实现流程一览
|
NoSQL 关系型数据库 测试技术
【NoSQL】NoSQL之redis安装及配置与优化(简单操作)(一)
【NoSQL】NoSQL之redis安装及配置与优化(简单操作)(一)
【NoSQL】NoSQL之redis安装及配置与优化(简单操作)(一)
|
存储 SQL 缓存
高性能分布式No SQL数据库Aerospike(三)——常用工具使用
高性能分布式No SQL数据库Aerospike(三)——常用工具使用
481 0
高性能分布式No SQL数据库Aerospike(三)——常用工具使用
|
存储 SQL 大数据
总结OLAP系统核心技术点,每一点都值得单独收藏
  OLAP系统广泛应用于BI、Reporting、Ad-hoc、ETL数仓分析等场景,本文主要从体系化的角度来分析OLAP系统的核心技术点,从业界已有的OLAP中萃取其共性,分为谈存储,谈计算,谈优化器,谈趋势4个章节。   一、谈存储   1、列存的数据组织形式   行存,可以看做NSM (N-ary Storage Model)组织形式,一直伴随着关系型数据库,对于OLTP场景友好,例如innodb[1]的B+树聚簇索引,每个Page中包含若干排序好的行,可以很好的支持tuple-at-a-time式的点查以及更新等。   而列存(Column-oriented Storage)
724 0
|
SQL 分布式计算 数据可视化
关于内部OLAP工具的一些设计思路
更新: 内部olap工具终于来了 https://deepinsight.alipay.com/index.htm#/list/self-analysis ----------------------------------------------------- 最近一年在蚂蚁接触了很多的数据分析需求,会用到各种交付工具,总的来说是非常方便的,唯一一个没有找到最佳实践的需求场景是OL
437 0
关于内部OLAP工具的一些设计思路
|
SQL 分布式计算 大数据
分布式SQL引擎是如何炼成的 —— 运行时探秘(上)
##概述 生逢DT时代,为了能从价值密度低下的海量数据中淘出真金,人们开发了各种各样的计算数据的利器。自Google陆续发布后来被誉为“三架马车”的三篇著名的论文之后,大数据技术逐步进入了高速发展期。放眼业界,这些年计算技术层出不穷、百花齐放。计算引擎从Hadoop MapReduce、Apache Hive发展至如今如日中天的Apache Spark、Apache Flink。计算范式从批
2540 0
|
存储 关系型数据库 数据库
《高性能MYSQL》逻辑结构-读书笔记
高性能MYSQL笔记 1. MYSQL逻辑结构 MYSQL逻辑结构有三层,分别为  1. 连接/线程处理:实现连接处理,授权认证,安全等  2. 服务层:该层主要有缓存,解析,处理,优化以及跨存储引擎如存储过程,触发器,视图等  3. 存储引擎:主要负责数据读取和存储。
1680 0