我有一个用例，如果可能的话，需要能够从延迟<1ms的某个存储中检索文档（~1.5kb）。商店里至少会有200万到300万份这样的文件。
示例文档
{"name": "NameOfTheItem", "city": "Seattle", "state": "WA", "postCode": "99332", "country": "USA"}访问模式
我所有的查找都将严格基于 name 现场。
我不需要高性能的写作
问题
对于这种大小的文档，在存储之前压缩文档，在检索时解压缩文档有意义吗？
对于这个大小的文档，数据格式（yaml、json、parquet等）重要吗？如果是的话，你有什么参考资料可以帮助我确定正确的格式吗？
对于商店，我有哪些选择可以帮助我实现sub-ms检索？
1条答案
按热度按时间xsuvu9jc1#
对于非常快的访问时间，您希望将数据保存在内存中，并将其保存在类似hashmap的数据结构中，以达到o（1）的读取复杂性。我刚刚计算了一下，我们讨论的总共是4-5gb的文档。一个合理的设置应该能够保存im内存。
不要考虑压缩。它只优化了存储大小，但降低了解压的访问时间成本。从计算结果（文档数x平均大小）可以看出，在没有压缩的情况下将所有内容保存在内存中应该不是问题。
我希望您也需要持久性，所以您应该将数据也存储在磁盘（例如数据库）和内存缓存中。