DingoDB Store：HTAP存储引擎的LSM-Tree、Raft与向量索引融合设计

1. 项目概述从“分布式键值存储”到“实时数据服务引擎”的蜕变最近在梳理团队内部的数据架构选型时一个名为 DingoDB 的项目引起了我的注意。准确地说我关注的是其核心存储组件dingodb/dingo-store。乍一看仓库名很容易让人联想到又一个“分布式键值存储”系统毕竟市面上已经有了 RocksDB、TiKV 等成熟方案。但当我深入其设计文档和代码实现后发现它的野心远不止于此。dingo-store的定位是一个为实时分析Real-time Analytics和混合事务/分析处理HTAP场景而生的高性能、低延迟分布式存储引擎。它试图在传统 OLTP 数据库的事务一致性与大数据分析系统的高吞吐、低延迟查询之间架起一座桥梁。这让我想起了过去几年在构建实时推荐、风控和运营看板时那种在多个存储系统间“缝缝补补”的酸楚——事务数据在 MySQL分析数据在 HBase 或 ClickHouse中间靠 Kafka 和 Flink 做流式同步架构复杂运维成本高端到端延迟还难以控制。dingo-store的出现似乎提供了一种“All in One”的新思路它通过一套存储同时支持点查、范围扫描和聚合分析并且原生拥抱向量计算这正好切中了当前 AI 应用对“向量数据库”和“实时特征库”的迫切需求。接下来我将从一个一线架构师的视角拆解dingo-store的核心设计、技术选型背后的权衡并分享如何在实际场景中评估和试用它。2. 核心架构与设计哲学拆解2.1 存储引擎的“三驾马车”LSM-Tree、Raft 与向量索引dingo-store的架构基石可以概括为三个关键技术LSM-Tree日志结构合并树、Raft 一致性协议以及为向量数据优化的索引结构。选择 LSM-Tree 而非 BTree是其面向写优化和顺序 I/O 性能的关键决策。在实时数据场景下写入往往是爆发式的如用户行为日志、IoT 设备上报LSM-Tree 通过将随机写转换为顺序追加写WAL MemTable并异步进行 Compaction能够轻松应对高吞吐写入。但 LSM-Tree 的读放大Read Amplification问题也众所周知。dingo-store对此的优化在于其多级 Compaction 策略和 Bloom Filter 的精细使用。例如在内存表MemTable达到阈值后会 Flush 成不可变的 SSTableSorted String Table后台线程会根据数据的热度和重叠度进行分层Leveled或分级Tiered的 Compaction这个过程会合并重复键、删除标记并重新组织数据以优化读取路径。一致性方面dingo-store选择了 Raft 而非 Paxos。Raft 以其易于理解和实现的特性著称它将共识问题分解为领导选举、日志复制和安全性三个相对独立的子问题。在dingo-store中数据被分片Region存储每个 Region 的多个副本通常为 3 或 5 个构成一个 Raft Group。所有写请求都必须通过 Leader 副本由 Leader 将操作追加到自己的日志中然后并行复制到 Follower在获得多数派确认后才提交并应用到状态机即存储引擎。这套机制保证了数据的强一致性和高可用性——即使少数节点宕机集群仍可正常服务Leader 宕机后Follower 能通过选举快速产生新的 Leader。最让我感兴趣的是它对向量数据的原生支持。这不仅仅是简单地将向量存储为二进制大对象BLOB。dingo-store在存储层集成了诸如 HNSWHierarchical Navigable Small World、IVFInverted File Index等近似最近邻ANN索引算法。这意味着当你插入一个高维向量如图像特征、文本嵌入时存储引擎会同步构建或更新对应的向量索引结构。查询时可以直接在存储层进行高效的向量相似度搜索避免了传统方案中需要将数据拉到计算层如 Spark、Flink再建索引的额外开销和延迟。这种“存算一体”的设计是它宣称低延迟实时分析的关键。2.2 数据模型与 API 设计超越简单的 Key-Value虽然底层是键值存储但dingo-store向上暴露的数据模型更为丰富。它支持类似关系型的表Table概念表有预定义的 Schema包含标量列整数、字符串等和向量列。这使其更接近一个分布式的、支持向量的“宽表”存储。在 API 层面它提供了多维度的访问接口点查Point Get通过主键可以是标量或向量快速检索单行数据。这是 OLTP 类操作的基础。范围扫描Range Scan通过主键范围进行迭代查询支持前缀匹配适用于时序数据或范围查询场景。向量搜索Vector Search基于向量列进行 K-最近邻K-NN或近似最近邻搜索可结合标量过滤条件如WHERE category ‘A’ AND vector_distance 0.2。批量操作Batch Put/Get支持高性能的批量写入和读取提升吞吐量。这种设计使得应用层无需再维护复杂的多系统集成。例如一个商品推荐系统可以将商品 ID、属性、实时销量标量和商品特征向量存储在同一张表、同一行中。一次查询既能通过商品 ID 快速获取详情点查也能根据用户画像向量找到最相似的商品向量搜索还能筛选出特定类目下销量最高的商品标量过滤向量搜索。所有操作都在一次存储引擎的交互中完成极大地简化了应用逻辑并降低了延迟。注意这种融合模型也带来了新的挑战比如资源隔离。一个消耗大量 CPU 的向量搜索查询可能会影响同一 Region 上点查的延迟。dingo-store通常通过资源组Resource Group或查询优先级Query Priority机制来进行一定程度的隔离但在设计数据分片Sharding策略时仍需考虑工作负载的特性尽量避免“热点”Region。3. 部署、配置与核心操作实战3.1 集群部署模式与选型建议dingo-store支持多种部署模式以适应从开发测试到生产环境的不同需求。All-in-One 单机模式所有组件存储节点、元数据服务、协调节点运行在单个进程中。这仅用于功能验证和开发调试绝对不能用于生产环境。启动命令通常很简单如./dingodb_store --config config.yaml。多进程分布式模式这是生产环境的推荐模式。核心组件包括Store Node数据存储节点负责实际数据的读写、Raft 副本管理、Compaction 等。是资源CPU、内存、磁盘消耗的主要部分。Coordinator协调节点负责集群元数据管理、负载均衡、Region 调度分裂、合并、迁移和全局时钟服务TSO。它本身不存储用户数据但需要高可用。Proxy / SDK客户端访问入口。应用通过 SDK 或独立的 Proxy 服务连接到集群。SDK 会从 Coordinator 获取数据路由信息哪个 Key 在哪个 Store Node 的哪个 Region然后直接与对应的 Store Node 通信避免单点瓶颈。在生产部署时我建议采用至少 3 个 Coordinator 节点构成一个高可用组使用 Raft 保证元数据一致性。Store Node 的数量则取决于数据量和吞吐需求初期可以从 3 个开始随着数据增长线性扩展。每个 Store Node 应部署在独立的物理机或虚拟机上并配备高性能 SSD如 NVMe以获得最佳的 I/O 性能因为 LSM-Tree 的 Compaction 是 I/O 密集型操作。网络配置至关重要。所有节点间需要低延迟、高带宽的网络互通。通常需要设置内部域名或静态 IP并在配置文件中明确指定。防火墙需开放节点间用于 Raft 通信、数据迁移、心跳检测的端口以及客户端访问 Proxy/SDK 的端口。3.2 关键配置参数解析与调优配置文件是性能调优的核心。以下是一些关键参数及其影响存储引擎相关 (store配置块)region.max-size单个 Region 的最大容量如 96MB。当 Region 数据量超过此阈值时会自动触发分裂Split。设置太小会导致 Region 数量过多增加元数据管理和 Raft 开销设置太大会导致单个 Region 负载过重不利于并行化和负载均衡。需要根据平均键值大小和访问模式进行权衡。raft.max-size-per-msgRaft 日志条目最大大小。影响日志复制的吞吐量。对于大向量插入场景可能需要调大此值。rocksdb.write-buffer-size/max-write-buffer-numberMemTable 的大小和数量。更大的 Write Buffer 可以吸收更多的突发写入减少 Flush 频率但会增加内存占用和故障恢复时间。rocksdb.level0-file-num-compaction-trigger触发 L0 Compaction 的 SST 文件数阈值。L0 文件是直接由 MemTable Flush 产生未排序。此值设置较小会频繁触发 Compaction增加写放大设置较大会增加读放大因为读可能需要遍历多个 L0 文件。需要监控rocksdb.stats中的stalls写停顿和get延迟来调整。向量索引相关 (vector配置块)index.type选择 HNSW 或 IVF 等算法。HNSW 通常查询精度和速度更好但构建耗时和内存占用更高IVF 构建更快内存更省但需要基于数据分布训练聚类中心。hnsw.efConstruction/MHNSW 索引的构建参数。M影响图的连通性和内存占用efConstruction影响构建时的搜索范围值越大精度越高构建越慢。这需要在索引质量和构建成本间取得平衡。ivf.nlistIVF 索引的聚类中心数量。影响搜索时需要遍历的聚类数量同样需要在精度和速度间权衡。一个实用的调优流程是先在测试环境用代表性数据负载进行压测观察 Grafana 监控面板如果集成中的关键指标写吞吐Ops/Sec、写延迟P99、读延迟P99、Compaction 压力、CPU/内存/磁盘 IO 使用率。然后有针对性地调整上述参数。通常遵循“先默认后微调”的原则优先调整最可能成为瓶颈的参数。3.3 基础数据操作与向量搜索示例假设我们使用 Python SDK 操作一个存储商品信息的表。# 1. 连接集群 from dingodb import DingoDB client DingoDB(useruser, passwordpasswd, host[coordinator1:port, coordinator2:port]) # 2. 创建包含向量列的表 table_name product_features schema [ {name: product_id, type: INTEGER, primaryKey: True, autoIncrement: False}, {name: category, type: VARCHAR, length: 50}, {name: price, type: DOUBLE}, {name: feature_vector, type: FLOAT_VECTOR, dimension: 128, indexType: HNSW} # 指定向量维度和索引类型 ] client.create_table(table_name, schema) # 3. 插入数据混合标量和向量 import numpy as np data [ [1001, electronics, 299.99, np.random.random(128).astype(np.float32).tolist()], [1002, clothing, 59.99, np.random.random(128).astype(np.float32).tolist()], ] client.insert(table_name, data) # 4. 点查 result client.get(table_name, [1001]) print(fProduct 1001: {result}) # 5. 向量相似度搜索 query_vector np.random.random(128).astype(np.float32).tolist() search_params {search_params: {ef: 100}} # HNSW搜索参数 # 查找最相似的5个商品并过滤类别为electronics results client.vector_search( table_name, query_vector, top_k5, search_paramssearch_params, filtercategory electronics ) for item in results: print(fSimilar product ID: {item[product_id]}, distance: {item[distance]})这个例子展示了从建表、插入到查询的完整流程。关键在于向量搜索和标量过滤在存储层被合并执行这比先过滤再搜索或先搜索再过滤的效率要高得多。4. 性能压测、监控与问题排查4.1 设计有意义的性能基准测试评估dingo-store是否适合你的业务不能只看官方数据必须用自己的数据和访问模式进行压测。压测应覆盖以下场景纯写入负载模拟日志灌入场景。使用工具如自己编写的脚本或适配的 YCSB 工具持续写入随机或有序的键值对可包含向量。监控指标写入吞吐量ops/sec、写入延迟分布P50, P90, P99、磁盘 I/O 利用率、Compaction 线程 CPU 使用率。观察随着数据量增长性能是否平滑有无剧烈波动或写入停顿Write Stall。读写混合负载模拟在线业务场景。配置一定比例的读点查、范围扫描和写操作。监控指标读写吞吐、读写延迟、CPU 综合使用率。特别注意在持续写入背景下读延迟是否会劣化。向量搜索负载模拟 AI 查询场景。并发执行向量相似度搜索可搭配不同 selectivity 的标量过滤条件。监控指标查询吞吐QPS、查询延迟P99、向量索引内存占用。测试在不同数据集规模如 100万、1000万向量下的性能表现。稳定性与故障恢复在压测过程中随机重启某个 Store Node 或 Coordinator 节点观察集群是否能够自动恢复服务数据是否一致性能影响持续时间。压测数据应尽可能接近生产环境的数据特征如键的大小、分布是否热点向量维度、分布等。压测时间应足够长如持续数小时以观察 Compaction 对长期性能的影响。4.2 核心监控指标与告警设置一个可观测的集群是稳定运行的保障。dingo-store通常暴露了丰富的 Prometheus 指标。以下是我认为必须监控的核心指标监控类别关键指标说明与告警阈值建议集群健康cluster_state集群状态1正常0异常。任何非1状态立即告警。region_countRegion 总数。短期内剧烈增长可能预示分裂异常或负载不均。store_livenessStore Node 存活状态。节点宕机立即告警。性能request_duration_seconds请求延迟按类型get, put, scan, vector_search区分。P99延迟超过 SLA如50ms告警。request_throughput请求吞吐量。大幅下跌可能预示瓶颈或故障。存储引擎rocksdb_stall_percentage写停顿比例。持续大于0表示写入被 Compaction 阻塞需调优或扩容。rocksdb_compaction_pending待 Compaction 任务数。持续高位表示 Compaction 跟不上写入速度。rocksdb_memtable_sizeMemTable 大小。接近配置上限可能触发频繁 Flush。资源process_cpu_seconds_rateCPU 使用率。持续高于80%可能成为瓶颈。process_resident_memory_bytes内存占用。关注是否持续增长潜在内存泄漏或接近物理内存导致Swap。disk_usage_percentage磁盘使用率。超过85%需考虑清理或扩容。Raftraft_log_lagFollower 日志落后 Leader 的条数。持续落后可能影响可用性。raft_propose_duration提案延迟。延迟高可能网络或磁盘有问题。建议使用 Grafana 搭建监控面板将上述指标可视化并设置相应的告警规则接入到钉钉、企业微信等告警平台。4.3 典型问题排查实录在实际测试和运维中你可能会遇到以下问题问题一写入速度突然变慢客户端出现超时。排查思路查看监控首先检查rocksdb_stall_percentage和rocksdb_compaction_pending。如果很高说明写停顿了。检查磁盘通过iostat -x 1查看磁盘利用率%util和响应时间await。如果磁盘已饱和%util持续接近100%说明 I/O 是瓶颈。检查内存确认rocksdb_block_cache_size和 MemTable 总大小是否配置合理。如果 Block Cache 太小会导致频繁读盘影响 Compaction 和写入速度。解决方案短期如果磁盘 I/O 饱和可能是 Compaction 过于频繁。可以临时调大level0_file_num_compaction_trigger和write_buffer_size减少 Compaction 频率但会牺牲一些读性能。长期升级硬件使用更高性能的 SSD如 NVMe。优化 Compaction 策略考虑使用universalcompaction 模式如果支持来减少写放大。增加 Store Node 节点分散写入压力。问题二向量搜索查询延迟不稳定偶尔出现长尾延迟。排查思路检查查询负载是否并发查询过高监控vector_search的 QPS 和并发连接数。检查资源竞争观察在查询延迟高的时间段CPU 使用率是否也飙高是否有后台 Compaction 或 Region 迁移任务在运行。检查索引参数对于 HNSW 索引查询时指定的ef参数是否过小过小的ef会影响搜索精度和速度可能需要回溯更多。解决方案使用资源组隔离线上查询任务和后台管理任务。优化查询的ef参数在精度和速度间找到平衡点。可以在测试环境绘制ef值与召回率、延迟的关系曲线。考虑将向量索引加载到更快的存储介质如内存映射文件或 PMem如果索引文件在普通磁盘上I/O 可能成为瓶颈。问题三集群扩容后负载没有均匀分布。排查思路检查 Region 分布通过管理命令或监控查看每个 Store Node 上的 Region 数量。是否严重不均检查热点 Key如果业务存在热点 Key如某个热门商品ID会导致该 Key 所在的 Region 成为热点即使 Region 数量均衡负载也不均衡。解决方案等待 Coordinator 的自动调度。Coordinator 会周期性地检查节点负载并尝试将 Region 从高负载节点迁移到低负载节点。如果存在明确的热点可以考虑从业务层面进行优化例如对热点 Key 进行打散Salting或者在表设计时使用更合理的分片键Shard Key让写入和查询能分散到多个 Region。5. 适用场景分析与选型对比5.1 哪些场景适合使用 DingoDB Store经过上面的分析dingo-store的核心优势在于“混合负载”和“实时分析”。以下几类场景是其发挥价值的舞台实时特征平台Feature Store这是我认为最契合的场景。机器学习模型需要最新的用户特征和物品特征进行实时推理。传统方案需要从 OLTP 数据库、消息队列、离线数仓等多个源头拼接特征流程长、延迟高。dingo-store可以作为一个统一的实时特征库同时存储标量特征用户画像、商品属性和向量特征Embedding支持高吞吐更新和低延迟点查、向量检索极大简化特征管线。融合搜索与推荐系统用户搜索时既要基于文本匹配标量过滤又要基于语义相似度向量搜索。dingo-store可以在一张表内同时支持这两种索引实现混合查询避免跨系统 JOIN 带来的复杂度和延迟。实时数据湖/湖仓一体入口作为流式数据如 Kafka 数据的实时摄入层在提供低延迟查询服务的同时可以将数据定期快照到更廉价的离线存储如 HDFS、S3中进行深度分析形成实时与离线联动的架构。物联网IoT时序数据监控设备上报的带有时序标签和指标向量的数据可以按设备ID分片高效支持按时间范围扫描和特定模式的向量异常检测。5.2 与同类系统的横向对比为了更清晰地定位我们可以将其与几个知名系统进行简单对比特性/系统DingoDB StoreTiKVApache HBaseElasticsearch核心数据模型强 Schema 宽表标量向量分布式事务键值稀疏列族宽表JSON 文档一致性模型强一致性Raft强一致性Raft最终一致性/强一致性Region级别最终一致性多副本索引支持主键索引 向量索引主键索引仅行键索引倒排索引 向量索引插件典型查询点查、范围扫描、向量混合搜索点查、范围扫描点查、范围扫描、过滤器全文检索、聚合、向量搜索写入优化LSM-Tree高吞吐写入LSM-Tree高吞吐写入LSM-Tree高吞吐写入Lucene 段合并写入吞吐相对较低场景侧重HTAP实时分析AI 数据平台OLTP 基础存储TiDB 的存储引擎海量数据存储随机读写全文搜索日志分析可观测性向量原生支持是核心特性否可通过外部方案否是通过插件非原生总结一下选型建议如果你的核心需求是“强事务关系型数据库”那么 TiDB基于 TiKV或传统 RDBMS 更合适。如果你的核心需求是“海量半结构化数据存储与随机访问”HBase 或其云托管版如 BigTable依然是非常成熟的选择。如果你的核心需求是“文本搜索与日志分析”Elasticsearch 的生态和工具链更完善。而如果你的场景是“需要同时处理高速写入、实时点查和复杂的向量/标量混合分析”特别是 AI 驱动的应用那么dingo-store所代表的融合架构就非常值得深入评估和尝试。它试图用一个系统解决多个问题虽然增加了系统的复杂性但也为架构简化带来了新的可能性。在技术选型时没有银弹关键在于认清自己业务当前和未来最核心的负载特征。