hbase mongodb hive starrocks比较

本文是在学习大数据的几个数据存储系统相关的组件所记录下来的，主要是不同组件的基础概念初步了解与对比。

NoSql

在大数据时代，虽然RDBMS很优秀，但是面对快速增长的数据规模和日渐复杂的数据模型，RDBMS渐渐力不从心，无法应对很多数据库处理任务，这时NoSQL凭借易扩展、大数据量和高性能以及灵活的数据模型成功的在数据库领域站稳了脚跟。Nosql无需实现为数据定义一个模式，可以更灵活地适配各种数据。

目前大家基本认同将NoSQL数据库分为四大类：键值存储数据库，文档型数据库，列存储数据库和图形数据库，其中每一种类型的数据库都能够解决关系型数据不能解决的问题。在实际应用中，NoSQL数据库的分类界限其实没有那么明显，往往会是多种类型的组合体。

HBase

HBase是基于Google BigTable的开源实现，由Apache软件基金会维护。它是一个分布式的、可扩展的、高性能的NoSQL数据库，用于存储大规模结构化数据。实际上就是为了解决海量数据的存储和读取问题的。

概述

类型：分布式 NoSQL 数据库

数据模型：面向列的存储模型

主要用途：实时读写和随机访问大规模数据

底层存储：HDFS（Hadoop Distributed File System）

架构：采用分布式架构 Map/reduce

特点

高吞吐量：适合高吞吐量的读写操作。

低延迟：支持低延迟的随机读写。堪比MySQL的随机访问性能。适合存储PB级别的海量数据，在几十~百毫秒内返回数据。

强一致性：提供强一致性保证。

扩展性：可以水平扩展，处理 PB 级别的数据。

hbase为什么读取速度快：

列式存储结构：HBase是一种基于列式存储的数据库，与传统的行式数据库不同，HBase将同一列的数据存储在一起，相同的数据被存储在相邻的单元格中。这种存储方式使得HBase查询时只需要读取必要的列，可以大大减少查询所需的数据量，提高查询速度。 HBase的row key是经过排序的,可以快速定位数据。

分布式存储：HBase是一种分布式的数据库，数据按照Region分割存储在多台服务器上。查询时可以同时从多台服务器中读取数据，大大提高了查询效率。关于region:region类似关系型数据库的分区，数据存放在region中，region下面还有很多结构，确切地说存放在memstore和Hfile中，访问Hbase时先去Hbase系统表查找定位这条记录属于哪个region，然后定位到这个region属于哪个服务器，再到对应服务器去查找数据。

基于索引的查询：HBase支持对行键(rowkey)的索引，可以通过检索行键来快速定位数据，避免了全表扫描和遍历的过程，从而大大提高了查询速度。

数据的本地化存储：HBase允许在Region服务器上进行查询操作，从而避免了将数据传输到客户端，能够大幅度提高查询性能。

查询过程中，HBase会将查询请求发给HMaster，HMaster会给出存储该数据的RegionServer的地址以及包含所需数据的Region记录。然后客户端与该RegionServer进行通信，获取所需数据。同时，HBase采用多级缓存机制，当RegionServer接收到查询请求时，首先检查本地内存中是否有所需数据。如果有，则直接返回结果。如果没有，则从磁盘中读取，同时将读取到的数据存储到缓存中，以便后续查询。

优点：

1） 存储容量大，一个表可以容纳上亿行，上百万列；

2）可通过版本进行检索，能搜到所需的历史版本数据；

3）负载高时，可通过简单的添加机器来实现水平切分扩展，跟Hadoop的无缝集成保障了其数据可靠性（HDFS）和海量数据分析的高性能（MapReduce）；

4）在第3点的基础上可有效避免单点故障的发生。

典型应用场景

实时数据存储和检索

在线服务的数据存储

需要快速随机读写的大数据应用

对数据有版本查询需求；

比如以具体互联网公司为例：

Facebook用户交互
这是一个典型的例子，被引用的次数不计其数，Facebook的Like按钮被点了多少次、有多少人浏览过某篇文章、有多少人喜欢这篇文章等数据是由HBase的计数器来存储的，发布者能够实时地看到有多少人给他点赞、有多少人喜欢他的文章。

淘宝TLog
淘宝TLog是一个分布式的、可靠的，对大量数据进行收集、分析和展现的系统。TLog的主要应用场景是收集大量的运行时日志，然后分析存储，最后提供数据查询和展现。淘宝的“鹰眼系统”（对请求从开始到结束整个生命周期的追踪，包括哪一步到了哪台机器、每一步花了多长时间、与多少系统有交互等）就是TLog的接入方，每天有上万台机器接入TLog，数据量多达上百TB，其底层就是使用HBase作为存储层的。

