Elasticsearch logsdb 索引模式和 TSDS 的业务影响

作者：来自 Elastc Tim Brophy

Elasticsearch 存储引擎团队在 Elasticsearch 8.19 和 9.1 中在存储效率和性能方面取得了重大进展。现在这些变化已经可用，它们会对你的业务产生什么影响？以及你该如何最大化利用它们？

更多阅读 “Observability：Elasticsearch 新的索引 mode: Logsdb 初体验” 及 “如何将 Elasticsearch 和时间序列数据流用于可观察性指标 - 8.7”

我们改进了什么？

这篇博客不会重复伴随 Elasticsearch 8.19 和 9.1 发布的技术博客中的内容，那篇文章已经专业地解释了为实现存储利用率和吞吐量巨大提升而实施的技术细节。话虽如此，仍然值得总结一下这些成果，以便为本文的其余部分提供背景。

这些变化和改进具体体现在我们称为时间序列数据流 (TSDS) 和 Elasticsearch logsdb 索引模式的功能中。它们都是对全球 DevOps、站点可靠性工程 (SRE) 和安全团队在其系统生成的数据呈指数级增长时所遇挑战的直接回应。

基准测试中，将 Elasticsearch 8.17（logsdb 索引模式首次引入时）与我们最新版本进行比较，显示存储效率提升了约 16%，索引吞吐量增加了约 19%。然而，这只是部分结果，因为它比较的是已启用 logsdb 索引模式的集群。对于仍在未启用 logsdb 索引模式情况下索引数据的客户来说，相同数据的存储占用可减少 70% 以上。

重要提示：Logsdb 索引模式在 Basic 和 Enterprise 许可证层级中都可用，但这里引用的数据与 Enterprise 相关。Enterprise 包含 synthetic_source —— 这一功能无需在磁盘上存储原始 json 文档，而是在需要时即时编译生成。更多有关订阅的内容，请参考 https://elastic.co/cn/subscriptions

压缩算法本身在执行编码以大幅减少数据占用时需要额外的 CPU 开销。然而，由于底层数据结构进行了重大变更，相比 Elasticsearch 8.17，目前在数据摄取过程中所需的额外处理能力仅约为 5%。

这对我们的客户意味着什么？

纯技术基准的提升是对我们工程团队工作的极好验证，但这些改进如何转化为客户的业务价值呢？这些增强是否仅仅意味着存储成本更低、查询响应更快？还是说在存储性能和效率提升的基础上，还能带来业务收益？现实情况是，它们将在多个方面影响成本并提升性能指标，例如服务可用性、事件修复以及合规性。

成本影响

对于刚开始构建 Elasticsearch 的人来说，为机器生成数据设计集群规模的一种方式是主要关注两个指标：每天摄取的数据量以及这些数据的保留天数。

在为你的用例设计集群时可以应用一些架构上的细节，但总体来说，集群设计的要素相同：

• 集群中的热节点必须有足够的规模来容纳摄取的数据量，以及所有需要即时可用的数据搜索，而不受节点可用性的影响。通常，这发生在数据生命周期的前几小时到几天，此后它对解决系统即时故障不再至关重要。
• 冷节点和冻结节点存储随着时间推移失去短期用途但因其他业务原因（如报表或审计）需要长期保留的数据。这些节点对处理能力的要求较低，通常按容量需求进行规划。

简而言之，通过启用 logsdb 索引模式和 TSDS 减少所有数据层的存储占用，可显著减少所需磁盘空间，从而降低成本，同时只带来极小的 CPU 开销。

更多数据，更高可见性，更低 MTTR

应用、操作系统和基础设施产生的数据量稳步增长。这一增长由业务需求驱动，因为公司需要优化运营基础设施、保持竞争力并采用新技术。IT 领域的团队必须决定需要从哪些系统摄取数据，以满足可用性指标。

许多团队不断在需求与数据存储成本之间做权衡。例如，他们必须决定是仅获取生产环境的数据，还是包括非生产环境的日志和指标；根据预过滤选择哪些日志消息重要；以及是否在存储前对指标应用聚合。

这些权衡的问题在于，它们通常基于对数据是否重要的假设来执行，而这些假设是基于过去已知事件建模的，无法充分预测或满足未来的事件或需求。

通过将现有数据的存储占用减半，可以将两倍的新数据引入 Search AI 平台，从而让团队摆脱修剪可能包含关键标识符的宝贵数据的需要。反过来，SRE、DevOps 工程师和开发人员可以基于实际的运营经验做出是否保留数据的明智决策，并将监控覆盖率扩展到 100%，确保整个环境都可观测。

一旦数据被证明不再必要，就可以转移到更便宜的层，聚合以降低精度，或彻底丢弃。数据所有者和消费者可以基于经过验证的输入共同制定这些生命周期策略，而不是基于假设，并且不会因存储成本升级而付出代价。这确保了公司能降低平均修复时间 (MTTR)，避免因削减成本措施而引入盲点。

