json - JSON文档数据库中的键成本(mongodb，elasticsearch)

Question

我想知道是否有人对诸如mongodb或elasticsearch之类的文档存储数据库中的JSON键大小具有速度或优化效果方面的经验。

例如:我有2个文档

doc1: { keeeeeey1: 'abc', keeeeeeey2: 'xyz')

doc2: { k1: 'abc', k2: 'xyz')

假设我有1000万条记录，那么以doc1格式存储数据意味着比在doc2中存储更多的db文件大小。

除此之外，在速度，RAM或任何其他优化方面是否会带来不利或负面影响？

Answer 1

您正确地注意到文档将具有不同的大小。因此，如果您决定采用第二种模式，则每个文档至少要保存15 bytes(类似文档为60%)。最终，您的140MB记录将以10 million之类的形式出现。这将为您带来以下优势:

HDD节省。 唯一的问题是，查看当前硬盘的价格几乎没有用。

节省内存。 与硬盘相比，这对于索引编制很有用。在mongodb的indexes should fit in RAM to achieve a good performance工作集中。因此，如果您在这两个字段上都有索引，则不仅可以保存HDD空间的140MB，还可以保存潜在RAM空间的140MB(实际上是值得注意的)。

I / O 。由于输入/输出系统的限制，很多瓶颈都会发生(从磁盘读取/写入的速度受到限制)。对于您的文档，这意味着您可以使用模式2每1秒读写一次twice as many documents。

网络。在许多情况下，网络甚至比IO还要慢，并且，如果您的DB服务器位于不同的计算机上，则您的应用程序服务器的数据必须通过电线发送。您还可以发送两倍的数据。

在介绍了优点之后，我必须告诉您使用小键的缺点:

数据库的可读性。 当您执行db.coll.findOne()并看到{_id: 1, t: 13423, a: 3, b:0.2}时，很难理解确切存储在此处的内容。

与应用程序的可读性与数据库相似，但至少在这里您可以找到解决方案。通过将currentDate转换为c和price转换为p的映射逻辑，您可以编写干净的代码并具有简短的模式。