DuckDB 全文搜索 vs PostgreSQL FTS vs Meilisearch：1 亿文档索引 — 构建时间、查询延迟、内存
发布: (2026年5月1日 GMT+8 09:20)
4 分钟阅读
原文: Dev.to
Source: Dev.to
测试设置：真实工作负载，真实硬件
- 语料库: 1亿条 Reddit 评论（约 50 GB 原始文本，14.8 GB 压缩 Parquet）
- 服务器: Hetzner AX‑52（AMD Ryzen 7 7700，64 GB RAM，2 × 1 TB NVMe）
- 查询: 来自生产搜索日志，覆盖四类：简单匹配、多词短语、模糊匹配和布尔查询。
- 版本: DuckDB 1.1，PostgreSQL 17.4，Meilisearch 1.10 —— 每个都经过性能调优。
关键发现 1：索引构建时间 — DuckDB 的惊喜
- DuckDB: 38 分钟（比 PostgreSQL 快 2.4 倍）
- PostgreSQL: 91 分钟
- Meilisearch: 44 分钟
DuckDB 的优势来自列式 I/O 和流水线式分词——它只读取 Parquet 中的索引列（body），避免不必要的数据移动。PostgreSQL 必须先将行写入堆页再构建 GIN 索引，导致 I/O 开销翻倍。
Meilisearch 虽然快速，但在索引期间最高占用 29 GB RAM，这对小规模部署可能是个瓶颈。得益于 GIN 索引，PostgreSQL 在增量更新方面表现出色（1 百万新文档仅需 14 秒），而 DuckDB 的列式架构使得部分更新比完整重建更便宜。
关键发现 2：查询延迟 — 专业化很重要
| 工作负载 | 引擎 | P50 延迟 | P99 延迟 |
|---|---|---|---|
| 简单布尔 AND | PostgreSQL GIN | 4 ms | — |
| 模糊 / 分析型（例如 Levenshtein） | DuckDB | ~1 ms（≈比 PostgreSQL 快 4 倍） | — |
| 拼写容错排名 | Meilisearch | — | 800 ms+ |
- PostgreSQL 成熟的查询规划器在简单布尔查询上表现出色。
- DuckDB 在模糊和分析查询上占优势，利用快速的列式扫描和聚合——非常适合“搜索即分析原语”。
- Meilisearch 提供最佳的拼写容错排名，但在大规模时表现欠佳，可能是因为其单分片设计。
关键发现 3：资源效率 — DuckDB 的磁盘优势
- DuckDB 索引: 大约比 Meilisearch 小 3 倍，得益于压缩列式存储。
- PostgreSQL GIN 索引: 大于 DuckDB 的，但比 Meilisearch 的更紧凑。
对于磁盘受限的环境，DuckDB 更小的占用可能决定成败。
结论：没有通用的胜者
| 偏好 | 推荐引擎 |
|---|---|
| 与 OLTP 集成的搜索，具备快速布尔查询和增量更新 | PostgreSQL |
| 快速分析查询，低磁盘使用，批量索引 | DuckDB |
| 强大的拼写容错和开发者体验（小规模语料或水平扩展） | Meilisearch |
阅读完整文章请访问 novvista.com 以获取包含更多示例和基准的完整分析。
最初发表于 NovVista.