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记录的形式出现。这将为您带来以下优势：

• 节省硬盘空间。 唯一的问题是，从当前硬盘的价格来看，这几乎没有用。
• 节省内存。 与硬盘相比，这对于索引编制很有用。在mongodb中，索引的工作集应适合RAM，以实现良好的性能。因此，如果您在这两个字段上都有索引，则不仅可以节省140MBHDD空间，还可以节省140MB潜在的RAM空间（实际上很明显）。
• I / O 。由于输入/输出系统的限制，很多瓶颈都会发生（从磁盘读取/写入的速度受到限制）。对于您的文档，这意味着您可以使用模式2 twice as many documents每1秒读写一次。
• 网络 。在许多情况下，网络甚至比IO还要慢，并且，如果您的DB服务器位于不同的机器上，则您的应用程序服务器的数据必须通过有线方式发送。您还可以发送两倍的数据。

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

• 数据库的可读性。 当您db.coll.findOne()看到并看到时{_id: 1, t: 13423, a: 3, b:0.2}，很难理解这里到底存储了什么。
• 应用程序的可读性 与数据库相似，但是至少在这里您可以找到解决方案。随着映射逻辑，其转换currentDate到c和price到p你可以写一个干净的代码，并有一个短暂的架构。