假设有人试图保存这样的API响应以供以后分析，即单个响应约有1000人
每个对象约有26个属性。例如，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}}
存储这类数据以供以后分析的最佳方法是什么?什么样的数据库?(越简单越好)
这些API调用的多个响应应该存储在单行中还是为每个对象创建多个列?或者其他方式，比如JSON dbs?
注意-该人可能随着时间的推移而改变，例如person100可能停止更新或变得不活跃....因此，未来的API响应可能不包括person100，而可能添加person1001的另一个记录(与person100无关)
附加信息:数据将在5年内每5分钟更新一次(以了解数据的使用/保留情况)。查询将主要限于personX如何在给定的时间范围内变化，范围可能从几个小时到超过6个月。一个人的属性可能具有相同/相似的属性概况，尽管它们的值会随着时间的推移而明显改变
最简单的方法可能是将每个API查询的结果保存在单个文件中，但如果这样做，可能最好使用JSONLines格式每人一行。然而，在任何一种情况下，我几乎肯定会添加一个'id'字段，以使查询特定的人变得非常容易，并在必要时将数据迁移到其他地方。越简单越好
上面的一种变体是每人一个文件，同样使用JSONLines格式，但增加了某种时间戳。
在复杂性的阶梯上，您可能想要考虑SQLite数据库。如果希望保留JSON格式，那么可能需要添加索引，例如个人id。
如果每个人的JSON对象表示是平面的，并且属性列表是稳定的，那么传统的做法是将数据存储为列格式。一个合理的折衷方案是将感兴趣的属性移到列中，并将所有其他(相关)详细信息降级到json值列中。
当然还有无数其他的数据库选择，你可以爬上复杂的阶梯。成本也是如此。对于初学者，您可能喜欢查看TimescaleDB。
管理规模如果一个人的数据不经常变化，那么就会有可能有多种方法来减少冗余。
在可能性范围的一端，你可以简单地放弃如果该人员先前保留的记录基本相同，则为整个记录。
对于频谱的另一端，您可以将数据重铸为a易于存储为表的一系列事件:
timestamp id propertyName value
这样做的好处是使您既灵活又灵活人的宇宙和感兴趣的属性集。
参见https://www.timescale.com/blog/time-series-compression-algorithms-explained/
脚注:PmWiki系统https://en.m.wikipedia.org/wiki/PmWiki说明了如何使用底层文件系统构建一个相当复杂的"数据库"系统。