2023年7月7日，华为开发者大会 2023（Cloud）在中国东莞溪村正式揭开帷幕。7月8日，openGemini架构师徐然在开源专题论坛上发布了openGemini 2大新特性：日志检索 和 高基数存储引擎。
日志检索
随着应用数量和IT系统规模日益增大，产生海量日志数据，这意味着更高的存储成本，以及对存储系统更高的数据写入和查询性能、更高的可扩展性和稳定性等要求，现有的日志存储系统多为轻量级，主流多采用Elasticsearch，但存在license授权、存储成本、性能和稳定性等系列问题，一种企业级高性能、低成本的海量日志存储和分析系统显得尤为必要。
徐然表示，“日志是一种重要的时序数据，使用时序数据库存储更为合适，但任何单纯的日志数据存储对于业务而言是无意义的。日志数据不同于其他时序数据，它意味着全文索引，要解决当前以及未来一段时间海量日志数据存储和分析带来的技术挑战，需要在索引创建和索引检索两方面寻求新的技术突破。openGemini社区设计研发了新的分词器和索引数据结构，具备更高的读写性能和更少的内存资源消耗。此外，openGemini采用列式存储和专用数据压缩算法，使得存储成本大幅降低。“
HSCE高基数存储引擎
为了更好理解什么是高基数问题，首先需要解释什么是基数(Cardinality)，它表示数据集中不同值的数量，比如一张表中有一个字段使用Bool类型表示服务状态，数据集的值只有两种：true和false，因此基数为2。但是如果是像车牌号这样的数据集，动辄百万甚至千万，基数就非常大了。
一般来说，为了更方便检索时序数据，通常会给时序数据关联一些标签（元数据），再根据标签值来查询和过滤数据。时序数据库中，一个系统的基数就是每个标签基数的叉乘，也称为时间线总数。
在时序数据库中，为了更快检索到数据，会为每条时间线创建索引，基数越大，意味着时间线越多，这就使得索引膨胀厉害，索引扫描时延大幅增加，从而影响时序数据库的读写性能，这就是高基数问题。
徐然表示，“高基数的问题的本质是索引性能和内存资源消耗问题，传统倒排索引在高基数场景近似稠密索引，索引开销较大，同时对于数据过滤几乎没有效果。解决它需要放弃现有的时间线倒排索引，寻求更低的内存资源消耗，更高效的索引检索技术方案才能从根本上解决问题，这并非易事。openGemini从AP系统中获得索引设计思路，结合时序数据和业务特点，开发了高基数存储引擎，使用更合适的数据聚簇、排序方式，并通过构建基数无关的稀疏索引，提升数据过滤效果与查询性能“
从实际应用场景测试数据可以看到，InfluxDB在写入时出现OOM，相比ClickHouse，新的存储引擎写性能提升3x，并发查询性能提升10x以上。
总结
本次特性发布会，openGemini提供企业级高性能、低成本的日志存储和分析解决方案。与此同时，openGemini还推出了全新存储引擎HSCE，重点解决时序高基数问题。这让openGemini可以在更多更广的时序业务场景中使用。
不管是日志检索还是高基数引擎，其背后依然面临非常大的技术挑战和工作量，我们必将竭尽所能，持续优化和完善，比如日志检索，社区目前支持了3种最为常用的查询方式：精确匹配、短语匹配和模糊匹配，如果反馈有新的需求，我们也会持续增加新功能。再比如高基数存储引擎，绝大部分聚合函数还不支持，社区计划在9-10月完成补齐，请大家耐心等待！
欢迎大家试用和反馈，我们投入的力量有限，要做好openGemini，还需要更多的企业和开发者共同参与社区，让开源惠及更多企业和开发者，营造良好的开源社区文化，也欢迎伙伴加入社区，共建、共治、共享未来！
PS：社区征稿，内容包括但不限于源码解析、内核技术分享、社区贡献、解决方案、业务场景、性能对比测试等，有神秘礼品等着您！联系人wx：xiangyu5632
技术文档参考：
-
https://docs.opengemini.org/zh/guide/geminiql/sql_syntax/DDL/create_measurement.html
-
https://docs.opengemini.org/zh/guide/geminiql/sql_syntax/DML/text_retrieval.html
openGemini官网：http://www.openGemini.org
openGemini开源地址：https://github.com/openGemini
openGemini公众号：
欢迎关注～ 诚邀你加入 openGemini 社区，共建、共治、共享未来！