ES的Java Rest client---jest

Elasticsearch的入门很是简单易学。

因为有丰富的原生的Restful API,建立索引，上传数据，搜索均可以在很短期内学会使用。官网上也有不少语言的client API与ES集群交互，有丰富的插件好比head,marvel等等。

那若是用ES这个开源项目作SAAS（software as a service)，好比搜索服务，是否能够直接用它原生的API呢？

jest是一款java Rest client，它支持SSL、proxy等等，而原生的transport client是TCP链接，用户认证受权要本身想办法实现，而且封装接口控制用户的操做。

从jest的文档中我找到了一部分答案：

ElasticSearch does not have Java rest client. It has only native client comes built in. That is the gap. You can add security layer to HTTP but native API. That is why none of SAAS offerings can be used with native api. -- Searchly

原生的API没有任何安全保护层，而对于HTTP来讲加一层安全认证是比较简单的。

jest client和原生的client的比较还有：

So if you have several ES clusters running different versions, then using the native (or transport) client will be a problem, and you will need to go HTTP (and Jest is the main option I think). If versioning is not an issue, the native client will be your best option as it is cluster aware (thus knows how to route your queries and does not need another hop), and also moves some computation away from your ES cluster (like merging search results that will be done locally instead of on the data node). -- Rotem Hermon

若是ES集群的版本不一样，用HTTP client会好些。若是版本不是问题，原生的client是最好的选择。由于它是culster-aware的，而且能够从ES集群分担一部分计算，好比合并搜索结果是在本地client执行的而不是data node。

There are several alternative clients available when working with ElasticSearch from Java, like Jest that provides a POJO marshalling mechanism on indexing and for the search results. In this example we are using the Client that is included in ElasticSearch. By default the client doesn't use the REST API but connects to the cluster as a normal node that just doesn't store any data. It knows about the state of the cluster and can route requests to the correct node but supposedly consumes more memory. For our application this doesn't make a huge difference but for production systems that's something to think about. -- Florian Hopf

原生的client像一个单纯的节点链接集群，它知道集群的状态和路由请求，这样会消耗多一些内存，在生产环境是值得考虑的影响。

 

开源的东西到底要不要常常用呢？感受初级开发人员仍是少用为好。