solrデータ削減計測

とりあえず今日一日のデータで比較。
実行中にデータが増えてるかもしんないから、多少のずれはあるかも。

一番期待していたomitTermFreqAndPositionsはやはり想像通り日本語検索がまともに動かなくなる。普通に考えるとどうせデフォルトはn-gramだろうから、positionがなくなると検索できないのは当たり前だ。「ねこ」と「エロ」は検索できるからこれでもいい気がする。omitPositionsはあるんだけど、term frequencyだけ無くすのはできないのかね。どのくらい効果あるかはわからないけど。

次に全文検索indexに使ってるほうのパラメータ変更によるデータサイズの比較

copied index store=false omitNorm=false	16480
copied index store=false omitNorm=true	16480
copied index store=false omitNorm=true compressed=true	16480

あんまり意味が無い

元データの本文のパラメータによるデータサイズの比較

indexed=true	22200
indexed=false compressThreshold=1000	16480
indexed=false compressThreshold=100	16480
indexed=false compressThreshold=1	16480
indexed=false	16480

compressedのパラメータが効いてない。呪うぞ、糞が。

もう機能自体がないのか。普通に困るだろ、常識的に考えて。
http://grokbase.com/t/lucene.apache.org/solr-user/2010/06/wither-field-compresed-true/27iucsnlkn73p33sy3k4n3ohcrry

とりあえず簡単に変更できて効きそうなのは、

• copyFieldで結合して全文検索のindexにしてるデータをstored=falseにする
  • 当たり前だけど大幅にデータ量削減
• copyFieldの結合元のほうをindexed=falseにする
  • フィールドごとのindexが削減できる

あとの問題はfull indexをするだけの空きディスク容量がないということだけだな。困った。

追記：
solr再起動したらディスクが大量に空いた。何故？
linodeリサイズした時のサイズに戻ったくらいなので、色々cacheとかが消えたということなのかね？
とりあえずぎりぎり再indexする容量ができたと思うので、full-import試してみる。

追記

2236538
2
0:36:58.414

意外と速い。初めてやった時(http://d.hatena.ne.jp/kudzu/20110513/1305313247)は、多分コーパスが半分くらいだったと思うけど、数時間かかった憶えがある。メモリが大きくなって、indexが半分くらいになったから速くなったのかね？
結果的にはディスク使用量が13GB -> 6GBになった。

Filesystem 1K-blocks Used Available Use% Mounted on
/dev/xvda 30689308 14582152 15797828 48% /
none 384424 108 384316 1% /dev
none 384424 0 384424 0% /dev/shm
none 384424 60 384364 1% /var/run
none 384424 0 384424 0% /var/lock
none 384424 0 384424 0% /lib/init/rw

別に20GBで十分だったな。一応このくらい余裕があると安心だけど。