存储多JSON格式人员数据用于分析的最优方案及选型问询

问题背景 #

假设需存储API返回的人员数据用于后续分析：单次API响应包含约1000个人员对象，每个对象含26个属性（propertyA至propertyZ），API每5分钟调用一次，数据结构如下：

{
  "person1": {"propertyA":"a1", "propertyB":"b1", ....... "propertyZ":"z1"},
  "person2": {"propertyA":"a2", "propertyB":"b2", ....... "propertyZ":"z2"},
  ....
  "person999": {"propertyA":"a999", "propertyB":"b999", ....... "propertyZ":"z999"},
  "person1000": {"propertyA":"a1000", "propertyB":"b1000", ....... "propertyZ":"z1000"}
}

补充说明：人员对象会随时间变化，例如person100可能停止更新或变为非活跃状态，后续API响应可能不再包含person100，转而新增person1001（与person100的非活跃状态无关）。
附加信息：数据每5分钟更新一次，需保留5年；查询需求主要为分析某一人员（如personX）在数小时至6个月时间范围内的属性变化；人员对象的属性结构基本一致，但属性值会随时间变化。

需解答的问题 #

1. 此类数据用于分析的最优存储方式是什么？应选用哪种数据库（越简单越好）？
2. 多次API响应的数据应存储为单行、为每个对象设多列，还是采用JSON数据库等其他方式？

方案建议 #

问题1：最优存储方式与推荐数据库 #

这类数据属于时序化的实体状态快照数据，最优存储方式是采用时序宽表存储，推荐使用SQLite（最简单），如果后续有扩展需求可以升级到PostgreSQL。

• 选择理由：
  • SQLite是轻量文件型数据库，无需部署额外服务，上手成本极低。按数据量计算：每5分钟1000条快照，5年约5256万条，每条按1KB估算仅占约5GB，完全在SQLite的承载范围内。
  • 结构化存储天然适配“按人员ID+时间范围查询属性变化”的核心需求，查询效率高且分析逻辑直观。
  • 若后续需要更高并发或复杂分析，PostgreSQL的JSONB类型可兼容属性结构的微小变动，同时支持时序查询优化。

问题2：数据存储结构选择 #

绝对不建议单行存储多次响应或为每个对象设多列，最优方案是将每个人员的每次API快照存储为单独一行，表结构设计示例：

• 排除其他方案的原因：

  • 单行存储多次响应：会导致单条数据无限膨胀，查询时需解析大字段，性能极差，完全不符合时序分析需求。
  • 为每个对象设多列：人员动态新增会导致表结构频繁变更，维护成本极高，且无法高效筛选特定人员的历史数据。
  • JSON数据库（如MongoDB）：虽然支持嵌套结构，但针对“人员+时间范围”的查询需求，结构化表的查询效率、分析便利性远高于JSON存储，且SQLite/PostgreSQL的使用门槛更低，更贴合“越简单越好”的要求。

• 额外优化：给person_id和snapshot_time建立联合索引，可大幅提升按人员查询历史快照的速度。

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