SelectDB 介绍：
SelectDB 是基于 Apache Doris 构建的现代化数据仓库，支持大规模实时数据上的极速查询分析，主要用于 OLAP 场景下对大规模数据进行快速分析和查询，它支持多维分析、实时查询、增量更新、高效的数据更新等功能。
SelectDB 目前有两个商业化产品：SelectDB Cloud 和 SelectDB Enterprise，能够差异化地满足来自云上和私有化部署用户的不同需求。
SelectDB 主要有四个应用场景：实时报表、湖仓一体、日志存储与分析、用户画像与行为分析
Elasticsearch 介绍：
Elasticsearch （简称ES）是一个分布式的、基于 RESTful API 的搜索和分析引擎，广泛用于大规模的数据存储和快速检索。它最初由 Shay Banon 于 2010 年开发，是开源的，并且是 Elastic Stack（通常称为 ELK Stack）的核心组成部分，另外组成部分是 Logstash、Beats（用于数据收集和处理）和 Kibana（用于数据可视化）。
案例分享：
从 Elasticsearch 到 SelectDB，观测云实现日志存储与分析的 10 倍性价比提升
在云计算逐渐成熟的当下，越来越多的企业开始将业务迁移到云端，传统的监控和故障排查方法已经无法满足企业的需求。观测云可以实现对云、云原生、应用及业务的统一监测，提供整体数据的分析、洞察、可视化、自动化、监测告警、智能巡查、安全巡查等服务。本文将分享 SelectDB 如何助力观测云完成日志数据存储和分析架构升级，实现在存储成本降低 70% 的同时、查询性能提升 2-4 倍，最终实现整体性价比 10 倍提升，为日志存储和分析场景服务提供强大动力。
面临的挑战和痛点：
观测云基于 VictoriaMetrics 存储模块研发了时序存储引擎 Metric Store，同时在泛日志场景集成了Elasticsearch/OpenSearch。这样的设计使 GuanceDB（GuanceDB 是一个观测云自主研发的由多种数据库技术组成的多模态数据库）对外有统一的写入和查询接口，能适应不同类型的数据格式和业务需求。在当前的实现中，MetricStore 已经具备卓越的性能。然而，对于日志类和用户行为类数据的处理来说，Elasticsearch 却有诸多不足，具体表现如下：
1、写入占用资源多：Elasticsearch 在处理高频写入大量的数据时，会占用较高的 CPU 和内存资源，这不仅会显著增加集群成本，还会挤占查询所占用的资源。
2、对无模式表支持差：Elasticsearch 对于 Schemaless 支持有限，当前的 Dynamic Mapping 在面对大量的用户自定义字段时，会频繁造成字段类型冲突，导致数据丢失，需要人工介入进行手动处理。
3、聚合查询性能差：Elasticsearch 在面对海量数据时，聚合性能表现较差。例如对亿级数据计算分位数、错误率时，极易出现超时，很难满足大规模数据下的业务分析需求。
解决方案：基于 SelectDB 的存储架构升级
在可观测性场景中，几乎所有的查询都涉及时间的筛选，同时大部分的聚合也需要按照时间窗口来进行，并且针对时间序列，还需要支持按单个序列在时间窗口前后进行 Rollup。在这些场景中，使用 SQL 来表达相同的语义就需要嵌套多层子查询，导致表达过程和编写都异常复杂。
因此开始尝试简化语法元素，在此基础上设计出了新的查询语言 DQL，并且增强了在可观测场景下的常见计算函数，通过 DQL 即可查询指标、日志、链路追踪、对象等所有的可观测数据。
从 GuanceDB 内部结构来看，本次升级使用 SelectDB 替换了 Elasticsearch/OpenSearch，原有的查询架构保持不变。
在引入 SelectDB 之后，DQL 查询的工作模式如下图：
如上图所示，Guance-Insert 是数据写入组件，Guance-Select 是 DQL 查询引擎。
在 Guance-Insert 中，实现了分租户的数据攒批逻辑，均衡了写入吞吐量和写入延迟两大指标，尽量高效地将数据通过 Stream Load 接口写给 SelectDB Doris BE 组件。当海量日志产生时，该方式攒批速度很快，平均日志入库延迟在 2-3 秒。
在 Guance-Select 中， Guance-Select 会根据当前查询 SelectDB 的 SQL 支持情况，选择是否将查询下推给 FE 计算。通常情况下，常见的聚合查询都可以下推给 FE 计算，但当遇到 FE 不支持的 SQL 语义或函数时，我们就会选择 Fallback 到仅下推谓词到 BE，通过 Thrift RPC 接口获取 Arrow 格式的列存数据，再在 Guance-Select 中计算。由于此方案无法将计算逻辑下推 BE ，因此实际性能会略差于在 FE 中的查询。不过在大部分场景下，这种方案是可以满足需求的。
当前的查询架构是综合 FE 和 BE 能力的混合计算架构，DQL 即可以利用 SelectDB 已经充分优化的查询能力，也可以让语法拓展不受 SelectDB 本身 SQL 能力的限制。
收益：
1、存储成本降低约 70%、查询性能提升 3 倍
SelectDB 的引入，实现了综合成本的大幅降低。之前我们在云上某可用区使用的是由 20 台 16C 64G 云主机组成的 Elasticsearch 集群提供查询服务，同时采用了独立的索引写入服务（相当于使用 20 台云主机）。在替换成 SelectDB 之后，只需要 13 台同配置的云主机，总成本下降了 67%。
2、倒排索引满足日志场景全文检索需求
倒排索引能够显著提升全文检索的性能并降低查询的资源开销，是实现高效日志分析的必备能力。SelectDB 支持倒排索引，以下是我们从 Elasticsearch 迁移到 SelectDB 过程中关键能力的介绍：
支持字符串全文检索，包括可同时匹配多个关键字 MATCH_ALL、匹配任意一个关键字 MATCH_ANY 、匹配短语词组 MATCH_PHRASE 的查询方式。我们对日志文本内容创建倒排索引时使用 MATCH_PHRASE 进行查询，能够完整覆盖原来在 Elasticsearch 上的功能。
支持英文、中文及 Unicode 多语言分词，中文分词还支持自定义词库、自定义停用词。我们将原先在 Elasticsearch 上使用的中文词库和停用词配置到 SelectDB 上，完成了用户体验平滑迁移。
除了在功能上能够满足日志全文检索的需求，SelectDB 倒排索引还支持在线按需增减索引。Elasticsearch 索引在创建时是固定的，后续无法新增索引字段，这就需要提前规划哪些字段需要建立索引，后续如需变更索引则需要重写，变更成本非常高。
3、Variant 数据类型，解决数据 Schema 频繁变化痛点
在常见的数据库中，大部分数据表的 Schema 是静态的，也有一些数据库如 Elasticsearch 可以通过 Mapping 实现动态 Schema。然而，动态 Schema 可能会遇到字段类型冲突或因历史字段不失效而导致字段数量达到上限的问题。在引入 SelectDB 之后，我们使用最新特性 Variant 动态数据类型（该特性将在 Apache Doris 2.1 版本中正式发布）可以很好地支持这类场景。
本案例中SelectDB 对比 Elasticsearch 的具体优势体现
1、SelectDB 写入性能高于 Elasticsearch；
2、SelectDB 数据和索引压缩率高于 Elasticsearch；
3、SelectDB 支持冷热数据分层存储；
4、SelectDB 倒排索引支持在线按需增减索引；
5、SelectDB 的 Variant 数据类型能够解决字段类型冲突或因历史字段不失效而导致字段数量达到上限的问题；
