對於JVM應用程序，有沒有充分的理由使用Elasticsearch REST API？

Question

我正在使用Elasticsearch開發Java應用程序。

到目前為止，我已經使用了Java節點客戶端。 不久前，我從一些同事那里聽說，首選REST API，原因如下：

1. 能夠升級Elasticsearch而不會增加傳輸客戶端版本，即Java客戶端的版本取決於ES集群運行的版本
2. 節點/傳輸客戶端將在即將發布的版本中棄用嗎？
3. 安全

我現在正試圖找出這有多少。

關於＃1， Elasticsearch文檔指出 ，（通常）客戶端和ES集群具有相同的主要版本就足夠了。 因此，REST API並沒有真正提供更好的功能。

然后，＃3由Shield處理。

我找不到有關＃2的任何信息。

從上面的信息中，我可能想要在Java應用程序中使用REST API的唯一原因是版本獨立性，只是為了安全起見。 除此之外，不多； 這是真的嗎？ 節點/傳輸客戶端將被棄用，這是真的嗎？

Answer 1

我不是ES專家，但我們只是在問自己同樣的問題，以下是我們對該主題的看法。

1. ES客戶端版本與ES服務器版本：
   • 本機客戶端遵循您所說的規則：主要版本兼容性。 直到最近才出現這種情況，對於真正的特定功能（例如Percolator），情況並非如此（次要版本的重大更改），
   • 看起來Jest是目前最好的HTTP客戶端抽象，它具有相同的約束： 文檔說1.x版不適用於2.x版，
   • 最后的解決方案是使用低級別的HTTP客戶端，但會丟失流暢的Java抽象。 不能比較
   • 您不能使用基於本機客戶端的Java應用程序解決ES的混合版本（在具有1.x和2.x實例的異構環境的情況下）。 HTTP客戶端應該有可能，因此可以簡化一些漸進式遷移方案。
2. 本機客戶端棄用：
   • 尚無明確說明，但將為5.x版提供一個官方HTTP客戶端 。 這樣，擁有兩個客戶的意義何在？
3. 安全性：
   • 如果需要，可以使用某些中間件（例如Apache前端）或使用https://github.com/Asquera/elasticsearch-http-basic輕松設置基本的HTTP安全性，
   • Shield是官方的，可與本機和HTTP一起使用，但不是免費的……

在我們的應用程序中，我們正在使用Spring Data ES。 它非常易於使用，幾乎不需要幾行代碼，但是版本滯后（在ES 2發布后支持2.x 6個月），並且基於本機客戶端。 從我們的角度來看，權衡值得提高開發效率。

最后，SAAS只提供HTTP API，因此在這種情況下，您別無選擇。