Elasticsearchのクラスタにノードを追加するのは簡単にできる。しかし、インデックスを盛々積んだクラスタにノードをカジュアルに追加すると、一気にシャードのアロケーションが走って負荷があがる。また、何の設定もせずに追加するとsplit brainを起こしやすくなる。適切に設定すれば大丈夫なので、それをまとめておく。 結論 安全にやるなら、 ノード追加前に全shardの移動を止める。 split brainを避けるために、最小のマスターノード数を設定しておく。 ということをしておくとよい。 クラスタ設定はリアルタイムに変更できるので活用しよう。 Cluster Update Settings http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/cluster-update-settings.html
See the video here: https://www.youtube.com/watch?v=o6lSeNatVFM A look at the elements required by Elasticsearch to turn a simple inverted index into an auto-clustering, horizontally scalable real time search and analytics engine. The talk will start from first principles, explaining how an inverted index works, how to make an inverted index suitable for real time search, how to scale that out, an
Sematextのブログにて連載された"Solr vs ElasticSearch"の翻訳。 現在、Part 6まで存在し、その全てを翻訳した。 Part 1 – 概観 Part 2 – インデックス作成と言語の取扱 Part 3 – 検索 Part 4 – Faceting Part 5 - 管理APIの機能 Part 6 – ユーザと開発者のコミュニティ比較 なお、オリジナルの記事はこちらのPart1から全て辿ることができる。 http://blog.sematext.com/2012/08/23/solr-vs-elasticsearch-part-1-overview/ この連載はまだ続くはずだがPart 7がいつ出るのかはわからない。また出た時に翻訳を続けられるかもわからない。 なお、訳者はSolrもElasticSearchも大した知識を持っていない。誤訳等見つけられたらぜひコ
概要 fluentd でサービスの情報を転送し、Kibana で分析したい これまでの過去データを一度に放り込みたい データの件数が合わない Kibana でエラーが発生する 各種設定を見直すことで対応可能 背景 長い長いミーティングに疲れ、集中力を擦り減らしたアナタは 無意識のうちにブラウザを起動していました。 去年まで勤めていた会社の同僚がシェアした記事が目に止まります。 「fluentd + Elasticsearch + Kibana で今どきのログ分析!」 感化されやすいアナタはおもむろに VM を立ち上げ環境を構築します。 Web サーバから吐き出されたログはオシャレでイイ感じにチャート化され、 満足したアナタは VM を落とし、再び仕事に戻りました。 しばらく経ったある日のこと、ふと気づきます。 「ログだけじゃなくて、ユーザ属性の分析にもコレ使えそう。」 毎度オレオレ管理ペー
目的 検索用サーバーとして最近注目されているElasticsearchですが、ついに1.0 RC1がリリースされたそうです。 Googleトレンドを見ても、この分野で先行するApache Solrに迫る勢いを感じます。 そういうわけで私もElasticsearchについて興味を持って調べてみましたが情報がちょっと少ないですね… 「調べたけど断片的な情報しかない」 「公式doc英語だし、専門用語が多すぎてわからん」 「え、できること多すぎ。よくわからん。どれが重要?」 と言った感じで、最初ちょっと大変… そこで調べ始める人が、概観をつかむためのチュートリアルをつくろうと思います。 コマンドを全部実行する必要ありません。用語をおさえることで調べものが捗ることがひとつのゴールです。 自分の理解の整理も兼ねています。間違ってる箇所あったら教えて下さい。 part 1:ESを使ってレストラン検索を作
fluent-plugin-elasticsearchやKibanaのデフォルトであるlogstash形式では、年月日毎にインデックスを作成されて使われることを想定されています。 これは扱いやすいのですが万能では無く、次のような状況ではパフォーマンス的な観点で、このインデックスの粒度を変更することを検討すると良いケースがあります。 粒度を細かくしたいケース(時間単位) 日毎のインデックス作成では、elasticsearchに割り当てたメモリ量を超えてしまう 粒度を荒くしたいケース(週単位/月単位/年単位) 日毎のインデックス作成では容量が小さく、日常的に検索する範囲が複数のインデックスに渡るとき Kibanaは年月日以外の粒度(時間・日・週・月・年)にも対応していますので、変更することも容易です。これは次の2つの設定変更で適用できます。 ログ収集を行うElasticsearchへ流し込む、
こんにちは。kimukimuです。 AWS re:Invent 2013 で Amazon Kinesis が発表されるなど、 ストリームデータ処理に対するニーズの高まりを感じますね。 (Amazon Kinesis は、Stormとも連携できるようになっているようです)。 さて、先日、Storm 0.9.0 が正式リリースされたり、Apache Kafka 0.8.0 が正式リリースされたりしたので、 それらを連携して、ストリームデータの可視化を行うプロトタイプを作ってみました。 1. はじめに まず、「ストリームデータ」とは、連続的に発生し続けるデータのことを指します。 システムが出力するログやセンサーが発生するデータ、SNSなどで常時発生するメッセージなどが該当します。 今回は、Apacheが出力するログを、ストリームデータとして収集・可視化することを行ってみます。 1-1.やりたい
RocksDB is the default state store for Kafka Streams. In this talk, we will discuss how to improve single node performance of the state store by tuning RocksDB and how to efficiently identify issues in the setup. We start with a short description of the RocksDB architecture. We discuss how Kafka Streams restores the state stores from Kafka by leveraging RocksDB features for bulk loading of data. W
さきほど帰国。parse.comのメモに引き続き、re:InventでのLogglyのセッションについてもまとめておく。 【追記 2013/11/20 9:20】スライドがupされていたので貼っておきます。 要約すると、 お客さんから大量に送られてくるログをリアルタイムに捌くためのシステム 最初の設計ではSolrCloudを利用していた 第二世代ではElasticsearchを利用。システム全体としてElasticな環境に。 基本環境はKafka + Stormな構成 セッションの情報は以下のとおり。 ARC303 - Unmeltable Infrastructure at Scale: Using Apache Kafka, Twitter Storm, and Elastic Search on AWS This is a technical architect's case stu
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く