消除数据孤岛

当数据点拥有更多上下文时，它的价值会提升。上下文为数据提供了联系，从而更清晰地展现出发生了什么、为什么发生以及接下来可能会发生什么。例如，服务 A 可能报告缺少入站事务，而服务 B 可能报告它无法访问任何其他服务。单独来看，这些消息仅仅代表了一个服务的状态。但结合起来，它们展示了因果关系。

这个简单的例子可以被成千上万次扩展，以展示现代系统的复杂性。当数据被选择性摄取和存储，或者存在于不同的监控平台时，它本身就没有在单一、上下文丰富的视角中产生那么多价值。通过降低整体数据存储成本，Elastic 让团队可以在单一平台上访问监控和日志数据，从而减少解决事件所需的时间。用户还可以在统一的仪表板上查看他们的数据，并由机器学习 (ML) 模型进行分析，从而识别并关联整个 IT 环境中的异常。有了 Elastic，统一平台带来的速度、效率和洞察不必以牺牲成本效益为代价。

合规与报告的适当保留

面对不断增加的数据保留成本，数据所有者需要决定在何时将数据归档并从昂贵的监控和日志工具中移除。一旦归档（通常是离线），检索过程可能是手动且耗时的。尽管可能不频繁，但当团队需要分配工程师去恢复对审计或合规事件至关重要的归档数据时，这仍然是一个耗时的活动。这类事件几乎不会没有优先级和重要性，而这只会增加定位和恢复归档数据的压力。

除此之外，如果归档是基于成本因素而不是业务需求来实施的，组织将不再具备关键的报告能力，无法比较历史数据和当前数据。Elasticsearch 通过 logsdb 索引模式、TSDS 和高效的数据分层正面应对这些挑战，使企业能够将数据优雅地归档到低成本存储层，而无需将其离线，从而可通过与当前运营数据相同的访问机制来获取。分析师的体验是无缝透明的，不需要额外的时间和精力从离线备份中恢复数据存储 —— 这一过程可能需要数小时才能完成。结果是，组织能够更清晰地看到长期趋势，从而为未来做出更好的决策。

AI 采纳的平台

生成式 AI 技术虽强大，但需要应用于合适的场景并获得正确的数据访问。这有助于交付超越一般生产力提升的价值。AI 助手和工具之所以有价值，很大程度上在于将其强大的能力与实时数据结合起来。再次强调，赋能 AI 提供真正成果时，上下文至关重要。

在 Elasticsearch 的案例中，Elastic AI Assistant 能够提升客户工程师的能力。它不仅依赖自身的训练数据，还依赖于每个客户独有的日志、指标和自定义知识库，从而为他们提供指导。它可以在安全且合规的情况下实现这一点 —— 遵循 Elasticsearch 中定义的访问控制，并在 Elastic 精心设计的严格工作流中运行，以可靠地驱动故障排查洞察和修复过程。

数据集越广泛，对系统全景的呈现就越完整，因此 AI Assistant 生成的答案就越有效。将更多数据投入 Search AI 平台的结果，就是为工程团队带来更高水平的真实价值。

立即试用

通过改进我们在 Elasticsearch 中存储和访问数据的方式，我们已经超越了单纯的成本节约。我们帮助客户打破了构建清晰全面的组织视图的障碍，从而能更好地利用他们的数据。

凭借这些洞察，许多客户在 MTTR 上取得了改进，工具成本有所降低，并正在使用 Elastic 来规划他们的 AI 采纳之旅。立即注册 Elastic Cloud 的免费试用，你的团队就能亲身体验这些功能以及所有其他让 Elastic 多次被评为 Gartner 可观测性平台魔力象限领导者的强大能力。

本文中描述的任何功能的发布时间和交付仍由 Elastic 全权决定。目前尚不可用的功能可能不会按时交付，甚至可能完全不会交付。

在这篇博客中，我们可能使用或提及了第三方生成式 AI 工具，这些工具由其各自所有者拥有和运营。Elastic 无法控制这些第三方工具，对于其内容、运行或使用，以及因你使用这些工具可能产生的任何损失或损害，我们不承担任何责任或义务。在使用 AI 工具处理个人、敏感或机密信息时，请务必谨慎。你提交的任何数据可能会被用于 AI 训练或其他用途，我们无法保证你提供的信息会得到安全或保密的保护。你在使用任何生成式 AI 工具之前，应熟悉其隐私政策和使用条款。

Elastic、Elasticsearch 及相关标志是 Elasticsearch N.V. 在美国及其他国家的商标、徽标或注册商标。所有其他公司和产品名称均为其各自所有者的商标、徽标或注册商标。

原文：The business impact of Elasticsearch logsdb index mode and TSDS | Elastic Blog