Riverが非推奨に（日本語訳）

Riverを追加した、Elasticsearchを始めたばかりの頃には、このアイデアは革新的でした。ユーザがElasticsearchを使って、Elasticsearchで検索できるようにするためにデータを入れることが最初の仕事の一つです。なので、Elasticsearchに自動的にデータを取得する直接インストールできるプラグインをコミュニティの人たちが作成できるようにしました。

最初のいくつかのRiverの実装は良くできていて非常に有用でした。 CouchDB Riverは非常にシンプルで人気がありました。（CouchDBのAPIを変更してくれてありがとう！）その他に人気のあるものは例えばRabbitMQでした。それらはゆっくりとですが、Riverの問題を顕在化させ始めました。

我々が発見した問題はどんなものでしょう？それはクラスタの安定性です。それらの性質なのですが、Riverは外部システムと連携しており、それらの外部システムは外部のライブラリを必要とします。それら自体はとても有用なのですが、それらによってオーバーヘッドがあります。オーバーヘッドがその一部として組み込まれるということは、より多くのメモリ、ソケット、ファイルデスクリプタなどを使用するということです。また、バグもです。

ここ数年の私たちの努力で、Elasticsearchのresiliency（弾力性）を改善しています。そして、Riverが自身の特性として外部システムと外部システムライブラリと一緒に動作することによりクラスタの不安定性を引き起こしている大きな原因であるということを再三、見てきました。数ヶ月前にFoundが参加した時に、私たちは彼らも同じ考えであることを知りました。彼らの管理している数千のクラスタにおいて、Riverプラグインがクラスタの不安定性の多くの原因であると。

私たちはなんどか、それを見ることで、より弾力性のあるシステムを構築するための助けに、 Riverを非推奨にすることに決定し、ユーザにElasticsearchに「外部から」データを入れることに集中して欲しいとお願いします。

Riversは1.5で非推奨になりました。 2.0では移行を簡単にするために基盤は保持しますが、その後のバージョンでは削除するでしょう。

Elasticsearchにデータを入れる簡単な方法はまだ重要だと考えます。どんな方法があるでしょう？

この一年あまりで、私たちは多くのプログラミング言語のElasticsearchの公式クライアントを提供しています。これは、アプリケーションに組み込んで、すでにあるコードベースに簡単にデータを取得する処理を入れられます。（このあたりおかしい）この手法はまた、Elasticsearch簡単に… 一般的な例では、ORMとしてすでに使われているドメインモデルをデータベースにマッピングするアプリケーションやドメインモデルをElasticsearchにフッキング、インデキシングするための実装です。

また、Logstashやそれに似たツールもElasticsearchにデータを登録することができます。例えば、Elasticsearchの幾つかのRiverは、来るLogstash 1.5でLogstashのプラグイン（例えば、CouchDBのプラグイン）として実装されているものがあります。

私はコミュニティと様々なRiverプラグインを作成しての作業を愛しています。 Riverを非推奨にする決定は容易ではありませんでした。もしあなたがRiverプラグインの作者ならば何をしなければならないでしょう？

Riverは比較的自身で完結しているため、コードはElasticsearchにデータを入れることが出来る一般的なライブラリとして抽出することができます。したがって、このライブラリは様々な場所で利用できるでしょう。シンプルな「main class」であれば、スタンドアローンとしてそれを実行できるように書くこともできます。

その他の方法としてはLogstashのinputプラグインに移行することもできます。 Logstashのinputは作成するのが非常に簡単で、1.5に関しては、 Logstashチームがプラグインの記述方法、管理方法、そしてプラグインを探す方法について記述しています。

Riverが非推奨に（日本語訳）

目次

See Also by Hugo

Related by prelims-cli

FEATURED TAGS