Logfire 用动态 shredding 实现千倍查询加速
Shredding JSON columns gave Logfire up to 1000x faster queries
在 Logfire 中，查询半结构化数据曾面临巨大挑战，尤其是当数据存储在 JSON 列中时。过去，我们依赖 Jiter 进行快速 JSON 解析，但无法避免大量的 IO 开销和解析成本。为此，我们引入了动态 shredding 技术，自动将高频访问的属性提取为强类型列。这一优化让原本需要 30 秒超时的查询，现在能在 1 秒内完成，性能提升高达 1000 倍。无需手动配置，系统会在数据摄入和压缩过程中自动完成列拆分，既保留了逻辑上的 JSON 视图，又在物理层面实现了列式存储的高效性。
看到 <customer_attribute> 的查询速度大幅提升！现在感觉几乎是瞬间完成。
HN 评论区
17- sgarland
当公司表现得好像他们发现了一个过去十年（甚至更久）所有数据库从业者都熟知的重大突破时，我觉得简直太好笑了。
JSON 慢得要命，无论是序列化/反序列化，尤其是查询。能不用就不用，非用不可也得省着点。规范化其实没那么难，现在有了 LLM 更是 trivial。告诉 Claude 你希望你的 schema 是 BCNF，如果你兴致来了甚至可以是 5NF。只有当你遇到性能问题时，才考虑反规范化。
- galkk
用更好的数据库？了解一下前人成果？
Dremel 论文早在 2010 年左右就解释了 shredding 的概念？Parquet 也早就有了？
https://blog.x.com/engineering/en_us/a/2013/dremel-made-simp...
是的，嵌套重复字段（或 struct）确实会让你头疼。几年前我玩 DuckDB 查询 Parquet 时，就遇到过列名相关的问题，甚至还得去挖源码来优化统计信息的使用，但那是可行的，在我的数据集上效率也还算合理。
不过话说回来，如果你有大型公司的资源，无论是算力还是人力，你确实能在数据上做出很酷的东西。所有那些基于真实查询统计来决定“哪些值得 shredding”、数据压缩、定期优化以及通过维护任务改进静态数据的工作……再次强调，用更好的数据库/引擎，天下没有免费的午餐，你付多少钱就得到多少回报（希望如此）。
- japgolly
> 而不是将所有属性存储在单个 JSON 列中，我们自动提取访问最频繁的属性到单独的、强类型的列中。
我很高兴他们“发现”了这一点，但这可是数据库 101 的基础知识。