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像一個單純的節點鏈接集羣，它知道集羣的狀態和路由請求，這樣會消耗多一些內存，在生產環境是值得考慮的影響。

 

開源的東西到底要不要常常用呢？感受初級開發人員仍是少用爲好。