使用

hbase在大数据体系下的位置：其实可以当场大数据体系下的Database来用，任何可以分析Hbase的引擎比如mr、hive、spark等框架连接上Hbase都可以实现控制，比如可以把Hive跟HBase进行关联，这样Hive中数据不再由HDFS存储而是存储在HBase中，关联Hive后也可以在Hbase中看到数据。

在hbase单机版只需要配置指定hbase和zookeerper写入数据的路径，如下：

hbase对列的数量没有限制，所以很适合存储不确定列、不确定大小的半结构的数据

Hbase的数据写入后不会被修改，数据的put操作在写预写入日志后，会先写入内存存储，同时在内存中按行键排序，等到合适的时候会将memStore中的数据刷新到磁盘的存储文件，带来的问题就是数据会有多个版本，这个数据有一个时间戳来标识数据写入时间。

Hbase中的概念：

HBase数据行可以类比成一个多重映射（multiple map），通过多重的键（key）层层递进可以定位一个值（value）。因为HBase数据行列值可以是空白的（这些空白列是不占用存储空间的），所以HBase存储的数据是稀疏的。

（1）命名空间（namespace）：命名空间是一些逻辑上有着关联关系的表的集合，类似于关系数据库中的database。HBase可以在命名空间层级做一些资源管理（如限制命名空间能够创建的表和分区数量）、安全权限管理、将某个命名空间指定到某些分区服务器运行以实现某种程度的资源隔离。
（2）表（table）：类似于关系数据库中的表，即数据行的集合。表名用字符串表示，一个表可以包含一个或者多个分区。
（3）行键（row key）：用来标识表中唯一的一行数据，以字节数组形式存储，类似于关系数据库中表的主键（不同的是从底层存储来说，行键其实并不能标识唯一的一行数据，因为HBase数据行可以有多个版本。但是，一般在不指定版本或者数据时间戳的情况下，用行键可以获得当前最新生效的这行数据。因此，从用户视图来说，默认情况下，行键能够标识唯一的一行数据），同时行键也是HBase表中最直接、最高效的索引，表中数据按行键的字典序排序。
（4）列族（column family）：HBase是一个列式存储数据库，所谓列式就是根据列族存储，每个列族一个存储（Store），每个Store有多个存储文件（StoreFile）来存储实际数据。
（5）列限定符（columnqualifier）：每个列族可以有任意个列限定符来标识不同的列，列也类似于关系数据库表的一列，与关系数据库不同的是列无须在表创建时指定，可以在需要使用时动态加入。
（6）单元格（cell）：单元格由行键、列族、列限定符、时间戳、操作类型（Put、Delete等来标识数据是有效的还是处于删除状态的）唯一决定，是HBase数据的存储单元，以字节码的形式存储。

‌列族与列的关系‌：列族包含了多个列，列具有唯一的列名和列值。在HBase中，列名是由列族名和具体的列名组成的‌14。
‌列族与行的关系‌：一个行可以包含多个列族，而一个列族可以包含多个行。在HBase中，行是数据的唯一标识，每个行都有一个唯一的行键（rowkey）‌

HBase按行键的字典序存储数据行，其数据存储层级可以用如下的一个Java中的Map结构类比：
Map<RowKey,Map<Column Family,Map<Column Qualifier,Map<Timestamp,Value>>>>

以用户行为日志管理系统用来存储数据的表s_behavior为例介绍相关命令。假设该表用来存储用户手机端和计算机端的行为数据，列族pc用来存储计算机端的行为数据，列族ph用来存储手机端的行为数据，每个列族都有两列，列1（v）代表用户的商品浏览记录，列2（o）代表用户的商品下单记录，行键格式为“[用户ID][时间戳][序列号]”，表如图所示。

命令：在hbase的bin目录下输入命令：

hbase shell
list //查看所有表
创建表的语句如下：这个表有两个列族，一个pc，一个ph
create 's_behavior', {NAME => 'pc'} , {NAME => 'ph'}
该语句创建了一个s_behavior表
scan原来扫描表的数据：
scan 's_test'
put命令用来插入一行数据到HBase表。put命令的格式如下：
put <table>,<rowkey>,<列族:列限定符>,<值>
比如：
put 's_behavior','12345_1423422543001_1','pc:v','1001'
get命令用来根据行键获取HBase表的一条记录。get命令的格式如下：
get <table>,<rowkey>
delete删除某列：
delete <table>,<rowkey>,<列族:列限定符>

