应用级别的Join操作

我们可以在应用这一层面（部分的）模仿实现关系数据库中的join操作。例如，我们要给 users 以及每个 user 所对应的若干篇 blog 建立索引。在这充满关系的世界中，我们可以做一些类似于这样的事情：

PUT /my_index/user/1     (1)
{
  "name":     "John Smith",
  "email":    "john@smith.com",
  "dob":      "1970/10/24"
}

PUT /my_index/blogpost/2 (1)
{
  "title":    "Relationships",
  "body":     "It's complicated...",
  "user":     1          (2)
}
copy

(1) 每一个 document 中 index，type，和 id 共同组成了主键。

(2) blogpost 通过包含 user 的 id 来关联 user，而这里不需要指定 user 的 index 和 type 是因为在我们的应用中它们是被硬编码的（这里的硬编码的意思应该是说，在 blogpost document中引用了 user ，那么es就会在相同的index下查找 user type，并且id为1的document，所以不需要指定 index 和 type）。

通过查询 user 的ID为1将很容易找到相应的 blog：

GET /my_index/blogpost/_search
{
  "query": {
    "filtered": {
      "filter": {
        "term": { "user": 1 }
      }
    }
  }
}
copy

想通过博客作者的名字 John 来找到相关的博客，我们需要执行2个查询语句： 第一，我们需要先找到所有叫 John 的博客作者，从而获得它们的 ID列表， 第二，将获取到的ID列表作为查询条件来执行类似于上面的查询语句：

GET /my_index/user/_search
{
  "query": {
    "match": {
      "name": "John"
    }
  }
}

GET /my_index/blogpost/_search
{
  "query": {
    "filtered": {
      "filter": {
        "terms": { "user": [1] }  (1)
      }
    }
  }
}
copy

(1) 其中 terms 的值被设置成从第一个查询中得到的ID列表。

在应用级别模仿join操作的最大好处是数据是立体的（normalized），如果想改变 user 的姓名，那么只要在 user 这个 document 上改就可以了。而缺点是你必须在查询期间运行额外的 query 来实现 join 的操作。

在这个例子当中，只有一个 user 符合我们的第一个查询条件，但在真实的世界中，很可能会出现数百万人的名字叫 John，将这么多的ID塞到第二个查询中，将会让这个查询语句变得非常庞大，并且这个查询会执行数百万次 term 的查找。

这种模仿join操作的方法适合于前置查询结果集（在该例子中指代 user）比较小，并且最好是不经常变化的，此时我们在应用中可以去缓存这部分数据，避免频繁的执行第一个查询。