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%）。对于您的 10 million 记录，这将以类似 140MB 的形式结束。这将为您带来以下优势：

• 硬盘节省。唯一的问题是，查看当前硬盘的价格，这几乎没有用。
• RAM 节省。 与硬盘相比，这对于索引很有用。在 indexes should fit in RAM to achieve a good performance 的 mongodb 个工作集中。因此，如果您在这两个字段上有索引，您不仅会保存 140MB 的 HDD space，还会保存 140MB 的潜在 RAM space（这实际上是值得注意的）。
• I/O。由于input/output系统的限制（磁盘reading/writing的速度受到限制），出现了很多瓶颈。对于您的文档，这意味着使用模式 2，您可能每 1 秒 read/write twice as many documents。
• 网络。在很多情况下，网络甚至比 IO 慢得多，如果您的数据库服务器在不同的机器上，那么您的应用程序服务器必须通过网络发送数据。而且您还可以发送两倍的数据。

说完优点，再说一个小按键的缺点：

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