2017.12.15 Friday
スポンサーサイト
一定期間更新がないため広告を表示しています
| スポンサードリンク | - | | - | - |
関口宏司のLuceneブログOSS検索ライブラリのLuceneおよびそのサブプロジェクト(Solr/Tika/Mahoutなど)について
2006.04.30 Sunday
「内容紹介」の訂正
本書はまだ店頭発売前だが、AmazonやYahoo!ブックスではすでに予約販売が始まっている。
これらのオンライン書籍販売サイトで次のような「内容紹介」がなされている(4月30日現在): Apache LuceneとはJavaで作られたGoogleのような全文検索システムです。 Luceneを使えば,一味違う高機能なWebアプリケーションを作ることができます。 たとえばWeb通販・ショッピングサイト,企業サイトの情報サービス,学術系サイトでの情報サービスなどが挙げられます。Webに付加価値を与えることができるのです。 本書は,全文検索システムの仕組みと機能を初心者にもわかりやすく解説し,豊富なサンプルコードで実装を示してゆきます。 構文解析プログラミングの教科書としてもどうぞ!非常に奥深い世界が広がっています。 これはおそらく出版社が考えてオンライン書店に送ったものだろうが、気になる点がある。明らかに事実と違う箇所があるのだ。 訂正した内容紹介文は担当編集者に送付済みだが、実際にオンライン書籍販売サイトの情報がいつ書き換わるかは定かではないので、ここにも訂正後の内容を示しておくこととする。訂正したい部分は上記で赤字で示した部分である。 (誤)「Apache LuceneとはJavaで作られたGoogleのような全文検索システムです。」 Apache Luceneは出来合いのシステムではなく、全文検索システムを構築するためのライブラリである、というのが正しい説明だ。また、Googleは世界中のWebページをロボットが「クロール」してインデックス(転置索引)を作成するが、Luceneには「クロール」する機能はない。これらのことは本書に明記している。 (誤)「構文解析プログラミングの教科書としてもどうぞ!」 本書は「構文解析プログラミング」についてはまったく触れていない。これは誇大広告というよりは事実無根である。「構文解析プログラミング」について学びたい人は本書を買ってはいけない。その場合は他書をあたって欲しい。 以上を踏まえ、担当編集者に送った訂正後の紹介文は次の通りである: Luceneは全文検索システムを構築するためのJavaのライブラリです。 Luceneを使えば,一味違う高機能なWebアプリケーションを作ることができます。 たとえばWeb通販・ショッピングサイト,企業サイトの情報サービス,学術系サイトでの情報サービスなどが挙げられます。Webに付加価値を与えることができるのです。 本書は,全文検索システムの仕組みと機能を初心者にもわかりやすく解説し,豊富なサンプルコードで実装を示してゆきます。 やさしく説明する工夫(挿話)やAjaxとLuceneを組み合わせた「インクリメンタルサーチ」など楽しい仕掛けも盛りだくさん!非常に奥深い世界が広がっています。 2006.04.29 Saturday
Lucene替え歌
ここにある事情でボツになった本書向けの「まえがき」の一部を掲載する。
それは、「Lucene替え歌」である。 本のまえがきに「替え歌」を載せてしまう。かつてそんな技術書があっただろうか。いや、ない。なので、やってみた。 ただし、担当編集者の池本さんに気づかれないようにこっそりと原稿に紛れ込ませた。 しかし、さすがはベテラン編集者だ。彼の目をごまかすことはできなかった。そして彼は静かに、しかしきっぱりとこう言った。 「替え歌はだめです。」 こうして、私の野望は潰えた。 以下はその幻の原稿である: 読者プレゼント Luceneの替え歌(井上陽水「夢の中へ」のメロディーでご一緒に!) 探し物は何ですか? 見つけにくいものですか? Googleの中も、Yahoo!の中も、 探したけれど見つからないのに まだまだ探す気ですか? それより僕とLuceneを勉強しませんか? ホームページへ、アプリケーションへ 検索機能を実装したいと思いませんか? Woo woo woo さあ〜・・・・・・ということで、本書でLuceneを勉強しましょう! 2006.04.27 Thursday
Apache Lucene入門
一昨日より、拙著「Apache Lucene 入門 - Java・オープンソース・全文検索システムの構築」がアマゾンで予約販売を開始した。
表紙画像はまだないようなので、ここに表示したい。こんな表紙である: 小さくてよくわからないかもしれないが、写真の部分は渦巻銀河である。そして、渦巻きの白い部分はよく見ると「テキスト」になっている。 全文検索は膨大なテキスト情報から検索質問語をキーにして目的の文書を取り出す機能であるが、「膨大なテキスト情報」を数千億もの星が集まって構成されているといわれる「銀河」になぞらえたイラストで、なかなかしゃれている。 最近、こういった本の表紙イラストや立ち上げ準備中の新会社のロゴという、デザイナーの仕事(アウトプット)を間近で見る機会が続いているが、感心しきりである。デザイン自体もそうだが、彼らの発想もまたすばらしい。 さて、肝心の本の中身だが、まえがきの後に書いた「本書の構成」の原稿を以下に貼り付けるので、参考にしていただきたい。 近日中にある事情で「ボツ」になったまえがきの原稿も公開しようと思う。 本書の構成 本書は6章構成になっており、第1章から第4章が前編、第5章と第6章が後編となっている。前編を「基本編」、後編を「応用編」と読み替えてもよい。Luceneのアプリケーションを書くためには「基本編」である第1章から第4章を通読しておくことが望ましい。「応用編」である第5章と第6章は余力があれば読むとよいだろう。 第1章は、全文検索とLuceneの基本知識の習得を目標とし、これらについて簡潔に述べている。Luceneに関しては、最初の全文検索のサンプルプログラムを作成し、その内容や動作を紹介している。サンプルプログラムの題材(全文検索のためのコンテンツ)には、日本でもっとも有名なファミリーである「サザエさん一家」を使用している。 第2章は、Analyzer(アナライザー)について説明している。Analyzerは、全文検索の対象となるドキュメントテキストを分析し、単語を取り出す働きをするものである。本章では特に日本語のテキストの分析に重きを置き、JapaneseAnalyzerの解説にページ数を割いている。その後、CJKAnalyzer、StandardAnalyzerおよびその他のAnalyzerを紹介する。 Luceneは全文検索に「転置索引方式」を採用している。そのため、検索の前にあらかじめ「インデックス」を作成しておかなければならない。第3章では、その「インデックス」の作成方法について説明している。その後、第4章で「インデックス」の検索方法について説明している。全文検索のサンプルデータとしては、サンプルプログラムの内容と動作の理解が進むよう、読者にとって親しみやすいと思われる「技術評論社の書籍データ」と郵便局の「大口事業所等個別番号データ」を用いた。 後編の第5章では、前編で習得した知識を使って、全文検索機能を持ったWebアプリケーションを作成する。このWebアプリケーションの検索機能は、「データベース」、「HTMLファイル」、「XMLファイル」、「PDFファイル」および「Mocrosoft Wordファイル」といった「異種ドキュメント」を透過的に検索し、表示する。 第6章では、「セキュリティ」、「検索質問語の強調表示」、「Ajaxを使用したインクリメンタルサーチ」等々といった、より応用的・発展的な内容を取り上げている。読者のLuceneアプリケーションにいろいろな機能を追加する際のヒントとなるだろう。 なお、Appendix AにはLuceneはじめ、その他の関連ツールおよび本書のサンプルプログラムのインストールと実行方法を掲載している。 2006.04.21 Friday
会社ロゴ制作
今日は、新会社のロゴ・名刺・Web制作をお願いしているデザイナーK氏と打ち合わせを行った。K氏は友人から紹介してもらったが、友人から聞いていた仕事振りから私も大いに期待し、デザイン系の仕事を全面的にお願いしたものである。
本日はロゴと名刺案数点についてデザインを見て話を聞くことができた。デザインは期待以上で、かつ、いい意味で裏切られるものでもあった。 たとえば、会社名のrond huitはなんとなく小文字をイメージしていたが、すべて大文字のデザインも提示され、どれも捨てがたいデザインであった。また、rondとhuitは独立した単語なので、間にスペースが入るものだろうと勝手に想像していたが、K氏のデザインはすべてrondhuitまたはRONDHUITと続けられていた。しかしそれによって、造形的な美しさと造語的な面白さ・独自性をロゴ自体がかもし出しているように感じた。 提示してもらったロゴは次の通りである。ここには載せていないが、名刺デザインもいろいろな配置で多数の案を提示してもらった。 本日はロゴについては上記のパターンからひとつを選んだ(どれを選んだのかは後日のお楽しみ)。そして週末にいろいろなカラーバリエーションをメールで送ってもらうこととなった。私はそのカラーバリエーションから数点を選び、来週頭に再度K氏とお会いして、実際の色見本から正確な色番号(専門用語があったが忘れた)を指定することとなった。 多忙なデザイナーK氏に無理なスケジュールで動いてもらったが、おかげさまで連休明けに名刺を持って営業が開始できそうである。 2006.04.18 Tuesday
LuceneによるGoogleの「もしかして」キーワードアドバイス機能の実現
Luceneのメーリングリストにたびたび登場する某氏はその的確な発言から好人物であることがうかがえる。しかし、私は彼の発言で気になることがひとつある。それは、implement(実装する)と書くべきところでimplimentと綴るくせがあるとことだ。
とても気になる。なぜそんなに気になるかというと、implement(s)はJavaの予約語でもあるからだ。 彼は当然のことながらJavaのプログラムを日々書いているだろう。そうすれば当然コンパイルもするわけで、implementsと書くべきところでimplimentsと書いたらコンパイラに怒られるのではないか。そうすれば、いいかげん正しい綴りに直りそうなものだが、彼がimplementと綴ったのを見たことがないのだ。 そんなわけで彼のメールが来ると気になってスレッドの内容に集中できないで困っている。いいかげん直して欲しいものだ。しかし直ったら直ったでまた気になると思う。どうしたものか。 ところで、綴りの間違いは日常よくあることのようで、最近は検索エンジンでも綴りの間違いの可能性を指摘してくれる。 たとえば、Googleで"impliment"と入力して[検索]ボタンをクリックすると、検索結果の上部に次のような表示がなされる: もしかして:implement Googleはいつからこんなに偉くなったんだ。いや、そんなに怒ってはいけない。よく見ればGoogleは低姿勢ではないか。「もしかして」である。「まちがってますよ」ではないのだ。実に慎み深くて好感触である。 Googleは世界中の80億ものWebページを日々クロールしてコンテンツを分析してインデックスを更新しているのだ。われわれが寝ているときも、食事をしているときも、トイレに行っているときも、風呂に入っているときも、テレビを見ているときも、飲みに行っているときも、Webページを集め続けている。そんなわけで、ここはそんな努力に「ご苦労さん」という意味も込めてGoogleのアドバイスにしたがって、「もしかして」の隣のimplementのリンクをクリックしてみる。 そうすると、Googleはますます自信を深めることとなるだろう。そうなると、Googleはそのうち、「もしかして」などとはいわなくなってくるのではないか。それはしゃくにさわるので、「もしかして」の方はクリックしてはいけない。ここは我慢して、implimentで検索に引っかかった別のページをクリックしたい。こういう人がたくさん現れると、Googleは自信を喪失していくに違いない。「オレが間違っていたのか・・・」。そして、ある日、「もしかして」はこのように変化するだろう: もしかして:implement 「もしかして」が小さく表示されるのである。Googleがimplimentが正しいと判断する日はもうすぐだ。 閑話休題。 Googleにだけ好きにさせておくのはアレなので、Googleに対抗して、Luceneを使って、「もしかして」の機能を実現してみたい。 それには、「あいまい検索」であるFuzzyQueryを使ってQueryを作成し、rewrite()メソッドでプリミティブなQueryに展開すると、検索に引っかかるTermを得ることができる。 コンテンツの題材には、小泉首相の「施政方針演説」を拝借する: 第164回国会における小泉内閣総理大臣施政方針演説 http://www.kantei.go.jp/jp/koizumispeech/2006/01/20sisei.html これに対して、次のようなキーワードで検索をかける:
このうち、1番目と3番目の単語は「施政方針演説」に含まれるので検索にヒットする。しかし、2番目と4番目はそれぞれ1番目と3番目の単語に似ているが「施政方針演説」に含まれない単語なので、検索にヒットしない。プログラムは検索にヒットしない単語の場合、インデックスに含まれる別の単語をアドバイスする、というものにする。 最初にプログラムの実行結果を示すと、次のようになる:
このプログラムの肝は次の部分だ:
検索にヒットしなかった検索質問語qからFuzzyQueryを作成し、rewrite()メソッドでBooleanQueryに展開する。そして、BooleanQueryを構成するBooleanClauseをとりだしてその節(clause)のTermQueryを調べればよいのだ。 このプログラムの全体は、次のようである:
2006.04.13 Thursday
会社名の決定
一部でお騒がせしている会社名であるが、先週の金曜日くらいに決めた。
株式会社 ロンウイット が新会社名となる。 会社名が決まると、これまで保留にしていたいろいろなことがどんどん進んでいくようになった。 たとえば、会社名を決めた金曜日その日にさっそくデザイナーの人と会い、ロゴ制作・名刺制作・Web制作を発注した。 私はこう見えても、中学から高校の美術の成績は5段階評価で5だったので--ついでに言えば、小学生のころの図工も5だった--ロゴ制作なんかは食指が動いてしまう。つい自分でやってみたくなる。しかしこういうのはやはりプロにお任せするべきだろう。 デザイナー氏は自分の会社を経営している友人から紹介してもらったが(友人もロゴと名刺制作をしてもらったのだ)、名刺制作などはロゴやフォント、その配置と紙質にいたるまで丁寧にコンサルをしてくれたとのことで私も大いに期待し、デザイン系の作業を外注したものである。今はロゴタイプを数案出してくれるということで、楽しみに待っているところだ。 また、会社設立の方は現在フリーで活動している私が日ごろお世話になっている会計事務所を通じて司法書士を紹介してもらい、その人にお願いしている。私がやることといったら、印鑑証明書を2通用意するぐらいで、あとは5月1日に法務局で待ち合わせすることが決まっているくらいだ。 ちなみにその司法書士の方は現在非常に忙しく、なかなかつかまらない。なにをしているのかと思ったら、今は有限会社の設立案件が非常に忙しいということであった。有限会社を作れるのは今月いっぱいなので、駆け込みの需要が結構あるようだ。 現在は5月以降に向けて準備をするということで、フリーの仕事も残作業以外は請けていない。そして、会社設立に伴う上記の作業はすべて外注しているので、それ以外の外注できない作業に没頭できる状態にある。自分の備忘録も兼ねてTO DOリストを書くと、こんな感じだ:
こうやって書いてみると、結構作業内容はばらばらだ。 2006.04.12 Wednesday
インデックスセグメントと関連パラメータ
Luceneのドキュメント(Document)はインデックス内のセグメントに登録され、管理される。
1つのセグメントにDocumentがいくつ入れられるかは、IndexWriterのマージ係数で決定される。 マージ係数はデフォルトで10である。この場合、10個のDocumentが1つのセグメント内に同居する。 11個目のDocumentが追加されたときは、新しいセグメントが作成されて、その中に追加したDocumentが入れられる。 このようにしてセグメントが増えていき、10個のDocumentを内包した10個のセグメントができると、それらがマージされて100個のDocumentを内包した1つのセグメントができる。そして、100個のDocumentを内包したセグメントが10個できるとそれらがマージされて1000個のDocumentを持った1つのセグメントができる。 このようにセグメント内にはDocumentがマージ係数のN乗単位で増えていくが、最大マージドキュメント数で1つのセグメント内のDocument数の上限を設定する。 なお、DocumentをIndexWriter.addDocument()で追加しても、即座にインデックスに反映されるわけではない。メモリ中のバッファに追加され、あるまとまった単位でインデックスに反映される。この数はIndexWriterの最大バッファ内ドキュメント数にて定められ、デフォルト値は10である。 この最大バッファ内ドキュメント数を大きくすると、インデックス作成のパフォーマンスが向上する。逆に小さくすると、IndexWriter.addDocument()で追加したときに即座にインデックスに反映されやすくなる。 これらのパラメータをまとめると、つぎの表のようになる:
2006.04.06 Thursday
会社名について悩む
5月に施行される新会社法に沿った会社を立ち上げる予定である。それについて、ここ3ヶ月くらい頭を悩ませている問題がある。
それは、会社名だ。これが決まらないと、案外、何も進まないものだ。ということにいよいよ5月が近づいてきて気がついた。最初は登記前に決めればいいや、くらいに思っていたのだ。それがどうだ、何も準備が進まないうちにもう4月も第2週に入ってしまった。 これではいかん、ということで悩みを人に共有してもらうために、こんなプレゼンを作って配った。 会社名についてのプレゼン http://handsout.jp/slide/532 しかしそもそも、「悩みを人に共有してもらう」というのは方向性として違うのではないか。返ってきた反応は「笑った〜(^O^)」「関口さんが悩んでいる様子がひしひしと伝わってきました」「がんばってください、応援しています」・・・こんな具合である。応援してくれるのはうれしいが、こんなことで時間を使っている場合ではないのだった。 当初は上の「プレゼン」にも書いたとおり「和風」の会社名にしようと思っていたが、紆余曲折を経て、結局、次のどちらかから選ぶことにした:
つづりはrond huitで仏語で丸(rond)八(huit)という意味だ。「丸八」というのは家の近所の通りの名前「丸八通り」から取ったものである。「丸」も「八」もめでたい方向性の文字であり、しかも近所の通りの名前から取る、という力の抜け具合というか、ニュートラルっぽいところがいい。 せっかく新しく会社を作るなら、会社名に創業者の想いとかを入れたら、という意見もあるが、命名に関してはNamazuやLuceneのことを他のところで書いたように、このくらいのノリでいいのではないか。というか、もうこの辺で決めないとやばい。 あと、なぜ仏語?というのはよく訊かれる質問である。FAQを作ろうか、と思ったくらいである。しかし、そんなことをしていると時間がどんどんなくなっていくので、ここで書いてしまうと「自分でもよくわからない」が答えだ。そんなに威張って言うことはない。 なぜ仏語か、そんなことわかるわけないじゃないか。日本人が日本国内で日本人を相手にする商売をするのになぜ会社名が仏語なんだろう。魔がさしたとしか思えない。 あえて理由をつけるなら、日本語だと「丸八」がつく会社名は無数にあるし、布団屋みたいだ。また、英語で「ラウンドエイト」だとボーリング場かボクシングの試合みたいだし、「サークルエイト」でもコンビニみたいだし第一、.com(ドットコム)ドメインが取れない。 じゃあ、仏語と同じ国連公用語であるアラビア語やスペイン語でもいいじゃないか、といわれると何も言い返せない。仏語がしゃべれるとか、そういうわけでもない。フランスとの接点は特に思い当たらないし、強いてあげれば年に数回口にするフランスパンくらいのものである。なので、これについては特に深く考えないことにする。 では最後に残った問題で、「ロンユイット」と「ロンウイット」のどちらにするか、ということだが、これもまた悩んでしまって、アンケートを取ることにした。 結果は、「ロンユイット」がいいとする者がおよそ3割、「ロンウイット」の方がいいという者が7割、という結果であった。 では、これを受けて「ロンウイット」にしよう、とすんなりいかずにまた悩んでいる。そもそも、多数決で決めよう、とか最初に決心していなかったのがまずかった。アンケートを取りつつ、さらに悩む。こんなことでこの先大丈夫なのか・・・。 2006.04.05 Wednesday
Namazu と Lucene
日本で「オープンソースの全文検索システム」といえばまずNamazuが思い浮かぶ。中央官公庁、地方自治体をはじめ、企業システムなどにも導入実績は豊富なようだ。
その圧倒的な導入事例の数には驚かされるばかりだが、私が最初にNamazuのことを知ったときに衝撃を受けたのは、導入事例ではなくその名前である。 なんなんだ、Namazuって。思わず声に出していたと思う。「ナマズ」。 「ナマズ」といえば、それまでの日本人にとって、地震を予知する能力を有すると言い伝えられている魚、という解釈が一般的ではなかったか。あるいはナマズ研究家である秋篠宮殿下を思い浮かべるのもよい。 しかし時代は変わった。そして今やNamazuといえば全文検索システムである。少なくとも、IT業界の中ではそういうことになっている。そして誰もがあらためて疑問に思うのだった。「Namazuの名前の由来はなんだろう」。その答えはwww.namazu.orgのFAQにあり、それはさらに人々を驚愕させるのに十分であった。「特に意味はありません。思いつきで決めました」。なんという軽さだ。いいのかそれで。 そこでわれらがLuceneである。これは日本ではルシーンと発音することが多いが、実際はルーシーンとルシーンの中間のようだ。私は言い易い方のルシーンで呼んでいる。 このLuceneという日本人になじみのない単語はなんだろう。 私は「ルシーン」という音からなんとなくスピード感を覚えたものだ。そこでLuceneというのはきっと超音速ジェット機の開発コード名かなにかだろう、少なくともF1マシンくらいはあるに違いないと考えた。 そして調べてみると、やはり答えはlucene.apache.orgのFAQにあり、再度衝撃を受けたのであった。「LuceneはCutting氏の奥さんのミドルネームです」。大丈夫なのか、検索業界は。 では気を取り直して、Luceneの導入事例はどうなのか見てみよう。Luceneの導入事例はhttp://wiki.apache.org/jakarta-lucene/PoweredByで見ることができる。これから導入実績は十分あるといってよいだろう。ちょっと安心だ。JavaプログラマにとってはおなじみのjGuru(http://www.jguru.com/)やTheServerSide.COM(http://www.theserverside.com/tss)もLuceneを使っていることがわかる。 しかし残念ながら、日本語をベースとしたシステムへのLuceneの導入事例はほとんど聞かない。日本語システムへの導入実績に関しては日本生まれのNamazuにLuceneは大きく水をあけられているといわざるを得ない。この辺は、今後徐々にでも日本でLuceneが広まればと願うところである。 |
+ Solrによるブログ内検索
+ PROFILE
+ LINKS
+ Lucene&Solrデモ
+ ThinkIT記事
+ RECOMMEND
+ RECOMMEND
Lucene in Action (JUGEMレビュー »)
Erik Hatcher,Otis Gospodnetic,Mike McCandless FastVectorHighlighterについて解説記事を寄稿しました。
+ RECOMMEND
+ SELECTED ENTRIES
+ RECENT COMMENTS
+ RECENT TRACKBACK
+ CATEGORIES
+ ARCHIVES
+ MOBILE
+ SPONSORED LINKS
|
(C) 2024 ブログ JUGEM Some Rights Reserved.
|
PAGE TOP |