es做mysql二级索引_用Elasticsearch实现HBase二级索引

写在前面

项目的日志模块中的日志数据都存储在 HBase 中，由于 HBase 只有 rowkey 这个一级索引的特性，为了方便对日志数据的个别字段进行查询，就需要额外创建二级索引

之前参考了网络上非常多的二级索引实现方案，各种方案的思路都是大同小异，无非就是把查询字段和 rowkey 做一个关联，存储在 HBase / ES / MySQL 等等地方，最终决定尝试采取用 Elasticsearch 存储二级索引

设计细节

1. 文档 id 的设计

将 rowkey 作为 ES 文档的 id

这么做有以下几点考虑：

id 需要全局唯一性，而 HBase 中数据的 rowkey 已经保证了这一点

rowkey 不需要被搜索

查询时，只返回文档 id 即可，不需要返回文档的内容(即做了二级索引的那些列的值)，这样能提高查询效率

rowkey 如果作为文档的一个列进行存储，会带来一些不必要的磁盘空间占用，假设一个 rowkey 有 20 字节大小，存 1 亿条数据至少会有 1.8 TB 的空间占用

当然，有利也有弊，目前考虑到的弊端包括：

使用非 ES 自己生成的 id，会带来一定的效率损失，每条数据存储时，ES 都要对 id 进行一次判断

…

2. 文档字段的设计

HBase 存储的数据中，需要做索引的列(即需要用来查询的列)

3. 字段属性的设计

索引

存储的字段都创建索引，毕竟不创建索引就不能查询

分词

根据实际情况，字段是否需要设置分词

_source / store

上面有说到，查询时仅需要返回文档的 id，不需要文档的内容，所以存储的字段可以禁用存储，大幅度节省磁盘空间

doc_values

如果存储的字段不需要进行排序、聚合、脚本运算，可以禁用 doc_values，也可以节省磁盘空间

norms

如果字段不需要分词，直接指定字段为 keyword，即默认不开启 norms

一个疑问

本来是先设计了日志数据存储到 HBase，然后才开始考虑二级索引的实现方案，按上面说的这么弄了之后，突然一时有点懵：我为什么不直接把数据存 ES 里？

又多学习了一些 ES 和 HBase 二级索引相关的文章后，在《分布式搜索的面试题3》中看到了这样的描述：

比如说你现在有一行数据

id name age ….30 个字段

但是你现在搜索，只需要根据 id name age 三个字段来搜索

如果你傻乎乎的往 es 里写入一行数据所有的字段，就会导致说 70% 的数据是不用来搜索的，结果硬是占据了 es 机器上的 filesystem cache 的空间，单挑数据的数据量越大，就会导致 filesystem cahce 能缓存的数据就越少

仅仅只是写入 es 中要用来检索的少数几个字段就可以了，比如说，就写入 es id name age 三个字段就可以了，然后你可以把其他的字段数据存在 mysql 里面，我们一般是建议用 es + hbase 的这么一个架构。

hbase 的特点是适用于海量数据的在线存储，就是对 hbase 可以写入海量数据，不要做复杂的搜索，就是做很简单的一些根据 id 或者范围进行查询的这么一个操作就可以了

从 es 中根据 name 和 age 去搜索，拿到的结果可能就 20 个 doc id，然后根据 doc id 到 hbase 里去查询每个 doc id 对应的完整的数据，给查出来，再返回给前端。

你最好是写入 es 的数据小于等于，或者是略微大于 es 的 filesystem cache 的内存容量

然后你从 es 检索可能就花费 20ms，然后再根据 es 返回的 id 去 hbase 里查询，查 20 条数据，可能也就耗费个 30ms，可能你原来那么玩儿，1T 数据都放 es，会每次查询都是 5 ~ 10 秒，现在可能性能就会很高，每次查询就是 50ms。

四个字总结的话，我觉得就是“各司其职”，HBase 就用来存储，ES 就用来做索引，况且目前的实际情况跟文章中说的也很像，要查询的字段就几个，而其他的字段又很大又没用，没必要都丢到 ES 中，浪费查询效率