Search and analytics, data ingestion, and visualization – all at your fingertips.
![Elasticsearch: The Official Distributed Search & Analytics Engine | Elastic](https://cdn-ak-scissors.b.st-hatena.com/image/square/920e019aaec2913305595d3953ac79066eeffb34/height=288;version=1;width=512/https%3A%2F%2Fwww.elastic.co%2Fstatic-res%2Fimages%2Fsocial_media_default.png)
こんにちは。 エンジニアの伊藤です。 11/18に開催された第7回Elasticsearch勉強会にて「niconicoの検索を支えるElasticsearch」と題して、niconicoでのElasticsearchの運用事例について発表してきました。 発表の機会を与えてくださった@johtaniさん、スタッフの皆さん、ありがとうございました。 (この投稿は報告が遅くなっただけで、アドベントカレンダーネタではありません...) 使用したスライドがコチラになります。 https://speakerdeck.com/shoito/niconico-elasticsearch 講演では、まずElasticsearchを使った検索基盤を作った背景、 次に、なぜElasticsearchを使うことにしたのか? そして、どう使っているのか?どう運用しているのか? 最後に、良く参考にしているElast
※この記事は次のブログを翻訳したものになります。 原文:Elasticsearch 1.5.0 Released 本日(3/23)、Lucene 4.10.4ベースのElasticsearch 1.5.0 をリリースしました。 このリリースはElasticsearchの最新の安定バージョンとなります。 多くのresiliency(復元性、弾力性) enhancementとバグフィックスを含んでおり、 すべてのユーザにアップグレードを推奨しています。 すべての変更についてはdownload Elasticsearch 1.5.0 hereをごらんください。 460PRという大量の変更を含む本リリースは、Elasticsearchをよりresilient(弾力のあるもの)にするために 費やされています。 Inner hits 本リリースで追加された、Elasticsearchに最もリクエストさ
AWSでは高可用性を高めるためにマルチAZの配置を推奨しています。サーバーをマルチZA配置にすることで、物理的に独立した複数のAZ (Availability Zone)にサーバーを稼働させることができるので、障害に強いシステムを構築できる素晴らしい仕組みです。 いいことずくめの仕組みなのですが、唯一の欠点はAZ間のレイテンシです。Elasticsearchは受け付けた検索要求をすべてのシャードへ問い合わせる仕組みのため、マルチAZ配置にするとAZ間の通信が発生してしまうので、どうしてもパフォーマンスが落ちてしまいます。 これを避けるには、1つのAZ内に配置されているElasticsearchのノードだけで完全なインデックス(シャード)を保持し、受け付けた検索要求は同じAZ内で検索を完結できるように構成する必要があります。それを実現するのが Shard Allocation Awarene
Elasticsearchのインデキシングに関するパフォーマンス検討 原文:performance considerations for elasticsearch indexing Elasticsearchユーザは様々な楽しいユースケースを持っています。小さなログを追加することから、Webスケールの大きなドキュメントの集合をインデキシングするようなことまでです。また、インデキシングのスループットを最大化することが重要で一般的な目標となります。 「典型的な」アプリケーションに対して良いデフォルト値を設定するようにしていますが、次のちょっとした簡単なベストプラクティスによってインデキシングのパフォーマンスをすぐに改善することができます。それらについて記述します。 第一に、制御できないならば、巨大なJavaヒープを使用しない:必要なサイズ(マシンの持つRAMの半分以下)のheapだけを設定し
TODO: 必要なら図を足す 他に書いた方が良いPros/Consのリクエストがあったら追記 内部のイベントストリームの扱い Pros: Inputがスケーラブルに実装しやすく,データストリームを正常時/エラー時で切り替えやすい Cons: エラーハンドリングがブロッキングモデルよりも複雑になりやすい 以下長々と理由書きます. Fluentdはイベントストリームを効率良く,またロバストに扱うことを目的に設計されています.そのため,独自の転送プロトコル(forwardプラグイン)を実装していますし,内部のイベントのハンドリングもそれに沿うようになっています.ただ,それによって相性の悪い操作とかもあります. Fluentdはバッファ機能を提供しており,これによって転送の効率化とエラー時のデータロスを防ぐ設計になっています.が,あまりにも書き込み先が遅いなどの問題があると,バッファの制限を超えて
遅刻した場合は入場できませんのでご注意ください。 ■タイムテーブル Elasticsearch株式会社 Jun Ohtani @johtani タイトル:Elasticsearch導入チェックリスト? 株式会社ドワンゴ 藤堂淳也 さん タイトル:Elasticsearch クエリとスキーマ定義のすごい細かい話 株式会社サイバーエージェント 山田直行さん @satully タイトル:ElasticsearchとKibanaで実現する、30億req/dayのリアルタイム分析 株式会社はてな 山家雄介さん @yanbe タイトル:はてなのメディア面を支えるElasticsearch(参考記事:http://bookmark.hatenastaff.com/entry/2014/06/27/180000) LT 未定 勉強会終了後、同フロア別室にて懇親会を開催予定です。 ======== スピーカ
UPDATE: This article refers to our hosted Elasticsearch offering by an older name, Found. Please note that Found is now known as Elastic Cloud. Leader election is one of the most tricky things to do in distributed systems. At same time, understanding how a leader is elected and the responsibilities of the leader is key to understanding a distributed system. IntroductionAll distributed systems have
セコン (id:secondlife, @hotchpotch) です。ウェブサービスにはよく「このエントリーに関連するブログ記事」や「このレシピに関連するレシピ」という機能が実現されてますよね。さて、この機能はどのように実現すれば良いでしょうか。例えば tf-idf で単語の類似度を求め…といった実装が必要になり、いささか面倒です。 しかしながら Elasticsearch や Solr *1を使うと手軽に実現できます。例えば、クックパッドニュースの記事では Solr を使い「この記事を読んだ人におすすめ」の機能に、最近クックパッドにジョインしたインドネシアの会社の DapurMasak では Elasticsearch を使い「Resep serupa(関連レシピ)」の機能で利用しています。 クックパッドニュースでのこの記事を読んだ人におすすめ DapurMasak での関連レシピ 使
The Loggly service utilizes Elasticsearch (ES) as the search engine underneath a lot of our core functionality. As Jon Gifford explained in his recent post on Elasticsearch vs Solr, log management imposes some tough requirements on search technology. To boil it down, it must be able to: Reliably perform near real-time indexing at huge scale – in our case, more than 100,000 log events per second Si
“Solr or Elasticsearch?”…well, at least that is the common question we hear from Sematext’s consulting services clients and prospects. Which one is better, Solr or Elasticsearch? Which one is faster? Which one scales better? Which one is easier to manage? Which one should we use? Is there any advantage to migrating from Solr to Elasticsearch? – and the list goes on. These are all great questions,
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く