Go: ElasticSearch 客户端学习

 关注
发布于: 2020 年 08 月 30 日
选择程序包来消费ElasticSearch是进行项目的第一步。 如果ElasticSearch是工作流的重要组成部分，则此选择可能会影响应用程序的性能。 但是，对于Go的选择很少：最著名的是olivere/elastic ，而官方的则是elastic/go-elasticsearch 。 让我们回顾一下每个程序包的优缺点。
﻿
设计两个程序包的设计截然不同，让我们通过一个query来观察它们的不同之处。
﻿
﻿
olivere/elastic 提供了完整的查询DSL，可以完全抽象真实的查询。 这是内置的查询：
﻿
﻿
这是官方包的内置查询方式：
﻿
﻿
这种查询更加详细明确。用Go中的map方式转化原始的json查询语句。
﻿
这两种设计都可以满足不同的开发者。不关心具体查询的开发者倾向于第一种，同时希望知道明确查询细节的更愿意选择第二种。现在让我们回顾下这两种方式的性能表现。
﻿
基准测试在样例中，我们构建一个简单结构来存储和索引查询。这是一个示例文档:
﻿
﻿
使用的查询是上一节介绍的查询。 基准测试将涵盖：
﻿
查询的建立
结果解码
﻿
这是结果：
olivere/elastic:
name           time/op
QuerySearch-4  4.14ms ± 5%
name           alloc/op
QuerySearch-4   160kB ± 1%
name           allocs/op
QuerySearch-4   1.65k ± 0%
 
official client:
name           time/op
QuerySearch-4  3.88ms ± 5%
name           alloc/op
QuerySearch-4   118kB ± 0%
name           allocs/op
QuerySearch-4     514 ± 0%
﻿
官方包更加高效分配的内存更少，给应用程序带来更好性能的同时也能降低gc的频率。
﻿
优化优化的第一步是分析。让我们在 olivere/elastic 基准测试中运行pprof。这里是内存分配对象top5的方法：
Showing top 5 nodes out of 47
flat%   sum%
29.83% 29.83%   reflect.New
29.43% 59.26%   encoding/json.(*decodeState).literalStore
8.41%  67.66%   encoding/json.(*decodeState).object
8.15%  75.82%   encoding/json.Unmarshal
5.61%  81.42%   encoding/json.(*RawMessage).UnmarshalJSON
﻿
encoding/json解码阶段占据了超过80%的分配。
﻿
﻿
第一个可行的优化方法是替换json解码器为easyjson
﻿
﻿
再次运行基准测试将稍微改善分配数量(-12%):
﻿
olivere/elastic:
name           old time/op    new time/op    delta
QuerySearch-4    4.14ms ± 5%    4.12ms ± 7%     ~
name           old alloc/op   new alloc/op   delta
QuerySearch-4     160kB ± 1%     158kB ± 1%   -1.57%
name           old allocs/op  new allocs/op  delta
QuerySearch-4     1.65k ± 0%     1.45k ± 0%  -12.15%
﻿
现在这部分已经优化了，我们可以再次运行pprof来看看是否还有更多低挂的水果。 pprof让我们使用以下命令删除已经检查过的路径：go tool pprof -alloc_objects  -hide =” decodeState | .UnmarshalJSON | Unmarshal | Decode”  mem.out：
﻿
﻿
现在查询的创建占据最多的分配。olivere/elastic提供了Source()方法允许直接以字符串的方式发送查询。这是优化后的结果：
﻿
name                    time/op
QuerySearch-4           4.12ms ± 5%
OptimizedQuerySearch-4  4.07ms ± 4%
name                    alloc/op
QuerySearch-4            158kB ± 1%
OptimizedQuerySearch-4   152kB ± 1%
name                    allocs/op
QuerySearch-4            1.45k ± 0%
OptimizedQuerySearch-4   1.35k ± 0%
﻿
至此我们可以通过优化得到一些改善，但仍然和官方包相较甚远。
﻿
编译自：https://medium.com/a-journey-with-go/go-elasticsearch-clients-study-case-dbaee1e02c7
博客地址：https://www.chenjie.info/2592
本文首发于我的公众号：
﻿