能否将DuckDB用作文档数据库？稀疏数据场景可行性问询

完全可以，你的场景和需求非常适配DuckDB的特性，即便它不是专门的文档数据库，也能很好满足你的使用要求。

为什么适配？ #

• DuckDB的列式存储天生适合处理稀疏数据：空值（比如book类型的duration、director列）不会占用实际存储空间，存储效率很高，这和你不同类型对象只填充部分属性的需求完美匹配。
• 你设计的表结构（type, title, author, duration, director, note, todo）刚好对应不同对象的属性，用关系表模拟文档/元组空间的思路完全可行。

实现建议 #

索引策略 #

不用给所有列都建索引，聚焦常用过滤列即可：

• 对type和author建联合B-tree索引，能大幅加速你示例中的type = "book" and author in [...]这类查询；
• 如果后续有按director过滤电影的需求，再给director单独建索引；
• 索引创建语句示例：

  CREATE INDEX idx_type_author ON objects(type, author);
  

数据导入 #

DuckDB支持直接批量导入JSON数据，非常适合你的对象格式：

• 把所有对象整理成JSON数组文件（比如objects.json），然后用以下语句导入：

  CREATE TABLE objects AS SELECT * FROM read_json_auto('objects.json');
  

• 1000万条数据的导入速度完全能接受，导入后自动识别列类型，也可以手动指定列类型保证准确性。

查询适配 #

你的示例查询直接用标准SQL就能执行，完全符合需求：

• 查询指定对象列表：

  SELECT * FROM objects WHERE type = 'book' AND author IN ('Taleb', 'Sun Tzu');
  

• 分组统计：

  SELECT type, count(*)
  FROM objects
  WHERE author IN ('Taleb', 'Sun Tzu')
  GROUP BY type;
  

DuckDB的OLAP优化对这类聚合查询有很好的支持，1000万条数据的统计查询速度不会慢。

性能预期 #

虽然DuckDB不是专门的文档数据库，但针对你的需求：

• 单表1000万条数据，配合合适的索引，等值过滤查询响应时间基本在毫秒级；
• 分组统计这类聚合查询，响应时间大多在秒级以内，完全满足你“性能足够即可”的要求。

内容的提问来源于stack exchange，提问作者Alex Craft