2.1からQueryParserに"*:*"という文字列を指定すると、MatchAllDocsQueryに翻訳してくれる機能が追加された:http://issues.apache.org/jira/browse/LUCENE-723MatchAllDocsQueryはインデックス中の全ドキュメントを取得するためのQueryである。P.194-195)。factorが不要な場合、当該フィールドに対してsetOmitNorms(true)を指定すると、検索時のヒープ消費量が最大で「ドキュメント数分のバイト」だけ節約できる。インデックスに100万件のドキュメントがあるとき、1つのインデックスフィールドに対してsetOmitNorms(true)を実行すると、そのフィールドを検索するプログラムではsetOmitNorms(true)を実行しない場合と比べて1Mバイト(ここではMは百万)のメモリが節約できる。factorをメモリ上にキャッシュするためである。このキャッシュはフィールド名をキーにしたテーブルで管理されているため、setOmitNorms(true)を行ったフィールドの分だけ節約の効果が出てくる。5つのインデックスフィールドでsetOmitNorms(true)を実行すると、100万件の文書では5Mバイト、1,000万件の文書では50Mバイトのヒープが節約できる。文書数が大きなインデックスほど節約効果が大きく簡単に試せるため、覚えておくとよいだろう。SaturdayIndexWriterの新しいコンストラクタ世の中、Web2.0が花盛りである。何を隠そう、弊社もWeb2.0企業へ変身しようと社内改革に真剣に取り組んでいる。そのためにまず、Web2.0とは何かを調べる必要がある。睦(著)どれも面白くためになった。軽量なプログラミングモデル単一デバイスの枠を超えたソフトウェアリッチなユーザー経験しかしどうもよくわからない。Web2.0企業になるためには何をすればいいのだろう。そこで思いついたのは、これらの本で必ず取り上げられているWeb2.0企業の最先端、Googleのまねをすることである。Googleのまねをするというと人は「検索エンジンの開発でもするのか」と想像するであろう。私が開発したわけではないが、当社は既に検索エンジンを持っていてそれで商売をしている。ここはもっと意表をつくやり方でやってみたい。私の昔の同僚でGoogleに移籍した者がおり、彼と飲んだときのことである。Googleについて彼が熱く語ったいくつかの逸話のうち、ひどく私の印象に残った話は「Googleは社員に無料で食事を振舞う」というものであった。これは今でこそ広く知れ渡っているGoogleの福利厚生のひとつであるが、当時は驚きと感心をもって聞いたものである。無料サービスがこんなところでも行われているのだった。これを取り入れさせてもらうことにする。まねするだけではだめだ。Googleの上を行くために、うちは3食すべて会社で払うことにする。なると3食すべて外食にしなければならない(社員食堂がまだないので)。これはなかなか大変なことだが、Web2.0のためには乗り越えなければならない壁である。領収書を受け取り、申告にあたってはきちんと残らず添付する。3食すべて領収書があるので、その分量といったら大変な枚数になるだろう。毎月の領収書の糊付けの作業だけで一日費やすことになってしまうかもしれない。Web2.0のためなので文句は言えない。すると税務署は大量の食費の領収書を見てあきれ、こういうだろう。税務署はとまどうばかりだ。税金を取るために執念を燃やす彼らは、署に戻りWeb2.0に関する勉強会を開いて対策を立てて出直すだろう。彼らはまたもこう指摘するのだった。「この領収書は1.0ですから」なんと、いつの間にか税務署も2.0化しているのだった。2.0の前で人は無力である。2.0といえば、Luceneのバージョンも今2.0である。次のバージョンとされている2.1は残Issueの数だけで見ればもうすぐ出そうな気配である。バグフィックスだけでなく、パフォーマンスについても前回書いたとおり改善されている。そのほかの改善点でひとつのわかりやすい例をあげると、IndexWriterのコンストラクタの追加がある。createの扱いがやっかいなものであった。この引数をtrueにすると、1番目の引数で指定したインデックスを作成するのであるが、インデックスがあってもなくても新規作成してしまう。逆にfalseにするとインデックスがないときはFileNotFoundExceptionをスローする。FileNotFoundExceptionこの表で、赤字にしたところがやっかいな動作の部分だ。Lucene本でもこの部分については数ページを割き、最終的にIndexReader.indexExists()メソッドを使うことを提案している。このフラグは多くの人を戸惑わせていたようで改善提案がなされた。オリジナルの提案では、3番目の引数をcreateではなくclearと改名し、clear=falseのときでインデックスがないときはFileNotFoundExceptionではなく新規作成するようにして欲しい、というものであった。すればエンドユーザには影響がないであろう、という主旨のようだが、これでは既存のプログラムが影響を受けるのでこの案は受け入れられなかったが、その代わり新しいコンストラクタが導入されることになった。この新しいコンストラクタでは、3番目の引数がはぶかれている。動作としては上記の表の黒字部分のようになる。インデックスがあれば追加し、なければ新規作成する、というコンストラクタである。これはおそらく今後最も使われるIndexWriterのコンストラクタになると私は予想している。WednesdayTermDocsとTermEnumこう見えてもそれなりに忙しい私が年内中に片付けたいこととして、仕事場の掃除があげられる。見はそれなりに片付いている感がある。必要なときにちょっとした文具やツールが見つからなかったりする。そんなとき、「Luceneの替え歌」を頭の中でリフレインしつつ探してみたりするのだが、見つからないものはやっぱり見つからない。悲惨な状態になっているのが、机の「一番上の引き出しの中」である。私の使っている独立ワゴン型の引き出しは3段になっていて2段目と3段目はそれなりに深さがあり、A4のファイルや技術書が見やすく並べられ整理されている。上の引き出しはそれらに比べて浅い。何を入れればいいのだろう。ITOKIの狙いがよくわからない。印刷業者から届けられた名刺ケースを引き出しの奥に置いてみる。スペースが空いている。そこで印鑑と朱肉を配置する。ホッチキスとその針を置く。セロハンテープと液状ノリ。