关于ElasticSearch在实际项目中遇到的问题分享

近来，公司业务拓展，要处理一些超大规模的数据。业务单日数据规模巨大，一天需要采集几百亿甚至上千亿条目的数据，当然总数据规模更大，数据种类繁多，每种数据维度也很多，但数据是有保留期限的。因数据量级较大，起初我们选择了开源的ES进行数据处理和检索。ES是一个高扩展的全文检索和分析引擎，它可以准实时地快速存储、检索和分析海量的数据。

ES基本是目前大数据平台中全文检索业务的中流砥柱，ES是面向文档型数据库，每一条数据在ES里就是一个文档，用JSON格式作为文档序列号的格式。ES的底层基于lucene,由lucene来为ES提供强大的索引检索能力。

但是ES随着数据量级的不断增加，达到千亿级别时，就逐渐暴漏了不足，下面一一罗列以供准备使用ES的小伙伴参考。

（1）由于业务中涉及到ES，所以数据都是存储到本地的，但开发过程中出现了磁盘损坏的现象，磁盘损坏后ES查询分片就不能查询了，需要手动恢复；

（2）因前期考虑不当，选择ES版本时没有经过全面的调研，导致后期出现了版本升级后索引不兼容的问题。并且有时因版本升级失败，索引损坏，导致没有办法回退的问题。

（3）因业务考虑经常需要对接常规关系型数据库和hive等组件，但因为ES本身并没有实现和这些系统的兼容，导致对接较为困难。后通过ELK来与其余系统对接，但支持性很差，且不支持在ES内部同时检索多数据源数据。这也是困扰大家很长时间的一个问题。

因ES实在无法满足业务需求，我们又调研了一款国产数据库LSQL，基于分布式架构的高性能数据库。LSQL使用了索引+大数据技术，可以对万亿级别的数据做到秒级数据检索及统计分析服务，LSQL数据库还可以轻松对接如Hive、Oracle等外部数据源。非常适合我们的项目需要。

LSQL数据库同样基于lucene进行索引开发，集成了Spark内存计算框架，除简单SQL语句外还可通过Spark sql进行复杂计算，完全兼容Hive sql语法。在使用过程中深刻体会到了其功能的强大。下面借用一张官网的功能图：

在使用过程中发现LSQL数据库还有一个特殊的功能——按列均匀返回。因为我们业务中不同种类的数据经常会出现严重的倾斜现象，例如某个协议的数据占整体95%以上。因为100个表，即代表了100种不同的协议，但是有的协议数据多，有的协议数据少，我们希望在首屏能够展示数据的多样性，也就是首屏通过一次查询能够让每个协议均返回一些数据，首屏能够看到每个协议的数据，而不是哪个协议多，就只能看到哪个协议的数据。而LSQL的按列均匀返回功能很好的解决了这一问题，录信数据库不管数据倾斜的程度，总能够让每个种类的数据都有所返回，均匀的呈现给用户，即使这个种类的数据很少，也是能够看到的。不会让用户看到的都是一个种类的数据。这对我们业务的解决起了很好的帮助作用。

有同样使用录信数据库的小伙伴欢迎来一起讨论讨论。