引言： HoraeDB 是一款高性能、分布式、云原生的时间序列数据库，于 2023 年底以 Apache 孵化项目形式开源。其核心源自蚂蚁集团开源的 CeresDB，经过团队 5 年深耕时序数据领域的打磨。HoraeDB 针对传统时序数据库存在的技术难题（如高基数标签组合的性能瓶颈、分布式方案不完备等）提出了解决方案，定位为新一代云原生时序数据库，既支持经典的时序工作负载也能胜任分析型负载。下文将从架构设计、技术细节、性能表现以及未来规划等方面，对 HoraeDB 在 2025 年的发展进行深入分析。
架构设计
存储引擎与分布式架构
HoraeDB 采用存储计算分离的分布式架构，以提升弹性和可用性。架构中引入独立的元数据管理和分布式存储方案，使得计算节点自身无状态或仅保留极少数据，从而方便横向扩展和负载均衡。其核心存储引擎以列式存储为基础，结合行式存储形成"混合存储"模式，针对不同数据类型和访问模式优化读写性能。这意味着 HoraeDB 将时间序列数据按照列存格式组织，以获得高压缩比和向量化计算加速，同时仍能兼顾实时写入场景下的行存储效率。
HoraeDB 内部分层设计清晰，各组件职责明确。其分布式集群主要由以下组件构成：
（图片参考文章：https://mp.weixin.qq.com/s/zkYmeP48RsqGb9_xIzSb_Q）
- HoraeMeta 集群： 集群元数据中心，负责全局元数据管理与调度协调；保证各节点对数据分片、拓扑等信息的一致视图。
- HoraeDB 实例节点： 无状态的计算/存储实例，承担具体的数据写入、查询和组织工作，可按需增加节点实现线性扩展。节点上维护内存中的 MemTable（内存表）用于暂存实时数据，以及查询所需的缓存。
- WAL 服务（Write-Ahead Log）： 独立的预写日志组件，用于接收并持久化实时写入的数据日志。在分布式部署中，WAL 服务确保数据在写入后即刻多副本持久保存，即使某个计算节点故障也不会丢失数据。WAL 可以基于本地 RocksDB 或分布式消息系统实现。
- 对象存储： 外部的持久化存储（如 HDFS、S3 或分布式文件系统），用于保存从内存表刷新的 SSTables（排序字符串表）文件。借助对象存储实现分级存储，将冷数据长期保存，减少本地存储压力。
上述架构设计带来了诸多优势：计算与存储解耦后，各层组件可独立扩缩容，实现弹性伸缩和高可用。例如，HoraeDB 可以根据负载动态增加计算节点处理查询，或扩展存储容量而不影响前端服务。同时，元数据集中管理简化了集群一致性维护，WAL 提高了数据可靠性，对象存储降低了长期存储成本。这种现代分布式架构使 HoraeDB 可以支持从单机到大规模集群的各种部署场景。
查询优化策略
HoraeDB 在查询层面采用多种优化策略，以确保海量数据检索的低延迟和高吞吐。首先，它支持SQL 和类 SQL 查询，包括对 PromQL、InfluxQL 等时序查询语言的兼容，用户可使用丰富的过滤、聚合和函数操作。为了提高查询性能，HoraeDB 引入分区扫描与剪枝技术，将大表按时间或其它维度分区存储，查询时根据时间范围或条件快速剪枝无关分区，仅扫描必要的数据块。在列式存储基础上，系统利用列的 min/max 索引和 Parquet Page Filter 等手段对数据页进行过滤，加速聚合计算。同时，查询引擎实现了谓词下推和向量化执行，在存储层预先应用过滤条件，并利用列式计算框架批量处理数据，以减少CPU开销。
HoraeDB 还特别针对慢查询隔离和并发查询进行了设计。在实际场景中，一些涉及长时间范围或大量数据点的查询（慢查询）可能耗时较长。为避免慢查询影响其它快速查询，HoraeDB 会对查询请求的潜在计算量进行预估，将请求分类为"慢查询"或"快查询"，分别投入不同的任务队列并行处理。这种隔离机制确保了绝大多数查询（如最近几小时的小范围查询）能够快速返回结果，而少数重载查询在独立队列中执行，不会阻塞系统整体的查询服务。此外，HoraeDB 提供读写分离部署模式，可将分析查询交由只读节点处理，进一步避免对核心写入节点的干扰。综合这些优化策略，HoraeDB 在高并发查询场景下依然能够保持稳定的查询性能和服务质量。
索引机制
索引设计是时序数据库性能的关键，尤其在多标签（Tag/Label）组合查询和高基数场景下。传统时序库通常对 Tag 列构建倒排索引，以加速基于标签过滤的查询。然而，HoraeDB 的设计者注意到，不同场景下标签基数差异极大：某些监控场景可能存在数百万条独立时间线（Tag组合），维护如此庞大的倒排索引会带来巨大内存开销和写入开销。为此，HoraeDB 引入灵活可插拔的索引机制，根据数据特点选择索引策略，实现性能与成本的平衡。
在低基数或标签较少的场景，HoraeDB 可以采用内存中的倒排索引来支持多维标签过滤查询------此时索引规模可控，全部驻留内存可以实现快速精确匹配。而针对高基数场景（时间线爆炸式增长），HoraeDB 核心策略是摒弃固定的"时间线"概念，降低对倒排索引的强依赖。也就是说，不再为每一种标签组合预先建立完整索引，而是更多地依赖前述的扫描+剪枝策略，通过列式扫描来处理广泛的标签组合查询。同时，针对不同的 Tag 字段类型和查询模式，HoraeDB 可以灵活选择索引方案：例如对某些高选择性的标签列构建二级索引或哈希索引，加速精确匹配；对范围查询频繁的时间字段利用排序分区加速；对其他标签则直接扫描。这种混合索引策略使系统在应对高基数标签时更具弹性------既能利用索引提高点查或小范围查询性能，又不会因索引过多导致内存和维护开销过大。实际效果上，HoraeDB 在标签非常多的场景下，相比传统依赖倒排索引的方案具有更稳定的性能表现，也为未来扩展新的索引类型（如基于Bitmap、Trie或机器学习的索引）奠定了基础。
水平扩展与高可用策略
作为分布式系统，HoraeDB 在水平扩展和高可用性方面采用了成熟的策略。其数据采用分片（Sharding）机制进行水平拆分，不同时间序列可以被划分到多个分片上存储，从而分散负载。分片的分配和重新均衡由 HoraeMeta 元数据中心自动调度，实现自动负载均衡和扩容时的数据迁移。当需要扩展性能或容量时，只需增加新的 HoraeDB 实例节点，元数据中心会将部分分片迁移到新节点上；对于读取压力，也可以添加只读副本节点分担查询。官方测试表明，在增加节点后系统吞吐和存储容量近乎线性提升，体现了良好的水平可扩展性。
高可用方面，HoraeDB 支持多副本的数据冗余和跨可用区容灾。每个数据分片可配置多个副本，写入时通过预写日志和复制协议将数据同步到副本节点。HoraeDB 允许根据场景调整数据一致性级别，例如要求多个副本ack确认以保证强一致，或降低一致性要求以获得更高吞吐。在实践中，HoraeDB 已支持同城双活和异地容灾，可在多个机房同时写入相同数据，并支持跨机房的HA查询。这意味着一个机房发生故障时，另一个机房的副本可迅速接管提供服务，满足金融级别的RPO/RTO要求。为确保故障切换时的数据正确性，系统在分片主副切换过程中使用了诸如ShardLock的机制来锁定分片，防止重复写入或部分丢失，保证数据完整一致。
此外，HoraeDB 通过无中心架构避免单点故障。元数据服务本身可以由多个节点组成Raft集群保证高可用，数据节点即使失去一两个也不会影响整体（只要有副本存活）。预写日志WAL服务也可以部署为分布式，高可靠地保存写入记录。结合完善的限流和监控机制（写入队列溢出丢弃、查询范围限制等）和自动故障转移策略，HoraeDB 构建了一个容错能力强、稳定可靠的分布式时序库。在 7*24 不间断运行的监控场景中，该系统能够在节点故障、网络分区或流量激增情况下保持服务不中断，体现出卓越的高可用性设计。
技术细节
写入优化策略
HoraeDB 面向高频数据写入进行了深度优化，能够轻松支撑每秒数百万数据点的持续灌入。首先，它支持批量异步写入机制，客户端可以成批发送数据点，服务端汇聚后异步写入存储，从而摊薄网络和磁盘IO开销。写入路径上，数据先写入内存中的 MemTable，并记录到WAL日志以确保持久性。得益于Rust实现的高效内存管理和无GC开销，MemTable 可以快速吸收并排序新数据点。对于大量小批次写入场景，HoraeDB 在内部进行了合并处理：例如将短时间内多个小写请求合并为更大块一起刷盘，提高磁盘顺序写入效率。在 1.2.2 版本中，这种合并策略将小规模请求的写入吞吐提升了数倍。
当 MemTable 中的数据达到一定阈值或时间窗口后，HoraeDB 触发刷盘（Flush） 操作，将内存数据批量转为列式的SSTables存储到对象存储或底层数据库中。由于采用列式格式和压缩，Flush 后的数据文件极为紧凑。值得一提的是，HoraeDB 支持多种底层存储引擎插件，除了默认的列式文件存储外，还可以对接外部数据库。例如已支持将 OceanBase 分布式数据库或 PostgreSQL 作为底层存储，实现数据落盘。这种插件式架构让用户可根据需求选择存储介质，在写入策略上也更加灵活（例如直接写入分布式关系库以利用其事务能力）。
写入过程中，为减小延迟，HoraeDB 广泛采用异步并行技术：WAL 写入、MemTable 持久化、索引更新等步骤解耦并多线程并发处理。此外，针对时序写入的时序性特点，HoraeDB 利用时间戳的有序性在文件存储中尽量顺序写入，降低磁盘寻道。它还对 WAL 日志引入了列式编码技术，在记录日志时先压缩整理，从而显著减少WAL大小，加快重放速度。整体而言，HoraeDB 的写路径经过精细调优，确保即使在持续高吞吐下仍能保持稳定的写入性能和较低的延迟，这为后续的实时查询提供了坚实基础。
查询执行优化
在查询执行方面，HoraeDB 借鉴了 OLAP 引擎的设计，实现了高效的查询处理。其查询引擎基于 Rust 构建，底层采用 Apache Arrow 列式内存格式和 DataFusion 分布式查询框架等技术，加速向量化计算。当用户发出 SQL 查询或 PromQL 等请求时，系统首先将其解析成逻辑执行计划，并对执行计划进行一系列优化：例如过滤下推、列裁剪（只读取查询涉及的列）、子查询合并等。针对分布式场景，HoraeDB 在 1.2.7 版本中引入了分布式查询计划支持------由协调节点将查询拆分为子任务，下发到各数据节点并行执行，然后汇总结果。这个改进显著提升了集群环境下大规模数据查询的效率。
HoraeDB 的查询处理充分利用了其混合存储结构。当查询涉及长时间范围或高数据量时，系统主要扫描列式存储文件，批量读取压缩数据并在内存中解压计算，单机上即可发挥出类似数据仓库的吞吐性能。官方基准测试显示，在低过滤选择性的查询下（即需要扫描大量数据，比如按某常见标签筛选全库数据），HoraeDB 比 InfluxDB 快 26 倍 完成相同查询（InfluxDB 参考版本为开源 1.8.x 系列，与 HoraeDB 1.x 进行对比）。这是因为此类宽范围查询受益于列存顺序扫描和批量计算，而传统 InfluxDB 逐条遍历大量倒排索引反而更慢。相反地，对于高选择性的点查查询（比如匹配特定主机的几条时间线），HoraeDB 则可以利用内存索引或快速路径直接定位数据。在这种场景下，InfluxDB 的倒排索引可能更有优势，测试中其查询延迟比 HoraeDB 快约 5 倍（15ms vs 85ms），不过绝对时间都在毫秒级。为兼顾两类场景，HoraeDB 后续版本计划进一步优化执行引擎，引入自适应索引使用策略，使查询执行能根据查询类型动态选择扫描还是索引路径。
另外，HoraeDB 非常注重内存管理和缓存优化。查询过程中常用的数据（例如最近几小时的热数据）会缓存在内存中或高速存储（官方自研的 TS-Cache 组件曾用于缓存最近3小时数据），并对时间线的最近点做增量更新优化，从而加速实时查询。对于复杂聚合计算，例如 group by 多标签、时间窗口聚合等，HoraeDB 的引擎进行了算法层面的改进，利用并行计算和分片聚合减少单节点压力。此外，HoraeDB 还提供了查询结果的去重和合并机制：在分布式查询或重复数据场景下，自行检测并消除重复数据，以确保结果准确同时降低网络传输量。通过上述种种优化，HoraeDB 在保证功能丰富性的同时，实现了对大规模时序数据查询的卓越性能。
数据压缩与存储优化
高效的压缩存储是 HoraeDB 相较传统方案的一大优势。HoraeDB 的列式存储引擎结合时序数据特点，默认提供10:1 以上的高压缩比，显著降低存储成本。在列存格式下，相同字段的数据按列集中存储，天然适合应用压缩算法（如 Gorilla 压缩用于时间序列值的 delta-of-delta、XOR 编码等）。HoraeDB 利用这种列内相关性，对时间戳列和数值列分别压缩。例如连续的时间戳存储为起始时间加增量编码，数值则采用 XOR 差分编码。再辅以通用压缩算法（如 LZ4、ZSTD）作用于列数据块，使得长期未变化或变化平稳的序列可以被极度压缩。在京东智联云的实践中，HoraeDB 使用 delta-of-delta 与 XOR 对最近几小时数据压缩，成功在内存缓存中保存大量热点数据。
除了压缩算法，HoraeDB 通过冷热数据分层存储优化成本和性能。新写入的"热"数据保存在较快介质（内存或本地SSD）并频繁访问，而历史"冷"数据定期下沉到低成本存储（HDD集群或对象存储）保存。查询时根据时间范围自动路由到对应层级，大部分查询因集中在近期数据而能从高速层获得结果，极大加快响应。对于超大规模的数据集，HoraeDB 还支持时间分区裁剪，避免扫描过期数据，并提供数据保留策略（如自动清理超过保留期的数据）降低存储占用。值得一提的是，由于HoraeDB 支持将数据存放到外部系统（如 OceanBase、PostgreSQL 等），用户可以利用这些系统自身的存储优化特性（索引、压缩、分区等）来管理 HoraeDB 的数据。这种开放架构进一步提高了弹性------例如在云上可以直接利用对象存储无限扩展容量，在本地则能对接已有数据库系统作为底座。
归功于上述技术，HoraeDB 在实际部署中展现出了低存储成本和高读写效率兼备的特性。例如，某些工业物联网场景下，每日TB级的数据接入后经过 HoraeDB 压缩仅占用百GB级存储，而查询最近一年的数据仍可在秒级返回。存储优化不仅节约了物理空间，也减少了I/O，进一步提升了性能。
事务处理与一致性模型
虽然时序数据通常是追加写入且事务需求不如OLTP强烈，HoraeDB 仍提供了必要的一致性保障和事务支持。在单机层面，HoraeDB 保证每条写入按照WAL日志顺序原子地应用到内存表和存储引擎中，实现写入操作的原子性。对于同时写入多个测点（fields）的请求，要么全部成功写入，要么全部失败回滚，不会出现部分更新的情况。这样可以确保单次写入的多个相关数据点一致可见。
在分布式环境下，HoraeDB 采用最终一致性加可调的强一致模型。默认情况下，数据写入到主节点后通过WAL复制到多个副本节点，在副本持久化后再应答客户端，从而实现跨节点的数据同步。如果要求强一致，HoraeDB 可配置写入需要多数副本确认才算成功（类似于 Cassandra 的 QUORUM 写策略）。对于读取，则通过元数据服务或查询路由确保读取到最新数据；在副本切换期间，利用前述 ShardLock 锁定分片避免读到不一致的数据。这些机制结合，使 HoraeDB 在常规运行时对外表现为强一致：客户端读取到的要么是完整的新数据，要么是旧数据，而不会混杂不完整更新。
值得注意的是，HoraeDB 还支持多数据中心双写模式以增强可靠性。在该模式下，不同机房的实例可以同时接收写入，每个写入操作被同步到两个机房的存储，从而实现 RPO≈0 的容灾能力。为避免双活导致的数据冲突，HoraeDB 通过全局唯一时间线标识及冲突检测策略，保证同一条时间序列的数据流向单一主源。当某一机房不可用时，另一侧接管写入并继续保证一致性。
在事务隔离级别上，HoraeDB 提供读已提交（Read Committed）语义，即读取不会看到未提交的数据。由于主要操作是时间序列的单调插入，复杂的事务隔离需求较少。对于管理类操作（如表定义变更），HoraeDB 通过元数据服务顺序执行，确保集群的一致视图。总体来说，HoraeDB 在保持高性能的同时，通过WAL、复制和元数据协调，实现了对数据一致性的可靠保障，可满足监控告警等对准确性要求高的场景。用户也可根据需要权衡一致性和性能，例如在某些场景降低副本确认数以换取更快写入。HoraeDB 将底层复杂的分布式一致性逻辑对用户透明化，提供了一个简洁但可信的事务与一致性模型。
性能对比（与 InfluxDB）
作为新兴的时序数据库，HoraeDB 常被拿来与业界成熟方案 InfluxDB 做对比。下面从读写性能、资源占用、吞吐量与扩展性等方面，将 HoraeDB 与 InfluxDB 进行比较，并给出关键指标的对比表格。
表1：HoraeDB 与 InfluxDB 性能与特性对比
注意：InfluxDB 参考版本为开源 1.8.x 系列，与 HoraeDB 1.x 进行对比。
| 对比维度 | HoraeDB | InfluxDB |
|---|---|---|
| 写入性能 | 吞吐量稳定且随时间几乎不降，长期平均约为 InfluxDB 的 1.5 倍；高并发批量写入下仍能保持低延迟。 | 初始写入速度较快，但因维护内存索引，随数据增多性能逐步下降；高基数场景下内存开销增大影响写入。 |
| 读取性能（低选择率查询） | 面对大范围扫描查询表现卓越：在扫描大量数据点的查询中，比 InfluxDB 快 26 倍 完成任务。列式存储和分区剪枝使其擅长聚合计算和全库分析。 | 大量数据扫描时性能显著下降：同等查询耗时达 6 分 43 秒，而 HoraeDB 仅需 15 秒。倒排索引在此类宽查询中作用有限，I/O 开销大。 |
| 读取性能（高选择率查询） | 针对精确匹配的小范围查询，延迟低至毫秒级，但因主要采用扫描策略，在极端高选择性的简单查询上稍逊：如按主机筛选单点查询耗时 ~85ms。后续计划引入更多索引优化此场景。 | 受益于倒排索引，小范围点查非常快速：相同查询耗时约 15ms，比 HoraeDB 快约 5 倍。但其优势仅限于少量时间线或精确标签匹配的查询，对宽表查询不利。 |
| 数据压缩效率 | 默认采用列式压缩，压缩比可达 10:1；同等数据占用存储空间更小。冷数据可移至对象存储，降低总体成本。 | 使用 TSM 存储引擎（LSM 结构），对时序数据也有压缩（如 Gorilla 算法），压缩率可观但通常在 2-4 倍量级，不及 HoraeDB 列存。长期存储成本相对较高。 |
| 内存占用 | 内存主要用于缓存热数据和维护必要的元数据索引。对高基数标签没有强依赖的全局索引，内存占用随时间线数目增长较平缓。可根据需要启用部分索引，灵活控制内存开销。 | 维护全局标签倒排索引，内存占用随时间线数目线性增长；高基数场景下索引占用内存巨大，可能达到几十GB级别，造成内存压力。需要定期重启或扩容以释放索引内存。 |
| CPU 利用率 | 列式扫描和向量化执行充分利用 CPU 进行批量处理，在大查询时可能出现较高 CPU 利用率以换取更快完成时间。整体查询更快，单位数据点CPU耗时更低。 | 小范围查询CPU耗时低（因有索引跳过无关数据），但大范围查询由于遍历数据点多，CPU长时间繁忙。整体CPU模式随查询类型波动较大，在复杂分析查询时效率偏低。 |
| 水平扩展 | 原生支持集群横向扩展：添加节点可线性提升吞吐和容量，无中心架构避免单点瓶颈。支持数据分片和副本，可在分布式环境运行良好。 | 开源版 1.x 不支持集群横向扩展（单机为主），企业版和 InfluxDB 2.x Cloud 提供分布式方案但需付费或专有。扩展性受限，单节点性能达到瓶颈后需复杂分片架构。 |
| 高可用 | 支持多副本容灾，同城双活和异地灾备。任一节点故障时有副本接管查询，WAL 确保故障期间数据不丢。系统自动故障转移，具备金融级 HA 能力。 | 开源版单节点存在单点故障风险，需要手动主从切换或外部工具备份。企业版支持集群副本和跨数据中心，但开源用户需自行实现HA方案，容灾能力弱于 HoraeDB。 |
| 协议生态 | 兼容 PromQL、InfluxQL、OpenTSDB 协议，提供 RESTful API 和多语言 SDK，便于集成现有监控系统。可插拔存储和计算组件，生态开放。 | 原生支持 InfluxQL 和 Flux 查询语言，提供HTTP API 和客户端库。与 PromQL 兼容性较弱（需第三方适配）。生态主要围绕自有组件，开放性一般。 |
上表概括了 HoraeDB 与 InfluxDB 在关键性能和特性上的比较。可以看出，HoraeDB 在批量写入性能上占优，其设计避免了写入时索引更新的瓶颈，因而随着运行时间推移吞吐保持稳定，整体写入速度达到 InfluxDB 的1.5倍以上。在查询性能方面，两者各有所长：HoraeDB 依托列式扫描对大规模聚合查询有压倒性优势，某些全库分析查询比 InfluxDB 快一个数量级以上；而 InfluxDB 针对点查询和小范围过滤有成熟的倒排索引支持，在这类查询上仍比 HoraeDB 更快。不过值得注意的是，现实监控场景中大量查询涉及最近短时间范围的数据，HoraeDB 通过缓存和快速扫描也能提供毫秒级响应，并且其性能不会因时间线数量爆炸而严重劣化，这对大规模监控尤为重要。
另外，在资源占用上，HoraeDB 对内存的需求相对可控，用户可按需启用或调整索引，以避免 Index 占用过多内存；InfluxDB 则往往需要为高基数场景预留大量内存。CPU利用上，HoraeDB 借助向量化优势在总体上处理相同数据量更高效，但遇到简单查询时可能会"满载"运行更短时间。两者权衡来看，HoraeDB 更适合超大规模、多标签的时序数据平台，而 InfluxDB 在中小规模部署或简单查询场景也能提供可接受的性能。
在吞吐量与可扩展性方面，HoraeDB 因原生分布式架构，几乎可线性扩展其吞吐量和存储容量。通过增加节点，HoraeDB 已展示出集群性能的线性增长，这一点是开源版 InfluxDB 无法达到的（后者受限于单机性能）。另外，HoraeDB 提供了企业级的高可用和容灾能力，如多活部署和数据冗余，这在关键业务场景下保障了持续服务。而 InfluxDB 开源版缺乏内置HA，需要借助第三方工具或升级企业版才能达到类似能力。
总的来说，HoraeDB 相比 InfluxDB 展现出更佳的扩展性和在特定负载下的性能优势。当然，在成熟度和生态广泛度上，InfluxDB 发展多年依然有其优势，如更完善的可视化工具和社区。但是随着 HoraeDB 在 2025 年逐步走向稳定并融入 Apache 社区，其性能领先的特性和云原生架构有望在越来越多实际场景中展现价值。
官方路线图与未来规划
2025 年官方规划及关键技术演进
根据官方透露的信息，HoraeDB 在 2024-2025 年将持续聚焦性能优化、功能完善和社区生态三大方向。一方面，核心团队计划进一步改进底层引擎，引入新的存储格式和索引结构以适配不同场景需求。例如，为提升高选择性查询性能，可能增加倒排索引或其他索引类型的可选支持，使查询优化策略更加智能。在存储层面，团队会探索更高效的文件格式（如自研列存格式或优化 Parquet）来提高读写性能和压缩率。同时，事务一致性方面也将加强，尤其是在分布式部署下完善一致性协议，可能引入更智能的副本同步和故障转移算法，以进一步缩短故障恢复时间。
另一方面，分布式集群能力会在2024年得到巩固并提升。如官方路线图所示，1.x 版本已实现基本的分布式部署和计算存储分离，后续版本将着力完善自动负载均衡和弹性扩容。这包括动态感知节点压力并迁移分片、在高峰期自动增加资源、低谷期收缩节点等特性，使 HoraeDB 真正成为云环境下按需伸缩的时序数据库。此外，团队也致力于提高系统的可Observability（可观测性）和可运维性，计划推出完善的自监控指标、集群运维工具以及 Kubernetes 运维方案，以方便用户在生产环境大规模部署。
截至 2025 年初，HoraeDB 已发布多个迭代版本。根据 2023 年的版本节奏（全年发布了 8 个版本），2024 年推出重要的 2.0 版本或接近成熟的版本，为毕业出 Apache 孵化器做准备。关键技术更新方面，2023 年下半年已经实现 Kafka WAL、查询计划优化、随机分区等功能；2024 年重点推出例如跨引擎存储融合（打通不同存储插件的数据一致视图）、更加智能的查询优化器（借助统计信息自动选择执行计划）、安全与权限控制（满足企业级安全需求）等新特性。总体而言，2025 年的 HoraeDB 将朝着稳定可靠、性能领先、功能完备的目标演进，并逐步满足更多元的业务需求。
生态系统发展方向（插件与扩展支持）
HoraeDB 秉承"拥抱开源生态"的理念，在生态系统构建上有明确规划。首先在接口兼容性上，HoraeDB 已兼容 Prometheus RemoteWrite/RemoteRead 接口、PromQL 查询语言以及 OpenTSDB/InfluxDB 的写入协议。未来这方面将持续完善，确保用户可以无缝迁移现有监控数据到 HoraeDB，或将 HoraeDB 作为后端存储接入 Prometheus 等生态工具。官方也提供了多语言的 SDK（如 Go、Java、Python 等）并将在2025年支持更多语言，以方便开发者接入。
在插件化和扩展支持方面，HoraeDB 展现出开放架构的优势。2023 年的更新已经表明，HoraeDB 可以对接不同底层存储（OceanBase、PostgreSQL 等），这实际上是一种存储引擎插件机制。展望未来，HoraeDB 可能会开放存储引擎接口，允许社区开发自定义存储后端插件，如接入分布式文件系统、云原生 Lakehouse 存储（Iceberg、Delta Lake）甚至新型硬件（例如时序专用存储设备）。同理，在计算层，HoraeDB 可与其他系统联动：比如作为流处理框架 Apache Flink 的外部表，或支持 Apache Spark 的数据源插件，以便在大数据平台中查询 HoraeDB 数据。这些扩展将极大丰富 HoraeDB 的应用场景。
此外，HoraeDB 社区也在探索UDF（用户自定义函数）和计算插件支持，让高级用户可以定制特殊的时间序列计算逻辑并嵌入查询引擎。考虑到 AI 与时序数据的结合日趋紧密，未来 HoraeDB 有望提供 ML 插件或与时序预测库的集成接口，为工业预测、异常检测等场景提供开箱即用的支持。生态方向的另一个重点是可视化和管理工具：目前 Grafana 已可通过兼容接口查询 HoraeDB，后续官方可能推出专门的时序数据可视化分析工具或与现有开源项目合作，简化数据展示与报表制作。对于运维，则可能发布图形化的集群管理界面、数据迁移工具、性能诊断工具等周边软件，形成完整的生态体系。综上，HoraeDB 2025 年的生态建设将围绕开放、集成、多样展开，使其不仅是一个数据库内核，更成长为一个时序数据平台，支持插件扩展和与周边系统的无缝协作。
行业应用前景
HoraeDB 作为新一代时序数据库，在诸多行业场景中具有广阔的应用前景。首先是在其诞生的运维监控领域：大型互联网公司每秒会产生海量的服务器指标、日志数据，需要高性能时序库来存储和实时分析。京东智联云正是出于监控需求自研了 HoraeDB 的前身；蚂蚁集团也将 HoraeDB 应用于内部系统以应对高维度指标监控和告警。可以预见，随着 HoraeDB 成熟，互联网运维(AIOps)领域会广泛采用它来替代或补充现有的 Prometheus+TSDB 方案，实现更高效的监控数据存储与查询。
在物联网 (IoT) 行业，HoraeDB 同样大有用武之地。IoT 设备无时无刻不在产生传感器读数、状态日志，这些数据具有典型的时序特征且规模庞大。HoraeDB 的高写入吞吐和水平扩展能力非常契合物联网场景，可以作为物联网平台的时序数据池，支撑实时设备监控、远程测控和历史数据分析。尤其在智慧城市、工业4.0等需要汇聚海量传感数据的系统中，引入 HoraeDB 后端将显著提升数据处理效率。此外，其支持多标签查询的特性方便按设备属性、区域等维度筛选分析数据。
金融行业的交易和行情分析也是一个潜在应用方向。股票、期货等金融市场每秒都有大量行情数据，交易系统也产生订单成交等事件序列，这些都属于时序数据。HoraeDB 可以用来存储高频交易数据和市场指标，并利用其OLAP能力做事后分析或实时风控。例如，券商可用 HoraeDB 记录行情走势图数据，支持交易策略回测和异常波动检测。HoraeDB 对高并发读写和高基数tag的支持，能满足金融数据中不同Ticker（股票代码）、交易所等标签组合的查询要求，同时保证数据一致性，对金融机构具有吸引力。
在能源和工业监测领域，如电力设备传感、石油管道压力监测、工厂生产数据采集等，也广泛存在时序数据需求。传统关系型数据库难以高效存储和查询这些数据，而 HoraeDB 提供了高压缩低成本的存储方案，可以长周期保存历史数据供统计分析，并在异常时提供实时告警查询。这将帮助电力、制造业等行业实现精细化运营和预测性维护。
最后，随着 AI 技术的发展，AI 时序数据管理也可能成为 HoraeDB 新的增长点。机器学习模型训练往往需要处理时序特征（如时序预测、时序异常检测的数据），HoraeDB 可以作为底层数据仓库，为上层 AI 平台提供快速数据提取、聚合功能。例如，在智能驾驶领域，车辆传感器数据流可以存入 HoraeDB，AI 模型可直接从中读取做行为分析。在智慧运维中，模型可以实时从 HoraeDB 获取指标序列进行异常识别。这种数据库+AI的结合将拓展HoraeDB的应用边界，赋能更多智慧化场景。
综上所述，HoraeDB 凭借其在性能、扩展性和灵活性上的突出特点，在 2025 年及未来有望在互联网运维、物联网、金融交易、工业能源乃至AI应用等多个行业中落地开花，成为时序数据管理领域的重要支柱技术之一。随着社区的壮大和功能的日趋完善，我们有理由期待 HoraeDB 在更多关键业务场景中发挥核心作用。
未来发展时间轴
为更直观地了解 HoraeDB 的演进历程和未来规划，下面给出一个简要的发展时间轴，其中包含重要里程碑和预期的未来计划：
- 2018-2021：技术探索阶段 -- HoraeDB 团队在时序数据高基数、高并发领域开展研究和预研，摸索解决传统 TSDB 性能瓶颈的方法。京东云内部开始实现早期版本架构（基于 ES+Casandra 的时序库）并投入监控场景验证。
- 2022 年 6 月：开源 CeresDB -- 蚂蚁集团发布 CeresDB 开源项目，将其内部时序数据库核心代码开放出来。此时系统已具备较高性能和弹性，并奠定了 HoraeDB 后续发展的基础。
- 2023 年 4 月：HoraeDB 1.0 发布 -- 团队发布 1.0.0 版本，实现存储计算分离的全新架构，支持分布式集群部署，并兼容 Prometheus 生态。随后的多个小版本快速迭代，引入 InfluxQL 支持、Kafka WAL、查询优化等特性。全年累计发布 8 个版本，高基数写入和查询性能显著提升。
- 2023 年 12 月：加入 Apache 孵化器 -- 蚂蚁将 CeresDB 核心捐赠给 Apache 基金会并更名为 "Apache HoraeDB (Incubating)" 正式孵化。
- 2024 年：功能成熟与生态完善 -- 按计划推出 1.x 后续版本和 2.0 版本，重点完善分布式可靠性、引入新索引结构、加强安全权限等。同时扩展周边生态，发布运维管理工具、支持 Kubernetes、一键部署等，使 HoraeDB 成熟度达到生产可用水准。
- 2025 年：规划毕业与广泛应用 -- 预计在 2025 年中左右，HoraeDB 将满足 Apache 毕业标准，成为顶级项目 (TLP)，标志其社区和技术的成熟。技术方面继续优化性能，可能推出革命性的新功能如自动存储优化、多租户支持等。HoraeDB 在各行业的落地案例显著增加，生态系统繁荣，或将出现云厂商推出基于 HoraeDB 的托管时序数据库服务。
通过上述时间轴可以看出，HoraeDB 从内部自研到开源孵化，用了不到五年时间便达到了一个功能完备、性能领先的阶段。展望未来，随着社区共同努力，HoraeDB 有望在 2025 年迈入新的征程，在开源时序数据库版图中占据一席之地，为更多场景提供可靠支撑。各行业对实时海量数据处理的需求正不断攀升，HoraeDB 的未来发展值得期待。