Naoya Murakami
visio****@gmail*****
2013年 8月 29日 (木) 16:42:09 JST
お世話になっております。村上です。
>もし余裕があるのなら(1)+「mallocが本当に失敗しているかを調べ
>る」（手順は後述）をしてもらいたいのですが、今のgroongaで
>90GiBのデータのオフラインインデックス構築は難しそうなのでお
>願いしづらいなぁというのが正直なところです。
可能な限り、原因を解明できたほうが、今後のためだと思いますので、
今晩はこれを仕掛けようと思います。また、明日、結果をご連絡します。
ちょっと疑問に思ったのですが、メモリ32Gでこうなるということは、
メモリがもっと小さくて、4GBとか8GBだともっと早くこの問題が
顕在化されるんですかね？
最近は、メモリが非常に大きくなってきて、データベース向けの
サーバなら100GB超のメモリも有り得るようにはなってきましたが、
まだまだ数GB程度のメモリのものも多く存在しそうです。
>また、スワップの追加は大変だと思うので、(3)データの持ち方を変
>えるのが現実的だと思います。せっかくいろいろ試してもらったの
>にすみません。。。
対応案のご提案ありがとうございます。いい案だと思います。
思いつきませんでした。上の結果いかんにかかわらず、
この対応は検討したいと思います。
なお、インデックスサイズは、ものすごく偏っていて、
以下のような感じだと思われます（だいたいの予想です）。
* title: 1GiB
* abstract: 5GiB
* claims: 14GiB
* description_19xx: 30GiB
* description_20xx: 40GiB
* property: 0GiB (ベクターカラム化して現状中身０です。）
それでも、１度、全体を19xxと20xxに水平分割にしてやった場合は、
インデックス構築ができたので、description_19xxと20xxを単独に
することで、インデックス構築に耐えれそうな気がします。
>検索するときにMATCH AGAINSTを複数指定しないといけなくなりま
>すが。。。
そこで、インデックスをわけるにあたって、以下の疑問点があります。
通常のSQL構文では、マルチカラムインデックスにしないと
複数のカラムを横断して全文検索ができないと思っています。
MySQLでは、以下のようにorで繋ぐと、片方のフルテキスト
インデックスしか使えないと認識しています。
この規模のインデックスなしの検索は破たんすると思っています。
where match against(descripiton_19xx) against('hogehoge' in boolean mode)
or match against(descripiton_20xx) against('hogehoge' in boolean mode)
groongaでは、マルチカラムだろうが単独カラムだろうがどっち
のインデックスでも||で全文検索できますよ。ていう記載があります。
http://groonga.org/ja/docs/tutorial/match_columns.html#id1
Q.MySQLからマルチでない複数の全文インデックスを跨ぐ検索を
することができますか？（両方のインデックスを使いつつ）
ひょっとしたら、以下のような指定はできるんじゃないかなぁと
考えています。
でも、この場合、match_columnsで指定できないので、１個１個
カラムと検索式を書かないといけないですかね？
また、この書き方と、マルチカラムの場合の速度差が気になります。
select * from ftext where match(description_19xx)
against('hogehoge + description_20xx:hogehoge' in boolean mode)
limit 1;
なお、少なくとも、mroonga_commandでselectしてmatch_colmuns を||
でつなげばできると考えています。
新規開発なので絶対に普通のSQL構文じゃなきゃいやだとか、そういう
制約はないです。
（水平分割するとSPIDERとの連携を考えなければいけませんが。）
速度差が顕著なのであれば、mroonga_commandでjsonを自前でparse
してもいいと思っています。
（たいして速度が変わらないのであれば、通常のレコード形式で
返ってきた方がうれしい。）
以上、よろしくお願いします。