百万级多列范围查询数据库架构选型咨询

Elasticsearch #

• 适配性极强的选项：
  • 原生擅长数值范围查询，多字段AND组合查询在100万数据量级下性能完全够用，无需复杂额外优化。
  • 字段增删超级便捷，不用执行DDL修改表结构，直接写入带新字段的数据，ES会自动识别并更新映射。
  • 支持runtime字段，可直接基于现有字段计算值并用于查询；若不想实时计算，也能用预处理管道提前存储计算结果，灵活度拉满。
• 短板：
  • 事务支持较弱，若业务对数据一致性要求极高（如涉及资金、核心业务数据的强事务场景），这会是硬伤。
  • 存储成本高于SQL，因为ES的倒排索引+列式存储组合会占用更多磁盘空间。

NoSQL（以MongoDB为代表） #

• 能满足需求，但并非最优选择：
  • 文档结构天然支持灵活增删字段，无需修改表结构，适配需求5没问题。
  • 支持数值范围和多字段AND查询，创建复合索引即可优化性能。
  • 可通过聚合管道实现计算字段的查询。
• 劣势：
  • 你的数据是全结构化且每个字段都有值，文档型存储会存在字段名重复存储的额外开销，空间利用率不如SQL或ES。
  • 复杂计算字段的查询性能，比不上ES的runtime字段或者SQL的计算列。

SQL数据库 #

• 完全适配所有需求，技术栈成熟可靠：
  • 数值范围、多字段AND查询都是SQL的基础操作，只要给常用查询字段建立单索引或复合索引，100万数据的查询速度完全有保障。
  • 计算字段查询可通过**生成列（计算列）**解决：虚拟生成列在查询时实时计算，存储生成列提前保存结果，两种方式都能满足需求，性能稳定。
  • 字段增删的便捷性：别被老印象束缚，现在主流SQL数据库（MySQL 8.0+、PostgreSQL）的在线DDL已非常成熟，大部分增删字段操作几乎不会锁表，完全符合“便捷”要求。
• 关于传统多列存储：
  必须采用。你的数据是全结构化且每条记录所有字段都有值，传统多列存储（每个字段对应一列的常规表结构）是最适配的：
  • 空间利用率最高，没有文档型存储的字段名冗余开销。
  • 索引创建、查询优化更直观，数据库优化器对这种结构的处理最成熟，性能可控。
  • 计算列、事务、备份恢复等特性都能完美发挥作用。

最终选型结论 #

• 若你有强事务需求，或团队已熟悉SQL技术栈，优先选择SQL数据库，采用传统多列存储即可，配合计算列和合适的索引，所有需求都能搞定。
• 要是更看重字段灵活性和复杂多字段范围查询的性能，且无强事务要求，Elasticsearch是更省心的选择。
• NoSQL适合非结构化/半结构化数据占比高的场景，你的数据是全结构化且全字段有值，并非最优选项。

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