先日、静的サイトに特化した全文検索ライブラリとして「Pagefind」というソフトウェアがあることを、下記の記事が話題になったことで知りました。 参考：静的サイトに特化した検索ライブラリ Pagefind を試す | grip on minds 実は、いまお読みのPublickeyはまさに、Movable TypeというCMSを用いて生成された静的なWebサイトです。現在、PublickeyではGoogleが提供している「Googleカスタム検索エンジン」を全文検索エンジンとして採用しています（右上の虫眼鏡アイコンから呼び出せます）。 しかしPublickeyでは以前からGoogleに依存しない、自前の全文検索エンジンを持てないかと模索しており、まさにPagefindは私が探し求めていたソフトウェアだったと言えます。 そこでさっそくPagefindがPublickeyに導入できるかどうか、
前回投稿で未解決だった問題、簡単に解決したので書いておく。 前回投稿でkuromojiがどうのこうのとやったが、今回の目的には必要なかった。目的は、前回投稿にも載せているが、以下のまぬけなグラフをなんとかしたいだけである。 つまり「キリン／一／番／絞り」を、普通に「キリン一番絞り」と表示できればよいのだ。要するに「分かち書き」が回避できればいい。で、この目的のためにはElasticsearchでmappingの定義をしてやればいいだけだった。 参考 fluentdからElasticSearch+kibana3に転送した文字列が分かち書きされるのを回避する 参考ページではmappingの定義をcurlリクエストで行っているが、今回は設定でやってみた。/etc/elasticsearch 配下にtemplatesディレクトリを作成し、そこにmappingを定義した適当な名前のjsonファイルを
はじめに Spark, SQL on Hadoop etc. Advent Calendar 2014 15日目です。 3日目の記事でもSpark Streamingは紹介されていましたが、私のほうではより初心者向けの基本的な内容を記述しておきたいと思います。 Spark Streamingとは リアルタイムログ検索エンジンを考えてみる 実装してみる Spark Streamingとは Apache Sparkはインメモリで動作する柔軟なバッチエンジンです。 Spark Streamingはストリームで流れてくるデータに対してApache Sparkで書いたバッチが動作するものです。 誤解を恐れずにいうとSpark Streamingは主に以下の3つの機能を提供しています。 各種ストリームデータを取得するためのコネクタ(Receiver)を提供する ストリームデータをSparkのRDDのよ
0. ログやデータを取得した後は？ ログやデータの分析には、様々なアプローチが考えられるが、Apache Solrやelasticsearchといった全文検索エンジン製品にデータを蓄積し、その機能を用いて検索・集計・分析を行う方法がある。その際、データをそのまま蓄積するのではなく、各ツイート・各行に属性を付与（エンリッチメント）することにより、分析の幅は大きく広がる。 全文検索エンジンへのデータの投入では、Flume-ngやfluentdといったデータ収集製品を利用する実例が多い。しかし、リアルタイムにデータに対してエンリッチメントの前処理を行おうとした場合、処理が複雑になるにつれ、単体サーバーで動作するFlume-ngやfluentdでは処理能力が頭打ちになってくる。そこで、登場するのが、リアルタイムに大量のデータを処理することができるストリーミング処理系のビッグデータ関連技術である。
しれっと久しぶりに投稿です。 Elasticsearchに日本語検索最適化プラグインkuromojiを入れてゴニョゴニョやってみたので、その記録など。 さらにKibanaで可視化したらどうなるか、を試してみた。（長いです） つい最近 Elasticsearch 1.4beta、Kibana 4betaがリリースされたのでせっかくだからそっちで試してもよかったのだが、チラ見したところkibana 4ではインターフェースがガラっと変わったらしく（またか）、そこでハマるわけにはいかないので安心の Elasticsearch 1.3、Kibana 3という環境で実施。マシンはAmazon EC2のm1.small, CentOS 6.5。 参考 Kuromojiで日本語全文検索 – AWSで始めるElasticSearch(1) ElasticSearch に Kuromoji プラグインを導入す
2014年4月21日は、第4回Elasticsearch勉強会ですね！ http://elasticsearch.doorkeeper.jp/events/8865 第4回Elasticsearch勉強会は、参加希望者が約200名の大反響なようです。 私は勉強会に参加できないので、C言語で書かれた国産の高速な全文検索エンジンGroongaと、Javaで書かれた世界的に勢いのあるElasticsearchについて性能の比較をしたいと思います。 注意事項 今回の検証では1台あたりの馬力を比較するためにサーバ1台での全文検索性能について比較しています。 私は、Groonga(Mroonga)の利用暦が約2年であるのに対し、Elasticsearchの利用暦は2日です。このため、Elasticsearchに対するチューニングの不備や公平な比較になっていない点が含まれている可能性があります。 Ela
2. 名前: 菅谷信介 所属: N2SM, Inc. オープンソース活動: Apache Portals (Jetspeed2など) コミッタ Seasarプロジェクトコミッタ(S2Container, Teeda, SAStruts, DBFlute, S2Portlet, S2Robot..) Fessプロジェクト運営 などなど・・・ Github: https://github.com/codelibs Blog: http://www.chazine.com/ Twitter: https://twitter.com/shinsuke_sugaya/ 自己紹介
【2016/09/10追記】 勉強しなおして、Elasticsearchの知識についてさらにまとめた記事を書いたので、そちらを参照してもらうと良さそうです。 blog.shibayu36.org 最近Elasticsearchの勉強をした。ただ、入門のためどのような資料が適しているかを知るのが大変だった。そこでどのように勉強したかについてメモをしておく。少しまとめエントリー的なノリになりそう。 Elasticsearchの概念を知る 全文検索技術の基本を知る Elasticsearchのドキュメントのたどり方を知る の順に学習を進めていった。 Elasticsearchの概念を知る Elasticsearchの学習を始めようとした時に、まずは基本からということで以下の本を読んでいた。 高速スケーラブル検索エンジン ElasticSearch Server (アスキー書籍) 作者:Ｒａｆａｌ
PostgreSQLアンカンファレンス＠東京（2015/5/30）でPostgreSQLの日本語全文検索まわりについて紹介しようかとたくらんでいます。しかし、現時点（2015-05-25）でキャンセル待ちで、当日参加できないかもしれないので紹介しようと用意している内容をここにまとめます。 内容 この資料の目的は、PostgreSQLで使える次の3つの方法の特性を紹介し、ユーザーが適切な方法を選択するための材料を提供することです。 LIKE pg_bigm PGroonga（ぴーじーるんが） LIKE LIKEのメリット・デメリットは次の通りです。 メリット 標準で使える インデックス作成不要（= データ更新が遅くならない） データが少なければ十分速い デメリット データ量に比例して遅くなる ユーザーがLIKEを使うかどうかの判断基準は「十分速いかどうか」（= 「データが少ないかどうか」）で
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
