Elasticsearch 1.6.0リリース（日本語訳）
※この記事は次のブログを翻訳したものになります。 原文：Elasticsearch 1.6.0 released 本日（6/9）、Lucene 4.10.4ベースのElasticsearch 1.6.0をリリースしました。 このリリースはElasticsearchの最新の安定バージョンとなります。 また、素晴らしい新機能がいくつか追加されています。 synced flushによるリスタートの高速化 �* シャード配置は保留中のタスクをブロックしない レスポンスボディのJSONのフィルタリング 共有ファイルシステムリポジトリに対するセキュリティフィックス 古いインデックスのためのUpgrade API Kibanaユーザのためのハイライトの強化 Windowsユーザのためのmlockall より詳細なスクリプト設定 すべての変更リストとダウンロードはこちらをごらんください。 synced f
Norikra meetup #2で発表してきました #norikra - BLOG::はるかさん
Norikra meetup #2でNorikraをログ解析に使うというごくごく一般的な内容の発表をしてきました。主催の@tagomorisさん、会場を提供頂いた:DeNAさん、皆様ありがとうございました。1年前に導入を検討し始めて、別に特段変わったこともしてないし、すごくヘビーに使っている訳でもないので、ゆるくまとめようとおもったらかなり時間余ってしまいました…… speakerdeck.com 最初MongoDBのcapped collectionに入れていたのが、Elasticsearch/Kibanaが流行してElasticsearchが全文検索以外に使われ出したり、ログ解析のトレンドはすごい勢いで変わってきているように感じます。Stream processingを行う方法にはFluentdのプラグインを用いる方法がありましたが、使っているfluent.confの中にfluent-
第10回elasticsearch勉強会に行ってきました - $shibayu36->blog;
elasticsearch.doorkeeper.jp 最近elasticsearchを触ることがあるので勉強会に行ってきました。 今回のなかで個人的に一番面白かったのは@mats116さんの「AWSで実現するelasticsearchの大規模運用」という話。nodeをmaster/data/searcher/indexerという役割に分けて、インフラを構成しているという話がなるほどという感じ。ある程度大規模になると大体master/data/searcherみたいな構成になりそうに感じる。searcherの部分はhttp.enabledをfalse、node.dataをfalseにするといっていたので、なんかのライブラリを利用してtransport層で通信しているのかなと思った。 またjohtaniさんの紹介していたelasticonの発表の中で、以下の話が面白そうだったので時間がある時
Logstashを使ったElasticsearchの再インデックス（日本語訳）
※この記事は次のブログを翻訳したものになります。 原文：Reindex Elasticsearch With Logstash Thanks David! マッピングを変更したり、インデックスの設定を変更したり、あるサーバから他のサーバや、 あるクラスタから他のクラスタ（例えば複数のデータセンターのような場合）にデータを再インデックスしたくなることがあるでしょう。 後者のような場合はSnapshotやRestoreの機能を利用することもできますが、インデックスの設定を変更をしたい場合は その他の方法が必要になります。 Logstash 1.5.0で、 elasticsearch inputとelasticsearch outputを使うことで、とても簡単に再インデックスができます。 ではやってみましょう。 古いクラスタ elasticsearch 1.5.2 はすでにダウンロード済みとして
Elasticsearch AWS で Multi-AZ 配置
AWSでは高可用性を高めるためにマルチAZの配置を推奨しています。サーバーをマルチZA配置にすることで、物理的に独立した複数のAZ (Availability Zone)にサーバーを稼働させることができるので、障害に強いシステムを構築できる素晴らしい仕組みです。 いいことずくめの仕組みなのですが、唯一の欠点はAZ間のレイテンシです。Elasticsearchは受け付けた検索要求をすべてのシャードへ問い合わせる仕組みのため、マルチAZ配置にするとAZ間の通信が発生してしまうので、どうしてもパフォーマンスが落ちてしまいます。 これを避けるには、１つのAZ内に配置されているElasticsearchのノードだけで完全なインデックス（シャード）を保持し、受け付けた検索要求は同じAZ内で検索を完結できるように構成する必要があります。それを実現するのが Shard Allocation Awarene
触って身に付く elasticsearch 1.0.0 の Snapshot と Restore 操作メモとスナップショットの仕組みの考察 - ようへいの日々精進XP
はじめに elasticsearch 1.0.0 が正式にリリースされたので改めて Snapshot と Restore 機能を試してみる スナップショットの仕組みについて少しだけ深堀りしてみる 操作 EC2 インスタンス上に構築した elasticsearch 1.0.0 リリース版を利用して操作する。また、データ自体はライブドアが提供しているこちらのレストランデータを利用する。 上図の restaurant インデックスを題材に Snapshot と Restore 機能を試してみる。ちなみにリクエスト内の ?pretty はお好みで。 リポジトリの一覧 curl -XGET "localhost:9200/_snapshot/?pretty" 以下のように表示される。 { "my_s3_repository" : { "type" : "s3", "settings" : { "re
Elasticsearch 日本語形態素解析のための文字列正規化の重要性
日本語の文章を形態素解析するときは、トークナイズする前に文字列の正規化を済ませて検索精度を向上させよう！ この記事は、Elasticsearch Advent Calendar 2014 の１８日目のエントリーです。即席で申し訳ないですが、なんとかまとめましたので是非最後までお付き合いください。 今回は、日本語形態素解析における文字列正規化のお話です。 それでは早速本題に。 非正規化された日本語の文章を形態素解析を使って、なるべく意図したようにトークナイズするためには、全角英数字を半角英数字に正規化したり、半角カタカナを全角カタカナに正規化したり、不要な文字を除外したり、単語ではなく、文字単位での正規化が重要になってきます。 Japanese (kuromoji) Analysis Plugin のページでも紹介されているように、全角英数字や半角カタカナの正規化には、CJK Width F
Embulkを使って大量の謎ログを読み込ませる手順 - Qiita
2015.3.16: @hiroysatoさんから教えていただいたnewコマンドをベースにした方法へ大幅に書き換え。 背景 セキュリティ関係のなんとかみたいな仕事をしていると、ある時急に数TBの謎のログを手渡されて「これ明日までになんか解析してみて」みたいなムチャぶりが飛んでくることがあります。このようなデータ分析では分析手法云々という前に、正規化してDBに取り込んだりする作業に相当の労力が必要になります。こういう事案に対していまどきなデータ転送ソフトウエアであるembulkを使うとだいぶ分析にとりかかれるまでの作業が楽になるのではないかと思ったので、一連の手順をまとめてみました。 前提条件 大きいサイズ（数GB〜数TB）のログデータを取り込みたい ログデータは1行1レコード形式のテキストで複数ファイルに分割されている ログの出力形式などは謎。既存のプラグインなど存在しない 出力形式の推定
Elasticsearch を使った位置情報検索 - クックパッド開発者ブログ
ホリデー事業室の内藤です。 ホリデー事業室は昨年の4月に発足した部署で、Holiday（https://haveagood.holiday）という新規サービスの開発を行っています。 Holiday とは、クックパッドが長年取り組んでいる「毎日の料理を楽しみにする」分野からは少しだけ離れ、「いつもの休日を楽しくすることで人生を豊かにする」ことを目指したサービスです。 例えばこちらのおでかけプランのように、「〇〇に行くならここも行ったほうがいいよ」や「〇〇を散策するならこのコースだよね」など、おでかけのレシピを投稿したり探すことができるようになっています。 今回は、全文検索エンジン Elasticsearch を使って、全文検索と位置情報を絡めた検索についてお話したいと思います。 本稿で説明する内容は、実際に Holiday の中でも応用を加えた形で使われています。 Holiday では、複数
Kibana4をKibana3みたいにHTMLだけで使うためのメモ - Qiita
まえがき 前の記事でKibana4をソースからビルドする手順を紹介しましたが、そこでビルドしたソース（とElasticsearchの設定）に手を加えるだけで、bin/kibanaを使わなくてもKibana4を利用できることがわかりました。 これができれば、慣れ親しんだApacheやnginxでアクセス制限ができたりしそうなので、今回はその手順を紹介します。 前提 前の記事で紹介した手順に従って、Kibana4をソースからビルドしてください。 ビルドが済んでいて、Kibana4のプロジェクトディレクトリー内にbuild/srcができていることを前提とします。Elasticsearchの起動もお忘れなく。 動作確認にpythonのSimpleHTTPServerを使用するため、Pythonが入っていることが望ましいです。 もし、Pythonがインストールされていなくても、Apacheやngin
#devsumiC 「14,000 件 /sec の配信を実現したリクルートのモバイル・アプリを支えるプッシュ通知基盤」のメモ - #garagekidztweetz
遅ればせながらせっかくなので devsumi2015 で参加してきたセッションのメモを公開していきます。 まずは、「20-C-2 14,000 件 /sec の配信を実現したリクルートのモバイル・アプリを支えるプッシュ通知基盤」から。 ひと言で言ってしまうと AWS （ DynamoDB とSQS ) と Elasticsearch の活用事例といったところだったかな、と。 では以降、メモです。 20-C-2 14,000 件 /sec の配信を実現したリクルートのモバイル・アプリを支えるプッシュ通知基盤 R-tech スマートデバイスグループ グループ横断的なスマートフォンアプリ開発 Pusna 開発 (プッシュ通知基盤) の進化と変化 Push 通知の特徴 メルマガに比べて開封率が高く、リアルタイム性も高い -> 効果的な販促ツール 情報レコメンド 休眠ユーザの再起 Recruit の
Elasticsearch勉強会第8回 ElasticsearchとKibanaで実現する 30億req/dayのリアルタイム分析
Elasticsearch勉強会第8回 ElasticsearchとKibanaで実現する 30億req/dayのリアルタイム分析
Elasticsearch クエリとスキーマ定義の細かい話
http://elasticsearch.doorkeeper.jp/events/19923 第8回elasticsearch勉強会 #elasticsearch #elasticsearchjp 2015-02-13（金）19:30 - 21:30 [訂正 2015/02/13] 負荷試験で心にとめていることの誤字を修正
プロダクション環境でElasticsearch+kibana(fluentd)でログ可視化運用をしてみてわかった事 - shnagaiの日記
これは Elasticsearch Advent Calendar 2014 22日目の記事です。 今回は、プロダクション環境で、流行りのFluentd+Elasticsearch+Kibanaでログ可視化というのを数ヶ月やった中で苦労した点とかはまった点を書いてみます。 というか、書き終えて思うとこれからやる人はここに気をつけた方がいいというような内容になってしまったので、既に運用されている方にはあまり役に立たないかもです。。 内容は、大きく下記3つです。 ①集計(検索)の条件を考えてtemplateでnot_analyzeを指定しておく ②スキーマ変更があるindexは、日単位でindex作るべし ③数値型フィールドの罠(Fluentd寄りの話) 前提として、この流れで収集しているのは下記4パターンのログ達。 ・Apache accesslog ・Apache errorlog ・Ap
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Elasticsearchで作る形態素解析サーバ
Elasticsearchのサジェスト機能を使った話
GitHub - arcus-io/docker-elasticsearch
http://blog.yoslab.com/entry/2015/02/13/203251
Mappings and Templates
fluent-plugin-stdinで手軽にローカルのファイルを転送する - Qiita
