系统与数据库2021arxiv.org
每秒解析数 GB 的 JSON（simdjson）
Parsing gigabytes of JSON per second
进阶 · 约 60 分钟读完前置知识：SIMD 指令基础、C++ 编程、JSON 格式规范
导读
这篇论文研究如何以每秒解析数 GB JSON 的速度进行高性能 JSON 解析。其核心做法是 simdjson 项目，利用 SIMD 指令对 JSON 文本进行并行解析，在保持标准兼容的同时大幅超越传统解析器。
HN 关注点：JSON 是业界通用数据格式，解析速度常是大数据管道的瓶颈，HN 读者关注极致性能优化的实现思路，并由此争论 JSON 与二进制格式的取舍。
后来怎么样
simdjson 已成为事实上的高性能 JSON 解析标准，被多个主流系统（如 Node.js、ClickHouse 等）采用，并持续衍生后续优化研究。
HN 评论精选
这几条评论里：质疑 1 补充 2 亲历 1
质疑大数据场景下应放弃 JSON 改用统一的二进制格式
如果你的数据量大到需要这种高度优化的解析器，那可能已经享受不到 JSON 人类可读的好处了——而这正是它消耗 CPU 周期的根本原因。此时应该改用解析速度优化的等价二进制格式。JSON 唯一的理由是它是通用语，所以行业应该从上百种类 JSON 的二进制格式中挑出一个统一起来。
stkdump查看英文原文
If your dataset is large enough to benefit from such a hyperoptimized parser you might not benefit from the human readability anymore, which is the main reason for the required CPU cycles on the first place. So you should probably use a feature-equivalent binary format that is optimized for parsing speed. The only reason to use json then is that it is the lingua franca. So we as an industry should figure out which of the 100s of binary variants of json-similar formats has the same capabilities and unite around it.
亲历亲历：protobuf 技术上优秀但生态兼容性带来高昂业务成本，Avro 可能是更好折中
这个工作很棒。有人建议用二进制格式，对某些场景确实合适。我的公司每天采集 10-100TB 数据，采集端用 PROTOBUF，前后端协作非常顺畅。但数据要存入关系型和文档型数据库，还要流入数据湖供人阅读，这些都不支持 protobuf：要么自己写解析器（有些场景不可能），要么在入库前转成 JSON（由于 protobuf 一些字段表示方式的选择不佳，转换代价很高）。用 protoc 是合理的技术决策，却是糟糕的商业选择。或许用 Avro 更好：既保留 schema，又把 JSON 序列化的工作推回客户端。
throwawaygal7查看英文原文
This is pretty great. Some folks in the thread are suggesting using a binary format, and that's certainly a good idea for some. My business sells software that collects moderately sized (10-100TB/day) , and this data is collected as PROTOBUF. The format is great, and coordinating the backend and client side stuff with protobuf is bliss. However, we store the data in various relational and document databases. Neither of those use protobuf... Most importantly, it's business critical to be able to stream this data to data lakes where it can be read by humans. None of the options are going to support protocol buffers, you're either going to have to write a parser (impossible for some) or transform to JSON before ingest (fairly expensive due to some poor choices in how to represent various fields). It was a sound technical decision to use protoc , and a terrible choice for the business. I think it would have been much better to use avro, still benefit from schemas but push the work of marshaling JSON back to clients...
补充补充论文对应的开源项目链接
论文描述的项目是 https://simdjson.org/。
loloquwowndueo查看英文原文
The project described in the paper is https://simdjson.org/.
补充提出利用重复键模式进一步优化解析的思路
我认为还有'对象预测'优化的空间：真实场景中数组里 99% 的对象会反复出现相同的键，聪明的解析器可以利用这一点。
Ginden查看英文原文
I think there is some room for "object predictor" optimization. In real world cases, 99% of objects in array will have the same keys over and over. Smart parser can potentially exploit that.
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2021Hacker News 讨论帖139 分 · 79 评
同领域还值得读
I/O 比 CPU 更快——让我们划分资源并消除操作系统抽象
I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions
指出在现代服务器硬件上 I/O 速度已接近甚至超过 CPU，传统操作系统抽象反而成为瓶颈。
系统与数据库2019 · 817 分 · 277 评进阶 · 约 30 分钟编辑精选使用 io_uring 的高效 I/O
Efficient IO with io_uring
由 Linux 内核开发者 Jens Axboe 撰写，介绍 Linux 新的异步 I/O 接口 io_uring。
系统与数据库2019 · 426 分 · 96 评进阶 · 约 45 分钟编辑精选线程对大多数用途而言是个坏主意（1995）
Threads Are a Bad Idea for Most Purposes (1995)
这篇 1995 年的文章由 John Ousterhout 撰写，讨论为什么线程对大多数用途而言是坏主意，并主张事件驱动编程通常更简单、更高效。
系统与数据库2017 · 423 分 · 382 评进阶 · 约 25 分钟编辑精选学习型索引结构之论证
The Case for Learned Index Structures
提出把索引看作一种"模型"：既然 B-tree 等结构本质上是在学习数据的分布，就可以用机器学习模型（如回归模型、神经网络）来近似键到位置的映射，从而替代 B-tree、哈希索引…
系统与数据库2017 · 398 分 · 66 评 · 引用 25进阶 · 约 60 分钟编辑精选FoundationDB：一个分布式、解耦的事务型键值存储
FoundationDB: A distributed, unbundled, transactional key value store
介绍 FoundationDB：一个分布式、解耦设计的事务性键值存储。
系统与数据库2021 · 283 分 · 99 评进阶 · 约 90 分钟编辑精选