全文検索システムの比較 - Elasticsearch vs Solr vs Amazon CloudSearch February 10, 2014 at 01:05 AM | categories: solr, aws, elasticsearch, web | 候補の選定方法 候補を選定するにあたって、以下の特徴をもっていることを前提とした。 LuceneやGroongaを使えば何でもできるが、ここでは対象としない。 ウェブベースのインターフェースを持つ インデックスの更新はほぼリアルタイムに反映される スケールアウトが容易 Solr https://lucene.apache.org/solr/ Luceneをバックエンドにした全文検索システム。バージョン4になってから大幅に機能が増強された。 長所 実績が十分ある 機能豊富 短所 クラスタを構築して運用するには手間がかかりそう S
昨晩、Elasticsearchから初のプロダクトとなるMarvelがリリースされました。ということで、さっそく触ってみて、簡単な紹介と感想を書いてみました。 Marvelって? Elasticsearch社が初のプロダクトとしてリリースした、Elasticsearchクラスタモニタリングツールです。 次のような特徴があります。 plugin形式で提供 GUIがKibana メトリックスはElasticsearchに保存 SenseがChrome以外でも使える プロダクション環境で利用する場合は有料ですが、開発用途では無料で利用できます。 現時点(2014/01/29)では、0.90.9以上のバージョン(1.0.0.RC1含む)で利用が可能です。 なにができるの? Elasticsearchクラスタに関するメトリックスを保存、可視化できるプロダクトです。 ドキュメント数やJVMの状況、クラ
第2回を開催しました! すごい、140人くらいくらいの参加登録者(参加者は100人ちょっと!)がいて、びっくりです。 ステキな会場を提供していただいた、リクルートテクノロジーズさん、運営していただいた方々、スピーカーの皆さん、参加者の皆さん本当にありがとうございました。 今回も素敵な看板ありがとうございます。 今回もしっかり楽しめたので、次回も頑張ります! 今回は、elasticsearch-jpMLの紹介とかをできたのでよかったかなぁと。 ぜひ、活用してください!どんな質問でもいいので。 あと、スライドに入ってた例の本もよろしくです。 ということで、懇親会も盛り上がったし楽しかったです。 今後も場の提供+自分の勉強のトリガーとして、開催していくので、ご協力お願いします! 聞きたい話など、MLや@ツイートしていただければと。 elasticsearchのRouting機能:株式会社シーマー
はじめに 前回の記事で fluentd から Elasticsearch にデータを放り込む際にフィールドタイプが軒並み文字列として扱われてしまった対応として fluent-plugin-typecast を使ってフィールドタイプを変更して Elasticsearch にデータを放り込んで対応したが、別のアプローチとして @johtani さんに以下のようなコメントを頂いたので早速試してみる! elasticsearch側でマッピングを定義してあげてからデータを登録するとおそらく、floatなどは文字列が来ても登録できると思います。 見た感じ、フィールド名などは決まっているようですし。 コメント頂けるだけでも嬉しいのにわざわざ手順まで記載頂いて感謝!有難うございます! 参考 johtani / double_mapping_test.json mapping core types deve
ElasticSearch勉強会 第1回を主催しました。 昨年のpyfesでなんちゃって資料で喋って、1年たちました。 ElasticSearchの書籍(英語)も出てきて、今年はElasticSearchが面白くなりそうだし、使ってる人たちから話も聞きたいなぁということで、主催しました。 思った以上に興味のある方がいらっしゃったようで、100人応募のところ、チケットがすぐ完売してしまうほど。。。 しかも、当日もほぼ満員ということで、大変な盛況ぶりでした。 スピーカーの皆様、参加された皆様、会場を提供していただいたリクルートテクノロジーズさん、ありがとうございました!(たぶん、90人くらいいらっしゃってたかと。) こんなステキな案内板も用意してもらいました。スタッフのみなさんありがとうございます! トゥギャっても頂きました。まとめていただいてありがとうございます! 自分の発表や個々の発表に関
この記事は古くなりました。新しい知見は下記を参照。aoking.hatenablog.jp 概要 全文検索エンジン Solr を使用していて、パフォーマンスチューニングに四苦八苦した話。 ここでは、検索時ではなくドキュメントの追加時についてのチューニングについて記してある。 更新自体は参照に比べて頻度が少ないが、参照はレプリケーションして負荷分散しやすい。 更新は整合性を保つために一台のマスターノードに対して行われるので更新はボトルネックになりやすいのだ。 定期的に IO 負荷が高くなる Solr を使っていると、一時的に猛烈に IO 負荷が高まる時がある。fsync になんと1分以上かかるような、猛烈な負荷だ。 これはインデクスのマージ時に起きる IO 負荷で、巨大なインデクス同士のマージだとその合計サイズ分の IO が発生することで IO 処理が専有されたままになっていた。 インデクス
メールアドレスのルールのまとめ系のサイトの内容が間違っています。 なので、この類のまとめは安易に信じないように 、という注意喚起をしておきます。 追記(2013/11/27) twitterやはてブをみていたところ、「ユーザーへの啓蒙という観点ではまとめの内容間違ってない」というご意見をたくさんいただきましたので、補足をしておきますね。 どうも「ルール」と「トラブルを避けるためのガイドライン」が混同されているように思います。まとめで紹介されている内容がユーザ向けの「ガイドライン」なのであれば、「+ 記号使わせてよ」ぐらいしか文句はありません。 ですが、ほとんどのまとめは上記の内容を「ルール」として説明しています。ひどいものにはRFCに基づいてまとめを書いたようにミスリードさせる記事もありました。このような現状を憂い、このような記事を書いたのです。 そもそもこれに気づいた発端は@kusano
[:W560] Log集計用DB設計 考える問題 Document無しのAgile開発をガチで推奨したい@yutakikuchi_です。【進撃の巨大データ】の第2回目として巨大アクセスLog集計用DBの設計について勉強した内容についてメモしたいと思います。DB周りはそこまで詳しく無いので詳しい皆様からの突っ込み大歓迎でございます。また図々しいですが知恵をください(笑)。 今日の主目的は下の2要件を叶えるためのDB設計を考える事です。特に問題になるのがRealTimeの話でTableにLogDataを書き込む処理と集計のSQLをどのように組み立てるか、それ以外にもSystemPerformanceとArchitectureにも関わってきます。 リアルタイムで大量データを集計したい 定期処理で大量データを集計したい 使うもの Fluentd : Fluentd: Open Source Log
awkという、古くからのスクリプト言語がある。(1977年生まれ。読み方は「オーク」である。エイ・ダブリュ・ケイではない)man awkをPDFに変換してみると、たったの3ページ強しかない。 $ man -t awk|pstopdf -i -o ~/Downloads/awk.pdf とてもシンプルな言語仕様ではあるが、awkには必要十分な表現力がある。特にテキストを処理する場面においては、最小限のシンプルな記述で、気の利いた処理を素早くこなす。無駄のないawkワンライナーを見ると、ある種の感動を覚える。awk以降に生まれたスクリプト言語は、少なからずawkの影響を受けていると思われる。 awkを知ることで、間違いなく幸福度は上がると思う。いつかきっと「知ってて良かった」と思える時が来るはず。もっともっと、awkを知りたくなってきた。 基本動作 awkの基本動作は、とってもシンプルである。
Nginx 1.4.2で試しました。 ネームサーバーは、ローカルのunboundをlocal-zone, local-dataを使って簡易コンテンツサーバーにして試しました。 local-zone: "oreno." static local-data: "api.oreno. 30 IN A 192.0.2.11" # local-data: "api.oreno. 30 IN A 192.0.2.12" proxy_passにホスト名を書くと→名前解決は一度だけ このように Nginx の設定を書いた場合、 location /api { proxy_pass http://api.oreno:9999; } 「api.oreno」の名前解決は、nginxの起動時に行われます 名前解決できない場合は、nginxは起動しません 名前解決できた場合は、ずっとそのIPアドレスにreverse
人間とウェブの未来(旧) 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 IOT研究会やコンテナ勉強会で発表した内容を制御コード例を交えて具体的なリソース制御の書き方を紹介したいと思います。 詳しい内容は上の行のエントリへのリンクを見て頂くとして、簡単にまとめると、Apacheへのリクエスト単位でCPUやDISK I/O等のコンピュータリソースを制御しようという話になります。今回はその仕組(mod_mrubyでcgroupを制御)の導入から具体的な制御DSLコードのサンプルを紹介します。 導入 導入はこれまでに何度も紹介していた内容とかぶるのですが、mod_mrubyのインストールと同様です。まずはgithubからmod_mrubyをcloneして、mod_mrubyディレクトリにあるbuild_config.rb
skelJSはJavaScript製、MIT Licenseのオープンソース・ソフトウェアです。 レスポンシブなWebデザインを考える際にはブロックを意識してデザインを行う必要があります。多くは幅を12分割して提供するようです。レスポンシブなサイトやWebアプリを開発するためのフレームワーク、skelJSも同様の設計となっています。 デスクトップサイズ。Bootstrapのように見やすい画面になっています。 タブレットサイズ。この場合もデスクトップライクですが、横の隙間は狭まっています。 スマートフォンサイズ。メニューなどはそのままに、下のコンテンツはずれています。 作成例。12個のブロックをどう割り当てるかを決めていく形です。 -3uといった指定をすると左側が空く仕組みになっています。これは面白いです。 入れ子にした場合の表示はちょっと変わっています。 skelJSは大きなフレームワーク
Linuxのhistoryコマンドで、実際にそれらのコマンドが実行された日時がわかればいいのになあと思っていたら、あったので方法を書いておきます。 まず、使用するためには、bash 3.0以降である必要がありますので、確認しておいてください。 [root]# bash -version GNU bash, version 3.2.25(1)-release (i686-redhat-linux-gnu) Copyright (C) 2005 Free Software Foundation, Inc. シェル変数「HISTTIMEFORMAT」を設定する シェル変数「HISTTIMEFORMAT」を設定することで、historyコマンドの結果に日時が表示されるようになります。 [root]# HISTTIMEFORMAT='%y/%m/%d %H:%M:%S '; 但し、この設定をして以降
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く