検索と題してはいるけど、なんだか検索を前提としていない雰囲気の本。
検索というのは発見のための1つのユースケース(もしくは実現方法)であるという主旨が最初の方にくる。発見ではなくナレッジマネジメント(!)の一部であるというところまで行くあたりが、この本が技術要素としての「検索」をメインに扱っていないことを表している。
後半に登場するパターンは参考にならないことももちろんないが、どちらかというとそういう思考フレームワーク的な、手順を踏まえて検索を考える向きにとても面白い。検索をよくするということは、発見やその体験をよくするということであって、検索という形だけじゃなくてもっと別なところも見ないといけない、というあたりはとても納得感がある。
検索というものをより良くするには、専門分野の垣根を越えたコラボレーションが必要だし、自分たちが思い描いている障壁を突破しないとね。
自由に考えるというより、きちんと筋道立てて考えているんだと思った。もしくは筋道立てて伝えてくれている。
どんなにセンスが必要な話であっても、本にまとまるときちんと目的からはじめてくれる。うれしいです。
以下はこの本と連動した(?)サイト。
Solr 3.1からTikaEntityProcessorというDataImportHandler用のProcessorがついたけど、これをDataSourceや他のProcessorとどう組み合わせて良いかがさっぱりわからない。
ぐぐりつつ試してみて、あるディレクトリ以下のファイルを全て取り込むのは多分これで良いという結論になった。
<dataConfig> <dataSource type="BinFileDataSource" name="bin"/> <document> <entity name="file" processor="FileListEntityProcessor" baseDir="/path/to/targetdir" fileName=".*" recursive="true" rootEntity="false" dataSource="null"> <entity name="tika" processor="TikaEntityProcessor" dataSource="bin" url="${file.fileAbsolutePath}" format="text" transformer="LogTransformer" logTemplate="file: ${file.fileAbsolutePath} processed" logLevel="info" onError="skip" > <field name="Author" meta="true" column="author"/> <field name="title" meta="true" column="title"/> <field name="text" column="text" /> </entity> </entity> </document> </dataConfig>
TikaEntityProcessorはDataSource<InputStream>のサブクラスがdataSourceになってないといけない。なのでBinFileDataSourceが必要。で、BinFileDataSourceはファイルの絶対パスが必要なのでFileListEntityProcessorからもらう。
FileListEntityProcessorはあるディレクトリの下にあるファイルを一つ一つ処理する感じ。正規表現でファイルをexcludeすることもできる。
このFileListEntityProcessorとの組み合わせがあんまり情報ないんですよ。。。
<fields> <field name="title" type="string" indexed="true" stored="true"/> <field name="author" type="string" indexed="true" stored="true" /> <field name="text" type="text" indexed="true" stored="true" /> </fields>
スキーマはこんな感じ。多分他にも増やせばTikaが抽出できるメタデータをもっと入れられるんだと思うけど、そこまで調べられていない。
やってみると、Tikaで処理できない旨のエラーが結構おきる。処理できなかったときには、特別なログに吐くなどしてエンドユーザに知らせたいんだけど、今のところSolrが普通通りログに吐くことしかできない。onErrorで好きな処理を指定することができなくて、abortするかそのドキュメントをskipするかしかできない。
そこそこのページ数だったが、夜なべして後半は一気に読んでしまった。
内容についてはザ・ゴールからつづく一連のやり方と大体同じで、ある問題が多い会社を舞台にTOCを活用して業績を上げるというおなじみかつ分かりやすいストーリー。楽しめたし、相変わらずいい読後感。
リーンだのTPSだのTOCだのみたいな概念について、いろんな人が共通認識として持っていると偉い楽だなあと思ってる。さらに、エンジニアだったらその工学的な側面では捉えていないと困るとも思う。「ボトルネック」という言葉が通じなかったりするとorzとなるし。
そのためにも、小難しく聞こえがちなものをこういう小説仕立てで見せるのはいい。もし高校野球の女子マネージャーがドラッカーの『マネジメント』を読んだら の偉いところもそこだよね。あれはもっとデフォルメが極端だけど、抽象的だったり分かりづらかったりするのを具体的なストーリーで見せるのは同じ。
そういうのが教養を形成する、と言うのかどうかはわからないけど、そういう方面の共通のコンテキストを作るのが会社という組織だけでは難しい側面もあるから、こういうのはもっと売れて欲しい。もしドラレベルとまでは言わないけど。
デフォルトでPhraseQueryを生成しなくなったQueryParserに注意(3.1)を読んで意味が分からなかったので、プログラムを実行してみた
public class TestLucene2458 { static final Version V = Version.LUCENE_31; public static void main(String args[]) throws CorruptIndexException, IOException, ParseException { Directory directory = createIndex(); IndexSearcher searcher = new IndexSearcher(directory); QueryParser qp = new QueryParser(V, "F", new CJKAnalyzer(V)); Query query = qp.parse("あいえお"); TopDocs docs = searcher.search(query, 5); System.out.println(docs.totalHits); } private static Directory createIndex() throws CorruptIndexException, IOException { Directory directory = new RAMDirectory(); Analyzer analyzer = new CJKAnalyzer(V); MaxFieldLength maxlen = new MaxFieldLength(100); IndexWriter writer = new IndexWriter(directory, analyzer, true, maxlen); Document doc = new Document(); doc.add(new Field("F", "あいうえお", Field.Store.YES, Field.Index.ANALYZED)); writer.addDocument(doc); writer.close(); return directory; } }
ようするに、"あいうえお"というドキュメントにたいして"あいえお"で検索している。なんと、これがhitする。
1
qp.setAutoGeneratePhraseQueries(true);
を入れると0になる。
ええーーーー。議論読んでないんで、良く意味が分からない。。