选择程序包来消费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