MongoDB

概述

类型：文档型 NoSQL 数据库

数据模型：基于 BSON（Binary JSON）的文档存储

主要用途：灵活的文档存储和快速开发

底层存储：自定义存储引擎（如 WiredTiger）

特点

灵活的 Schema：支持动态 Schema，适合快速迭代和开发。

强大的查询能力：支持丰富的查询语言，包括聚合框架。

水平扩展：通过分片实现水平扩展。

高可用性：通过复制集提供高可用性和自动故障转移。

地理空间索引：支持地理空间数据和查询。

MongoDB是一种非关系型数据库，采用文档型数据模型。它支持多种编程语言，如Java、Python、C++等。MongoDB具有丰富的数据操作功能，如数据查询、插入、更新和删除等。此外，MongoDB还支持数据分片和复制，以实现高可用性和可扩展性。

优点：

1）更高的写负载，MongoDB拥有更高的插入速度。

2）处理很大的规模的单表，当数据表太大的时候可以很容易的分割表。

3）高可用性，设置M-S不仅方便而且很快，MongoDB还可以快速、安全及自动化的实现节点 （数据中心）故障转移。

4）快速的查询，MongoDB支持二维空间索引，比如管道，因此可以快速及精确的从指定位置 获取数据。MongoDB在启动后会将数据库中的数据以文件映射的方式加载到内存中。如果内 存资源相当丰富的话，这将极大地提高数据库的查询速度。

5）非结构化数据的爆发增长，增加列在有些情况下可能锁定整个数据库，或者增加负载从而 导致性能下降，由于MongoDB的弱数据结构模式，添加1个新字段不会对旧表格有任何影响， 整个过程会非常快速。

MongoDB缺点：

1）事务能力薄弱，虽然MongoDB里事务，但是好像只能针对单条语句(查了好多但是有些看不懂)，不能像MySQL一样利用事务执行多条语句，可以根据情况来选着全部提交执行或者全部取消回滚。

2）MongoDB占用空间过大 。

3）MongoDB没有成熟的维护工具。

应用场景：

1）适用于实时的插入、更新与查询的需求，并具备应用程序实时数据存储所需的复制及高度伸缩性；

2） 非常适合文档化格式的存储及查询；

3）高伸缩性的场景：MongoDB 非常适合由数十或者数百台服务器组成的数据库。

4）对性能的关注超过对功能的要求。

使用：

MongoDB 将数据存储为一个文档，数据结构由键值(key=>value)对组成。MongoDB 文档叫做BSON类似于 JSON 对象。字段值可以包含其他文档，数组及文档数组。在MongoDB中，对于插入的格式并没有要求，字段类型可以随意变动。

比如在创建一个集合后，我们可以在这个集合加入下面的数据：

{ “name”:“this is a name”, “age”:12 }

同样我们也可以在这个数据库插入这样的数据：

{ “name”:8888, “address”:“changsha” }

插入：

假设有如下数据Student，类型如下，插入一条数据：

type Student struct {
Name string bson:"name" mapstructure:"name"
Age int bson:"age" mapstructure:"age"
Hobby []string bson:"hobby" mapstructure:"hobby"
Tes []Vege bson:"tes" mapstructure:"tes"
}
s := Student{Name: “tom”, Age: 20}
collection := client.Database(“go_db”).Collection(“test”) //连接database
insertResult, err := collection.InsertOne(context.TODO(), s) //插入数据

更新：

update := bson.D{{“$set”, bson.D{{“likenum”, 1000}, {“age”, 22}}}}
ur, err := c.UpdateMany(ctx, bson.D{{“name”, “a2test”}}, update)

前面为更新要匹配的条件，后面为修改的的值。可以只修改某一个字段，其他的没有修改的不会变，如果没有这个字段会进行新增。

Mongodb和Hbase:

Redis定位在"快"，HBase定位于"大",mongodb定位在"灵活"。mongodb有二级索引，支持相比于HBase更复杂的集合查找等。

MongoDB适合中小型的业务系统，Redis适合那些追求极致速度的场景，HBase则是为海量数据而生的。

Hive

概述

类型：数据仓库系统

数据模型：基于 SQL 的查询模型

主要用途：批处理和数据分析

底层存储：HDFS

特点

SQL 兼容：提供类似 SQL 的查询语言（HiveQL），适合数据分析。

