1年半前、node.jsのElasticSearchのクライアントを選択する問題に遭遇しました。 その後、いくつかのプロジェクトがありましたが、すべてが複雑すぎるか、とにかく書かれていました。 どうやら：必要なのは、JSON.encode / decode、エラー処理、およびいくつかのヘルパーを使用したhttpリクエストのラッパーです。 次に、ノードについて、私はすぐに小さな
モジュールを作成しました 。これは非常に便利であることがわかりました。
最近、レール上のアプリケーションにESを固定する必要がありました。 Rubyのクライアントの中には、長い間サポートされていないものもあれば、複雑すぎるものもあります。 ただし、多くのクライアントにはエイリアス管理メカニズムがありませんが、これはESにとって非常に重要な機能です。
node.jsのモジュールを基本とし、その機能を拡張して、開発、展開、および管理に最も必要なすべてのツールがあるように、最小限のgemを作成することにしました。 これが何が起こったのかです。
最小限のAPI
ESには優れたドキュメントがあり、一部のメソッドには多くの設定があります。 Elasticsには、考えられるすべてのメソッドのヘルパーはありません。 メインのメソッドは
Client#request 。これにより、任意のリクエストを実行できます。 httpメソッドといくつかの簡単なリクエストのヘルパーがあります。 このアプローチでは、エラスティックが新/旧バージョンの機能をサポートしないという状況は決してありません。
リクエスト用のDSLもありません。 私の意見では、それは開発を妨害し、遅らせるだけです（ドキュメントの読み取り、ソースコード、サンプルドキュメントのリクエストをESドキュメントから新しいDSLに変換する必要性）。
ActiveRecord統合
アプリケーションごとのインデックス/モデルごとのインデックスおよびCRUDメソッドを選択する機能を備えています。 他のORMのサポートは簡単に追加できます。
ダウンタイムなしでインデックスとマッピングを管理する
Elasticsはエイリアス設定をESに保存するため、サードパーティのストレージは必要ありません。 競合する移行の場合、新しいインデックスを作成し、それと連携するアプリケーションを実行し、そこにデータをロードしてから、エイリアスを更新できます（このためのタスクがあります）。 異なるインデックスは決して接続されていません。エイリアスを1つだけ更新する必要がある場合、残りのインデックスは再インデックスできません。
熊手とカピストラーノ・タスキー
移行およびインデックス作成モデル用。
テスト用の自動更新モード
このモードでは、各状態変更リクエストの後に、同じインデックスでリフレッシュリクエストが実行されます。
エラスティックは、レールの有無にかかわらず機能します。 コード、例、およびより詳細な説明は
githubにあります。