1、x（文章）
size: 2.95Ti (5.90Ti)
docs: 2,632,935,747 (5,729,405,688)
2、y（用户）
size: 27.9Gi (55.8Gi)
docs: 52,068,639 (129,841,253)
一篇文章（weiboer_id）对应一个用户（uid），希望合并成一个 index，求思路，scheam没有嵌套，mapping 简单。就是index 数据量大。用 scroll api 去取文章索引（x）是不是太恐怖了
size: 2.95Ti (5.90Ti)
docs: 2,632,935,747 (5,729,405,688)
{
"_index": "x",
"_type": "x",
"_id": "3722291466461774",
"_version": 1,
"_score": 1,
"_source": {
"id_short": "B9lTYr70a",
"weiboer_id": "1682355561",
"content": "",
"content_full": "//@赶着毛驴去纽约:说的dei //@英国报姐 汤上面挺有启发的一段话，分享给大家。。",
"published_at": "2014-06-16T19:28:25.000Z",
"repost_count": 0,
"comment_count": 0,
"up_count": 0,
"repost_id": "3711586356700619",
"repost_level": 2,
"app_source": "iPad客户端",
"href": "/1682355561/B9lTYr70a?from=page_1005051682355561_profile&wvr=6&mod=weibotime",
"crawled_at": "2015-07-15T21:05:50.030Z",
"_id": "3722291466461774"
}
}2、y（用户）
size: 27.9Gi (55.8Gi)
docs: 52,068,639 (129,841,253)
{
"_index": "y",
"_type": "y",
"_id": "1739692683",
"_version": 2,
"_score": 1,
"_source": {
"username": null,
"name": "test",
"intro": "他还没有填写个人简介",
"gender": 0,
"vip": 0,
"verify": 0,
"fans_count": 11,
"follower_count": 0,
"weibo_count": 0,
"level": 1,
"last_weibo_at": "1970-01-01T00:00:00.000Z",
"info": "",
"location_str": "江苏 泰州",
"birthday_str": "1996年10月4日",
"sexual": "",
"relationship": "",
"email": "",
"tags": [ ],
"updated_at": "2015-05-22T15:00:10.915Z",
"sys_tags": [ ],
"uid": "1739692683"
}
}一篇文章（weiboer_id）对应一个用户（uid），希望合并成一个 index，求思路，scheam没有嵌套，mapping 简单。就是index 数据量大。用 scroll api 去取文章索引（x）是不是太恐怖了
4 个回复
kennywu76 - Wood
赞同来自: pqy
如果合并成一个扁平的索引，实现join一类的查询效率应该是最高的，但由于source比较大，在某些场景下可能就不是那么高效，比如只需要查询用户，或者微博内容（除非原索引也保留 ）。
如果在应用内部join两个索引的查询结果性能不是很成问题的话，建议保留现在2个索引的形式。
kennywu76 - Wood
赞同来自: pqy
logstash和reindex api都只能是对同一种类型的索引做处理，不具备对两种类型的数据按照主外健关系做join的功能， 这个合并的逻辑还是需要自己用scroll api写一下代码。
scroll调用会返回一个scroll id，标示一个开启的search context。 这个context类似于数据库的游标，用于记录搜索的结果集以及获取数据的进度。 只要这个context处于open状态，即使应用出问题了，只要在context过期时间内可以恢复好，就可以继续读取数据而不用从头再来。 所以在reindex期间，你可以将scroll open的状态设置得比较长，比如10分钟，同时简单的持久化一下scroll ID。 这样如果应用因为某种原因异常退出，重启后可以读取到scroll ID就可以从中断的地方继续开始处理。
要注意的一点是在scroll是做第一次search的时候对数据集做了一个snapshot，所以之后写入的数据是不会被读取的。 另外就是scroll的过期时间如果设置得很长，reindex完后记得手工删除一下scroll ID，防止后续的数据写入受到影响。
pqy
赞同来自:
这俩 index ，是在15台8核32g 1Tssd，es2.x的集群，合并后在 90台8核32g 1Tssd，es5.2.2的集群。如果能顺利合并，最大的索引也是这个合并后的索引，其他的很小（单个小于10g，不超过20个）可以忽略不计。我可以给这个合并后的索引 45主shards+1replica 吗，是否合适。
合并的方法，logstash-input-elasticsearch、还有 es 5.x reindex 能否做到，还有其他合适的办法吗，源数据都在es2.x的集群里面。
pqy
赞同来自: