一尘不染

JSON文档数据库中的键成本(mongodb,elasticsearch)

elasticsearch

我希望有人对诸如mongodb或elasticsearch之类的文档存储数据库中的JSON密钥的大小具有速度或优化效果方面的经验。

因此,例如:我有2个文档

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

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

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

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


阅读 240

收藏
2020-06-22

共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},很难理解这里到底存储了什么。
  • 应用程序的可读性 与数据库相似,但是至少在这里您可以找到解决方案。随着映射逻辑,其转换currentDatecpricep你可以写一个干净的代码,并有一个短暂的架构。
2020-06-22