elasticsearch - 如何为Elasticsearch索引此数据

Question

我本质上是在尝试模仿ES中的联接，并且我知道这不是ES的好用例，但是与此同时，我要完成的工作对于搜索功能而言似乎并不寻常。我已经阅读了ES文档，博客文章，绘制的图，并且当然在本地测试了不同的场景，但是我仍然很难理解如何为ES索引数据。这是我的第一个ES项目，也是我第一次与noSQL环境互动。

想象一下一个社交食谱网站(为简单起见)...

用户可以发布原始食谱。其他用户可以“喜欢”(一次)，“保存到”(多次保存到不同类别)和“烹饪”(可以多次烹饪一个食谱)食谱。

用户可以搜索食谱，并在不同的简单标记上进行过滤，例如“食谱已至少烹饪一次”，以及他们是否喜欢，保存和/或烹饪了食谱。此外，当您查看用户的个人资料时，您可以搜索他们喜欢，保存和烹饪的食谱。以及用户创建的食谱。

当前的设置有效，但似乎无法扩展，它是用其各种Yes / No标志以及一个Liked_by_users，Saved_by_users和Cooked_by_users的一个字段来索引配方的。这些字段包含已对配方采取任何这些操作的user_id数组。然后，当我要过滤时，我传递了user_id(或者，如果要查看您的任何 friend 做过的事情，则为user_ids)，并过滤ID是否显示在相关数组中的结果。但是，如果最终可以有数百万个这样的交互，那么用这种方式存储和搜索似乎并不好。我还可以将配方ID存储在用户上，但最后，看来我将遇到类似的问题，而且麻烦的是需要先从用户查询这些ID。

我一直在尝试和/或思考的问题:

对所有内容进行非规范化。我认为这是首选的ES方式，但是我担心这只是太多重复的数据(可以搜索配方标题，内容，类别等)，并且其中某些数据经常更改。例如，如果用户喜欢某个食谱，则该食谱的“喜欢”计数将更新，以便可以按“喜欢”计数对结果进行排序。

我相信这将需要为曾经与之交互的所有用户创建食谱的副本，然后将交互存储在该副本中。因此，有一个标记为“喜欢”，一个数据数组用于保存类别，以及一个数据数组以用于烹饪时间。我相信我仍然需要传递一个user_id数组来过滤某个人是否过滤了他们 friend 煮过的任何东西，但是我认为Users不会有数百万个 friend ，可能少于200个。是否仍然如此要传递许多ID？是否保存了太多数据？同样，有些字段可能会经常更新，这使声音听起来更加糟糕。

用户下的嵌套配方听起来也不正确，因为在更新任何其他内容时都需要重新索引所有内容。

在文档中，“父级/子级”听起来像是不得已而为之，并且在此用例中听起来也不太安静。

我已经考虑过要从mySQL中提取要过滤的ID(即用户与之交互的配方ID)并将其传递给ES。但是，一个，mySQL只能连接这么多的id(同样，如果对mySQL来说太长，则不确定将它们构建为代码中的字符串是否明智)，第二，我不确定这是否是一个过滤ES结果的有效方法(数据过多)。

我已经尝试了其他一些事情，例如分别索引用户和食谱之间的关系，但是一切似乎都归结为疯狂的小镇。

我也不知道ES太多了。阅读文档时，提到“如果您有很多XYZ，这不是一个好主意”，但我不知道在这种情况下，这意味着什么。我读过的唯一具体部分是有关更新非规范化博客文章中用户的名称的信息，而更新“几千”将花费不到一秒钟的时间。我有什么经验法则可以用来估算存储在字段中的数据，传递给过滤器的数据或要更新的文档之类的东西的大小？

Answer 1

在Elasticsearch上实现此过程非常棘手，因为实体(用户，配方，类别等)以各种方式链接在一起，并且在没有竞争条件的情况下以高吞吐量更新此数据并非易事。

用户之间共享类别吗？我的意思是，将食谱保存到类别(如标签)后，此信息对所有人都可见吗？如果是这样，此结构应该可以帮助您入门。

听起来您应该有两种类型的文档:食谱和烹饪操作/用户/食谱。

配方结构:

{
  "_id": "rga9gia0934gau90" (could be auto-generated by ES)
  "created_by": 123         (user id)
  "contents": "Pour x grams of sugar..."
  "ingredients": ["sugar", "..."],
  "tags": ["unhealthy", "sweet", "..."]
}

烹饪日期结构:

{
  "_id": "123-rga9gia0934gau90" (generated as {user_id}-{recipe-id})
  "user_id": 123,
  "recipe_id": "rga9gia0934gau90",
  "cooked_at_dates": ["2017-01-02", "2017-01-07"],
  "cooked_n_times": 2
}

这样，大多数更新都是单个文档的本地更新。但是，某些查询(例如“用户X尚未烹饪的甜菜谱”)需要两个ES查询:首先要获取用户已煮过的所有菜谱的菜谱ID，第二个查询是要查找没有任何甜菜谱的所有甜菜谱列出的ID。这不会扩展到成千上万的食谱，但应该可以用于成百上千的食谱。