Elasticsearch-很多小文件还是更少的大文件？

Question

我正在通过图像系统（类似于Google的反向图像搜索）来创建公司内部使用的编目系统的搜索。我们已经成功地将Elasticsearch用于常规搜索功能，因此我计划进行哈希处理我们所有的图像，为它们创建一个单独的索引，并将其用于搜索。系统中有很多项目，每个项目可能都有与其关联的多个图像，并且该项目应该能够通过反向图像搜索其任何相关图像来找到。

我们想到了2种可能的模式：

为每个图像制作一个文档，仅包含图像的哈希值和与之相关的项目ID。这将导致大约700万个文档，但是它们会很小，因为它们仅包含一个哈希和一个ID。

为每个项目制作一个文档，并将与之关联的所有图像的哈希存储在文档上的数组中。这将导致大约10万个文档，但是每个文档将相当大，某些项目具有与之关联的数百个图像。

这些模式中哪个更有效？

Answer 1

在参加了 Alexander Reelsen 最近的Under the Hood演讲后，他可能会说“这取决于情况”并“对其进行基准测试”。

正如@Science_Fiction 已经暗示的那样：

1. 图片经常更新吗？这可能会带来负面的成本因素
2. OTOH，700 万个文档的开销可能不应该被忽视，而在第二种情况下，它们只是not_analyzed字段中的术语。

如果 1. 是一个低因素，我可能会首先从你的第二种方法开始。