GuanceDB 3.1：从 Bloom 过滤走向全字段倒排，重塑千亿级可观测性数据秒级查询体验

可观测性查询面对的从来不只是日志。指标、日志、链路、RUM、事件，以及持续增长的资源与业务属性，共同构成了一个需要被统一检索的数据面。一次真实的故障排查，往往同时包含服务、环境、地域、状态、追踪标识和文本条件，还要排除已知噪声。当数据量进入千亿级，查询能否秒回，取决于这些条件能否尽早收敛成可组合、可运算的行集合——而不是一堆"可能命中"的数据块。 GuanceDB 3.1 把倒排与全文检索完整地落到了可观测性数据的查询路径上。这里说的"全字段"，是指不同数据类型中的任意字段都具备建立倒排或全文索引的能力——而非默认无差别地全部建索引；用户可以按照字段类型和查询习惯自主选择策略，把每一份索引成本都花在查询收益最高的地方。 Bloom 过滤器有价值，但它不是完整的检索路径 Bloom 过滤器是轻量的概率型集合判断结构。写入一个值时，系统通过多个哈希函数把位数组中的若干位置设为 1；查询时，只要其中一位为 0，就能确定该值不存在。如果所有位置都是 1，只能得到"可能存在"的结论。只要索引构建、分词和查询规则保持一致，Bloom 不会产生假阴性，因此很适合先排除不可能命中的数据块。 它的代价优势来自"不保存行号"。但这也决定了 Bloom 只能回答成员关系，不能告诉查询引擎值出现在哪一条记录。其理论误报率近似为： p ≈ (1 - e^(-k·n/m))^k 其中 m 是位数组大小，n 是写入的值或词项数量，k 是哈希函数数量。固定空间下，字段基数、词项数或 n-gram 数量不断增加，更多位会被置为 1，过滤器趋于饱和，误报率随之上升。降低误报需要更大的位数组或重新选择哈希次数，这会增加索引空间、构建 CPU 和读取成本。因此，Bloom 的粒度、容量、分词方式和目标误报率必须与真实数据分布共同设计。 这里其实存在两层"误命中"。第一层来自哈希碰撞：值并不存在，但对应位恰好都被其他值置为 1。第二层来自块级共现：即使 Bloom 完全没有哈希误报，多个查询值只要分别存在于同一个块的不同记录中，这个块仍然无法被跳过。对于多条件低命中查询，第二层往往更加关键。 设查询条件为： service=checkout AND env=prod AND region=sg AND status!=ok 若这些值分别出现在同一个数据块，块级过滤器可以分别回答"可能存在"，却无法证明它们在同一条观测记录上同时成立。即使最终一条结果都没有，执行引擎仍可能读取候选块、解码相关列并逐行判断。数据块越大、字段越多、条件越分散，候选块与真实命中记录之间的差距就越明显。 不同布尔条件下，这种差异会进一步放大： 对 AND，Bloom 只有在至少一个条件确定不存在时才能跳过数据块；各条件分别存在但没有行级交集时，仍需后置扫描。对 OR，只要任一条件可能存在就必须保留数据块，条件越多，能够被整体排除的块通常越少。对 NOT、!=、NOT IN，知道"被排除值可能存在"并不能判断哪些行应当保留。若缺少强正向条件限定候选集，查询仍可能接近全量读取。对短语和邻近搜索，基于 token 或 n-gram 的 Bloom 只记录"这些片段可能出现"，不保存词项所在记录及位置，通常仍需读取原文做精确确认。 因此，Bloom 的误报只影响效率，不会造成错误结果，最终结果仍由精确阶段确认。它是有效的块级跳过结构，但不是完整的行级检索路径。 需要说明的是，这并不是"开源产品不好"，而是 Bloom 类方案共同面对的执行粒度上限。以可观测性中的日志子场景为例：Loki 官方文档将 Bloom 查询加速标注为实验性能力，要求使用结构化元数据；可加速的过滤主要是字符串等值、有限的与/或和可简化正则，且必须出现在解析步骤之前——放在解析之后就不会加速，详见文末官方资料。 VictoriaLogs FAQ 说明，它按字段保存数据块，用过滤器跳过不含指定词或短语的块，并维护时间稀疏索引。该机制擅长排除明显无关的数据块；从块级执行粒度推断，在低命中、多条件和负查询中仍可能留下较大候选范围。 同一查询、同一数据块、同一组记录，差异来自索引能提供的定位粒度。示意中的 r101—r104 是同一个数据块 B17 的具体记录，只用于说明执行粒度，不代表任何性能基准。Bloom 误报只带来额外读取，不会改变精确结果；倒排也仍受高频词、纯负查询和大返回量的边界约束。 GuanceDB 3.1：让复杂条件直接落到行集合 GuanceDB 3.1 为指标标签、资源属性、链路属性、RUM 维度、事件字段等结构化数据提供倒排，为日志正文、错误信息等长文本提供分词全文索引。倒排索引先维护字段值或词项字典，再为每个词项记录对应的行号集合。工程实现通常会对递增行号做差分编码，或根据密度选择压缩数组、位图等表示，使 posting list 可以按段存储和合并。 查询时，执行器不必先读取字段正文，而是先读取各条件的 posting list。AND 可以从最短列表开始，通过有序归并、跳跃指针或位图运算不断收窄；OR 直接合并候选；NOT 则在时间、租户或其他正向条件已经限定的记录集合上做差。若全文索引保存词频或位置信息，还可以在索引层完成短语、邻近和相关性判断，而不只是确认词项曾在某个数据块出现。 关键变化不是"索引更多"，而是从块级"可能命中"提升为行级"候选定位"。对上述组合条件，执行器可优先处理选择性最高的条件，再与其他列表求交；交集为空时，可在读取完整记录前结束。只有真正入选的行才进入列读取、反序列化和结果组装路径。 高、低选择性查询可以采用不同候选路径。稀有错误码、追踪标识等条件产生短行号表，快速缩小范围；常见级别或地域对应的 posting list 较长，但仍可与时间、租户、服务等更强条件求交。需要说明的是，倒排也不是无条件的固定延迟方案：高频词会形成很长的 posting list，纯负查询需要一个明确的候选全集，返回量很大时仍受网络与序列化限制。GuanceDB 3.1 的优势是让执行器拥有行级集合和选择顺序，而不是消除所有查询成本。 把索引成本放到正确的资源池 全字段可索引不代表写入节点要同步承担全部计算。GuanceDB 3.1 将写入、查询和任务/compaction 节点分离，数据以对象存储持久化；索引生成、段合并与压缩由独立节点完成。 索引或合并任务出现峰值时，可在云上临时扩展资源，完成后释放实例，在线容量不必按后台峰值配置。写入池可以根据实时吞吐和队列深度扩缩，compaction 池可以根据待处理分区、段数或字节量从零扩展到多个任务节点。对象存储承接数据和索引段，让计算与存储分别扩展。全字段索引的计算成本因而可控，查询仍获得行级定位。 这种任务边界也更适合利用 AWS Spot 等可中断算力：写入弹性层在持久队列、幂等提交和重试机制保护下承接突发流量；compaction 通过任务租约、checkpoint 和失败重排安全地使用 Spot，实例被回收后可由其他节点继续。查询池则按交互式 SLA 保留更稳定的容量。成本由实际写入量和待合并数据量驱动，而不是为三类工作负载的叠加峰值长期保留整组机器。 索引建立的节奏也可按查询收益安排：高频资源属性和业务维度优