批处理：适合大规模数据的批处理任务。

集成性：与 Hadoop 生态系统紧密集成，支持 MapReduce、Tez 和 Spark 作为执行引擎。

Schema-on-Read：数据在读取时解析，灵活性高。

典型应用场景

大数据分析和报表

数据仓库和 ETL（Extract, Transform, Load）流程

历史数据的批量处理

Hive是基于hadoop的一种数据仓库，可以将结构化的数据文件映射为数据库表，并提供简单的sql查询功能，MapReduce计算模型可将大型数据处理任务分解成很多单个的、可以在服务器集群中并行执行的任务，这些任务的计算结果可以合并在一起来计算最终的结果。而hive可以将sql语句转化为mapreduce任务执行，底层由HDFS来提供数据的存储，当在Hive中创建一个表时,实际上是在HDFS上创建了一个文件夹来存储这个表的数据。说白了hive可以理解为一个将SQL转换为MapReduce的任务的工具，甚至更进一步可以说hive就是一个MapReduce的客户端。Hive本身并不提供数据的存储功能，它可以使已经存储的数据结构化。hive将数据映射成数据库和一张张表，库和表的元数据信息可以存在metastore上(hive metastore一般是关系型数据库）。 通过 SQL 轻松访问数据的工具，从而支持提取/转换/加载 (ETL)、报告和数据分析等数据仓库任务。一种将结构强加于各种数据格式的机制访问直接存储在 Apache HDFS或其他数据存储系统（例如 Apache HBase）中的文件。

Hive所有的运行的任务都是交由YARN来统一管理，流程如下：客户端提交SQL作业到HiveServer2，HiveServer2会根据用户提交的SQL作业以及数据库中现有的元数据信息生成一份可供计算引擎执行的执行计划，每个执行计划对应若干的MapReduce作业，Hive会将所有的MapReduce作业都一一提交到YARN中，由YARN去负责创建MapReduce作业对应的子任务任务，并协调它们的运行。YARN创建的子任务会与HDFS进行交互，获取计算所需的数据，计算完成后将最终的结果写入HDFS或者本地。

StarRocks

概述

类型：分布式 MPP（Massively Parallel Processing）数据库

数据模型：列式存储，支持 SQL 查询

主要用途：实时分析和高性能查询

底层存储：自定义存储引擎

特点

高性能：优化的查询性能，适合实时分析。

实时性：支持实时数据导入和查询。

SQL 兼容：支持标准 SQL，易于使用。

列式存储：高效的列式存储和压缩，适合分析型工作负载。

扩展性：支持水平扩展，处理大规模数据。

典型应用场景

实时数据分析

高性能数据查询

数据仓库和 BI（Business Intelligence）应用

列式存储方式有以下几个优点：

1.快速的数据查询

由于数据是按照列进行存储的，所以查询某个列时只需要读取该列所在的块，而不是整行数据，从而大大提高了查询效率。

2.压缩效率高

由于列式存储的数据块中只有一个值的数据，所以可以使用更高效的压缩算法进行压缩，从而减少存储空间。

3.易于扩展

由于数据是按列存储的，所以可以很容易地添加或删除列，从而方便地扩展或缩减表的大小。

在StarRocks中，每个表都被分成多个块（block），每个块包含了一定数量的列数据。当执行查询时，StarRocks会根据查询条件定位到相应的块，并从这些块中读取所需的列数据，从而实现高效的查询。为了支持列式存储，StarRocks还提供了一些列式存储相关的功能，例如列式索引、列式聚合、列式过滤等，这些功能可以进一步提高查询效率和数据压缩效率。StarRocks中, 一张表的列可以分为维度列(也成为key列)和指标列(value列), 维度列用于分组和排序, 指标列可通过聚合函数SUM, COUNT, MIN, MAX, REPLACE, HLL_UNION, BITMAP_UNION等累加起来. 因此, StarRocks的表也可以认为是多维的key到多维指标的映射.

尽管 StarRocks 使用列式存储，但它仍然支持关系型数据库的表结构。用户可以定义表的列、数据类型、约束等，就像在 MySQL 中一样。

starrocks在使用时方便，可直接用sql语句：

创建表

CREATE TABLE my_table (
id INT,
name VARCHAR(255),
age INT,
salary DOUBLE
) ENGINE=OLAP
DISTRIBUTED BY HASH(id) BUCKETS 10
PROPERTIES (
“replication_num” = “3”
);

插入数据

INSERT INTO my_table (id, name, age, salary) VALUES (1, ‘Alice’, 30, 10000.0);

查询数据

sql复制SELECT * FROM my_table WHERE age > 25;

sr的架构：一个sr集群由FE和BE构成，可以使用MYSQL客户端访问SR集群。

分布式架构，包含 Frontend（FE）和 Backend（BE）节点。

FE 负责 SQL 解析、优化和调度，BE 负责数据存储和查询执行。

支持水平扩展，通过增加节点来提升性能和容量。

Tablet:StarRocks中表的逻辑分片，也是StarRocks中副本管理的基本单位，每个表根据分区和分桶机制被划分成多个Tablet存储在不同BE节点上。

目前StarRocks根据摄入数据和实际存储数据之间的映射关系，分为明细模型（Duplicate key）、聚合模型（Aggregate key）、更新模型（Unique key）和主键模型（Primary key）。

明细模型：

StarRocks建表默认采用明细模型，排序列使用稀疏索引，可以快速过滤数据。明细模型用于保存所有历史数据，并且用户可以考虑将过滤条件中频繁使用的维度列作为排序键，比如用户经常需要查看某一时间，可以将事件时间和事件类型作为排序键
使用：
（1）建表，在建表时指定模型和排序键
mysql> create database test;
mysql> use test;
CREATE TABLE IF NOT EXISTS detail (
event_time DATETIME NOT NULL COMMENT “datetime of event”,
event_type INT NOT NULL COMMENT “type of event”,
user_id INT COMMENT “id of user”,
device_code INT COMMENT "device of ",
channel INT COMMENT “”)
DUPLICATE KEY(event_time, event_type)
DISTRIBUTED BY HASH(user_id) BUCKETS 8

在 StarRocks 中，DISTRIBUTED BY 子句用于指定表的数据分布策略。具体来说，它定义了数据在不同的分片（buckets）之间如何分布。通过这种方式，可以实现数据的均匀分布，从而提高查询性能和系统的扩展性。
建完表后，插入测试数据
INSERT INTO detail VALUES(‘2021-11-18 12:00:00.00’,1,1001,1,1);
INSERT INTO detail VALUES(‘2021-11-17 12:00:00.00’,2,1001,1,1);
INSERT INTO detail VALUES(‘2021-11-16 12:00:00.00’,3,1001,1,1);
INSERT INTO detail VALUES(‘2021-11-15 12:00:00.00’,1,1001,1,1);
INSERT INTO detail VALUES(‘2021-11-14 12:00:00.00’,2,1001,1,1);
查询数据，5条明细数据都在。此种模型的表用来存储所有历史明细数据。

聚合模型：

在数据分析中，很多场景需要基于明细数据进行统计和汇总，这个时候就可以使用聚合模型了。比如：统计app访问流量、用户访问时长、用户访问次数、展示总量、消费统计等等场景。
适合聚合模型来分析的业务场景有以下特点：
业务方进行查询为汇总类查询，比如sum、count、max
不需要查看原始明细数据
老数据不会被频繁修改，只会追加和新增
使用：
（1）建表，指定聚合模型
CREATE TABLE IF NOT EXISTS aggregate_tbl (
site_id LARGEINT NOT NULL COMMENT “id of site”,
DATE DATE NOT NULL COMMENT “time of event”,
city_code VARCHAR(20) COMMENT “city_code of user”,
pv BIGINT SUM DEFAULT “0” COMMENT “total page views”,
mt BIGINT MAX
)
DISTRIBUTED BY HASH(site_id) BUCKETS 8;
（2）插入测试数据
INSERT INTO aggregate_tbl VALUES(1001,‘2021-11-18 12:00:00.00’,100,1,5);

（3）查询测试数据，可以看到pv是sum累计的值，mt是明细中最大的值。如果只需要查看聚合后的指标，那么使用此种模型将会大大减少存储的数据量。

更新模型：

有些分析场景之下，数据需要进行更新比如拉链表，StarRocks则采用更新模型来满足这种需求,比如电商场景中，订单的状态经常会发生变化，每天的订单更新量可突破上亿。这种业务场景下，如果只靠明细模型下通过delete+insert的方式，是无法满足频繁更新需求的，因此，用户需要使用更新模型（唯一键来判断唯一性）来满足分析需求。但是如果用户需要更加实时/频繁的更新操作，建议使用主键模型。
使用更新模型的场景特点：
已经写入的数据有大量的更新需求
需要进行实时数据分析
使用：
建表，指定更新模型
CREATE TABLE IF NOT EXISTS update_detail (
create_time DATE NOT NULL COMMENT “create time of an order”,
order_id BIGINT NOT NULL COMMENT “id of an order”,
order_state INT COMMENT “state of an order”,
total_price BIGINT COMMENT “price of an order”
)
UNIQUE KEY(create_time, order_id)
DISTRIBUTED BY HASH(order_id) BUCKETS 8
插入测试数据，注意：现在是指定create_time和order_id为唯一键，那么相同日期相同订单的数据会进行覆盖操作

主键模型：

相比较更新模型，主键模型可以更好地支持实时/频繁更新的功能。虽然更新模型也可以实现实时对数据的更新，但是更新模型采用Merge on Read读时合并策略会大大限制查询功能，在主键模型更好地解决了行级的更新操作。配合Flink-connector-starrocks可以完成Mysql CDC实时同步的方案。
需要注意的是：由于存储引擎会为主键建立索引，导入数据时会把索引加载到内存中，所以主键模型对内存的要求更高，所以不适合主键模型的场景还是比较多的。
目前比较适合使用主键模型的场景有这两种：
数据冷热特征，比如最近几天的数据才需要修改，老的冷数据很少需要修改，比如订单数据，老的订单完成后就不在更新，并且分区是按天进行分区的，那么在导入数据时历史分区的数据的主键就不会被加载，也就不会占用内存了，内存中仅会加载近几天的索引。
大宽表（数百列数千列），主键只占整个数据的很小一部分，内存开销比较低。比如用户状态/画像表，虽然列非常多，但总的用户数量不大（千万-亿级别），主键索引内存占用相对可控。

主键模型通过主键约束，保证同一个主键仅存一条数据的记录，这样就规避了Merge操作。
StarRocks收到对某记录的更新操作时，会通过主键索引找到该条数据的位置，并对其标记为删除，再插入一条数据，相当于把update改写为delete+insert

CREATE TABLE users (
user_id BIGINT NOT NULL,
NAME STRING NOT NULL,
email STRING NULL,
address STRING NULL,
age TINYINT NULL,
sex TINYINT NULL
) PRIMARY KEY (user_id)
DISTRIBUTED BY HASH(user_id) BUCKETS 4
插入测试数据，和更新模型类似，当user_id相同发送冲突时会进行覆盖

sr中的bitMap索引：

StarRocks支持基于BitMap索引，对于Filter的查询有明显的加速效果。
原理：
Bitmap是元素为bit的， 取值为0、1两种情形的, 可对某一位bit进行置位(set)和清零(clear)操作的数组。Bitmap的使用场景有：
用一个long型表示32位学生的性别，0表示女生，1表示男生。
用Bitmap表示一组数据中是否存在null值，0表示元素不为null，1表示为null。
一组数据的取值为(Q1, Q2, Q3, Q4)，表示季度，用Bitmap表示这组数据中取值为Q4的元素，1表示取值为Q4的元素, 0表示其他取值的元素。

CREATE TABLE IF NOT EXISTS user_dup (
user_id INT,
sex INT ,
age INT
)DUPLICATE KEY(user_id)DISTRIBUTED BY HASH(user_id) BUCKETS 8

CREATE INDEX user_sex_index ON user_dup(sex) USING bitmap;

Bitmap索引, 应该在取值为枚举型, 取值大量重复, 较低基数, 并且用作等值条件查询或者可转化为等值条件查询的列上创建.
且不支持对Float、Double、Decimal 类型的列建Bitmap 索引。

Bloom Filter 索引

什么是Bloom Filter:
Bloom Filter（布隆过滤器）是用于判断某个元素是否在一个集合中的数据结构，优点是空间效率和时间效率都比较高，缺点是有一定的误判率。

StarRocks的建表时, 可通过PROPERTIES{“bloom_filter_columns”=“c1,c2,c3”}指定需要建BloomFilter索引的列，查询时, BloomFilter可快速判断某个列中是否存在某个值。如果Bloom Filter判定该列中不存在指定的值，就不需要读取数据文件；如果是全1情形，此时需要读取数据块确认目标值是否存在。另外，Bloom Filter索引无法确定具体是哪一行数据具有该指定的值。默认3次hash。

注意事项：
（1）不支持对Tinyint、Float、Double 类型的列建Bloom Filter索引。
（2）Bloom Filter索引只对in和=过滤查询有加速效果。
（3）如果要查看某个查询是否命中了Bloom Filter索引，可以通过查询的Profile信息查看