【13】把 Elasticsearch 当数据库使:Join
来自: https://segmentfault.com/a/1190000004468130
使用 https://github.com/taowen/es-monitor 可以用 SQL 进行 elasticsearch 的查询。要真正把Elasticsearch当作数据库来使,Join是一个绕不过的话题。关于Elasticsearch如何支持join,这个slide总结得很好: http://www.slideshare.net/sirensolutions/searching-relational-data-with-elasticsearch 。总体来说有这么几种方式:
-
完全不join,把关联表的字段融合到一张表里。当然这会造成数据的冗余
-
录入的时候join:使用 nested documents(nested document和主文档是同segment存储的,对于一个symbol,几千万个quote这样的场景就不适合了)
-
录入的时候join:使用 siren
-
查询时join:使用 parent/child (这个是elasticsearch的特性,要求parent/child同shard存在)
-
查询时join:使用 siren-joins(就是一个在服务端求值的filter,然后把结果发布给每个shard去做二次match)
-
查询时join:在客户端拼装第二个查询(和siren-joins差不多,但是多了一次客户端到服务器的来回)
-
查询时join:在coordinate节点上做两个查询的join合并( https://github.com/NLPchina/elasticsearch-sql )
我个人喜欢的是siren-joins和客户端拼装这两种方案。这两种方案都是先做了一次查询,把查询结果再次分发到每个分布式节点上再次去做分布式的聚合。相比在coordinate节点上去做join合并更scalable。
客户端求值
首先我来看如何在客户端完成结果集的求值
$ cat << EOF | python2.6 es_query.py http://127.0.0.1:9200 SELECT symbol FROM symbol WHERE sector='Finance' LIMIT 1000; SAVE RESULT AS finance_symbols; EOF
这里引入的 SAVE RESULT AS 就是用于触发前面的SQL的求值,并把结果集命名为 finance_symbols。如果因为一些中间结果我们不需要,我们也可以用REMOVE 命令把求值结果删除
$ cat << EOF | python2.6 es_query.py http://127.0.0.1:9200 SELECT symbol FROM symbol WHERE sector='Finance' LIMIT 1000; SAVE RESULT AS finance_symbols; REMOVE RESULT finance_symbols; EOF
甚至我们可以使用任意的python代码来修改result_map。
$ cat << EOF | python2.6 es_query.py http://127.0.0.1:9200 SELECT symbol FROM symbol WHERE sector='Finance' LIMIT 1000; SAVE RESULT AS finance_symbols; result_map['finance_symbols'] = result_map['finance_symbols'][1:-1]; EOF
客户端Join
在客户端求值的基础上,我们可以利用客户端保留的结果集来发第二个请求。
cat << EOF | python2.6 es_query.py http://127.0.0.1:9200 SELECT symbol FROM symbol WHERE sector='Finance' LIMIT 5; SAVE RESULT AS finance_symbols; SELECT MAX(adj_close) FROM quote JOIN finance_symbols ON quote.symbol = finance_symbols.symbol; REMOVE RESULT finance_symbols; EOF
这个产生的Elaticsearch请求是这样的两条:
{ "query": { "term": { "sector": "Finance" } }, "size": 5 }
然后根据其返回,产生了第二个请求
{ "query": { "bool": { "filter": [ {}, { "terms": { "symbol": [ "TFSC", "TFSCR", "TFSCU", "TFSCW", "PIH" ] } } ] } }, "aggs": { "MAX(adj_close)": { "max": { "field": "adj_close" } } }, "size": 0 }
可以看到,所谓客户端join,就是用前一次的查询结果拼出了第二次查询的条件(terms filter)。
服务端Join
有了 siren-join 插件( https://github.com/sirensolutions/siren-join ),我们可以在服务端完成同样的join操作
cat << EOF | python2.6 es_query.py http://127.0.0.1:9200 WITH SELECT symbol FROM symbol WHERE sector='Finance' LIMIT 5 AS finance_symbols; SELECT MAX(adj_close) FROM quote JOIN finance_symbols ON quote.symbol = finance_symbols.symbol; EOF
前面第一个查询是用SAVE RESULT AS求值并命名为finance_symbols,这里我们并没有求值而是给其取了一个名字(WITH AS),然后就可以引用了。
{ "query": { "bool": { "filter": [ {}, { "filterjoin": { "symbol": { "indices": "symbol*", "path": "symbol", "query": { "term": { "sector": "Finance" } } } } } ] } }, "aggs": { "MAX(adj_close)": { "max": { "field": "adj_close" } } }, "size": 0 }
可见产生的filterjoin把两步合为一步了。注意对于filterjoin查询,需要POST _coordinate_search 而不是_search这个URL。Profile
[ { "query": [ { "query_type": "BoostQuery", "lucene": "ConstantScore(BytesFieldDataTermsQuery::[size=8272])^0.0", "time": "29.32334300ms", "breakdown": { "score": 0, "create_weight": 360426, "next_doc": 137906, "match": 0, "build_scorer": 15027540, "advance": 0 }, "children": [ { "query_type": "BytesFieldDataTermsQuery", "lucene": "BytesFieldDataTermsQuery::[size=8272]", "time": "13.79747100ms", "breakdown": { "score": 0, "create_weight": 14903, "next_doc": 168010, "match": 0, "build_scorer": 13614558, "advance": 0 } } ] } ], "rewrite_time": 30804, "collector": [ { "name": "MultiCollector", "reason": "search_multi", "time": "1.529236000ms", "children": [ { "name": "TotalHitCountCollector", "reason": "search_count", "time": "0.08967800000ms" }, { "name": "MaxAggregator: [MAX(adj_close)]", "reason": "aggregation", "time": "0.1675550000ms" } ] } ] } ]
从profile的结果来看,其原理也是 terms filter(BytesFieldDataTermsQuery)。所以这也就决定了这种join只是伪join。真正的join不仅仅可以用第一个表去filter第二个表,而且要能够在第二个查询的计算阶段引用第一个阶段的结果。这个是仅仅用terms filter无法完成的。当然所有这些join的努力仅仅是让数据维护变得更加容易而已,如果我们真的要求Elasticsearch的join和传统SQL一样强大,那么我们也无法指望那么复杂的join可以快到哪里去,也就失去了使用Elasticsearch的意义了。有了上面两种Join方式,我们可以在极度快速和极度灵活之间获得一定的选择权利。