※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch unplugged - Networking changes in 2.0 Elasticsearchをローカルのマシンで起動します。 そして、昨日試したデータを削除するためにDELETE *を実行します。 すると、悲しそうな叫びを同僚が発していることに気づき、なぜそんなことになっているのか不思議に思うでしょう。。。 Elasticsearchはいつも、親しみやすいものでした。 複数ノードのクラスタがどのように機能するのかをテストするには、 ローカルのマシンでいくつかのElasticsearchのインスタンスを起動するだけでした。 起動したインスタンスはマルチキャストを利用して自動的にお互いを見つけて、1つのクラスタになり、負荷を共有し始めます。 しかし、これは親しみやすすぎました。 カンファレンスなどで、

※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.7.0 and 1.6.1 released 本日（7/16）、Lucene 4.10.4ベースのElasticsearch 1.7.0およびElasticsearch 1.6.1 のバグフィックス版をリリースしました。 これらのリリースはセキュリティフィックスを含んでおり、すべてのユーザにアップグレードを推奨します。 ダウンロードおよびすべての変更については次のリンクをごらんください。 最新安定版：Elasticsearch 1.7.0 1.6系バグフィックス：Elasticsearch 1.6.1 1.7.0が1.x系の最後のリリースとなります。 今後の新機能については、Elasticsearch 2.0以降で取り込まれる予定です。 Elasticsearch 1.7.0は小さなリリースですが、2つ

Elasticsearchのインデキシングに関するパフォーマンス検討 原文：performance considerations for elasticsearch indexing Elasticsearchユーザは様々な楽しいユースケースを持っています。小さなログを追加することから、Webスケールの大きなドキュメントの集合をインデキシングするようなことまでです。また、インデキシングのスループットを最大化することが重要で一般的な目標となります。 「典型的な」アプリケーションに対して良いデフォルト値を設定するようにしていますが、次のちょっとした簡単なベストプラクティスによってインデキシングのパフォーマンスをすぐに改善することができます。それらについて記述します。 第一に、制御できないならば、巨大なJavaヒープを使用しない：必要なサイズ（マシンの持つRAMの半分以下）のheapだけを設定し