我刚打酱油去了,不好意思

2个index合并

Elasticsearch | 作者 pqy | 发布于2017年04月06日 | 阅读数:4374

1、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)是不是太恐怖了 
 

 
已邀请:

kennywu76 - Wood^Trip.com

赞同来自: pqy

你这个场景,也只能是scroll api取文章索引,针对每个scroll的片段,查询用户信息,代码里合并好,再写入到新的索引。
 
如果合并成一个扁平的索引,实现join一类的查询效率应该是最高的,但由于source比较大,在某些场景下可能就不是那么高效,比如只需要查询用户,或者微博内容(除非原索引也保留 )。
 
如果在应用内部join两个索引的查询结果性能不是很成问题的话,建议保留现在2个索引的形式。
 
 

kennywu76 - Wood^Trip.com

赞同来自: pqy

45 primary , 1 replica可以。   
 
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

赞同来自:

感谢 @kennywu76 。我们还是需要合并成一个扁平的索引,原来的索引不保留 ,主要是考虑需要使用聚合计算比较容易。比如上面俩索引,求不同性别用户,文章发送量分别是多少,类似这样的。性别的维度在(用户索引),文章数据的count在(文章索引)。我还有2个问题
 
这俩 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的集群里面。
 
index and type in source can both be lists, 
allowing you to copy from lots of sources in one request.
This will copy documents from the tweet and post types in the twitter and blog index.
It’d include the post type in the twitter index and the tweet type in the blog index.
If you want to be more specific you’ll need to use the query.
It also makes no effort to handle ID collisions.
The target index will remain valid but it’s not easy to predict which document will survive because the iteration order isn’t well defined.

https://www.elastic.co/guide/e ... .html

POST _reindex
{
"source": {
"index": ["twitter", "blog"],
"type": ["tweet", "post"]
},
"dest": {
"index": "all_together"
}
}

 
 
 
 

pqy

赞同来自:

还有个疑问,scroll api 中间出问题了,不是只能重头再取吧 。还是有什么要注意的 @kennywu76

要回复问题请先登录注册