Naoya Murakami
visio****@gmail*****
2013年 8月 23日 (金) 06:43:33 JST
お世話になっております。村上です。 度々の自己レスですいません。 大きいサイズのカラムを2つのカラムにわけることにより、grn_ja file is fullのメッセージを回避できました! したがって、以下で自己完結としておきます! 当方の認識に間違いがある場合にのみ、時間があるときにでもご指摘いただければ幸いです。 今月のリリースも期待しております! ----------------------- まず、レコード数が上限になっているのかどうかを切りわけるため、最もサイズの大きいlongtextのカラムの データをごく短い文字列(aa)に変えてテーブルインサートしたところ、grn_ja file is fullのメッセージは 発生しませんでした。このことからレコード数は関係ないなと思いました。 また、インデックスは無効な状態のままインサートしていてこのメッセージが発生するということから推測すると、 テーブルの制限の1つのキーの最大サイズ4Kバイトでもなく、キーサイズ合計4Gバイトでもなく、 インデックスのレコード数、語彙数の上限2億6千万、最大インデックスサイズ256GBでもなく、 実は1カラムの最大データサイズにも制限があり、これにひっかかっているんじゃないかなぁと思いました。 そこで、単純にでかいカラムを分けるだけでいけるんじゃないかと、最もでかいlongtextのカラムを2つのカラムに分割しました。 こうすると、インデックス無効の状態でインサートしても、grn_ja file is fullのメッセージは発生しなくなりました。 このことから、実はgroongaの1カラムには最大データサイズの制限というのがあるんじゃないかなぁと思っています。 (たぶん最大インデックスと同じ256GB?)認識に間違いがなければ、ドキュメントに記載があると親切かもしれません。 http://groonga.org/ja/docs/limitations.html http://mroonga.org/ja/docs/reference/limitations.html インデックス構築してみて、他の制限にひっかかったり、構築後のパフォーマンスがあまり芳しくない場合は、 素直に水平分割構成に戻して、SPIDERつかったりして対応します。 水平分割すると、スケールしやすいだとか、パーティション刈り込みができればはやいとか 管理しやすいとかいろいろメリットがあるとは思いますが、 複数インデックスを使おうとしてもorder by limitの最適化は、分散したテーブル全部をソートしなければ いけなかったりするのでテーブル数が多いと結局時間がかかってしまったり、 mroonga_commandを使えないので個別にしかドリルダウンができなかったりして、一長一短なんですよね。 (とくに、複数インデックスをつかって、ソートしないという手段がとれないのが。。) なので、1テーブルで耐えうる性能がでるのかどうか試して見て判断したいなぁと思っています。 なお、当方、システム構築の実務経験がないので、設計自体がナンセンスという可能性は大です。 余談ですが、テーブル参照もいろいろいじってみたのですが、SQLで参照元カラム名.参照先カラムという 指定ができなかったので、現状、mroongaでは、参照先の主キーしか扱えず、TEXT型、LONGTEXT型の テーブル参照はできないと認識しました。間違ってたら教えてください。 以上です。 2013年8月21日 5:54 Naoya Murakami <visio****@gmail*****>: > お世話になっております。村上です。 > > 度々の投稿失礼いたします。 > > 以下のエラーメッセージは、具体的には、どの制限にひっかかっているのでしょうか? > http://groonga.org/ja/docs/limitations.html#limitations-of-table > > Got error 1026 'grn_ja file (**.mrn.000019E) is full' from mroonga > > このメッセージは、disable keysにした状態で大量のデータをインサートして、 > 1100万レコード目ぐらいで必ず発生します。 > > この制限に引っかかった場合、テーブルを水平分割せざるを得ないという認識でよろしいでしょうか? > キーやサイズがでかすぎることが原因という場合は、大きいカラムをテーブル参照とかに > 置き換えれば回避可能でしょうか? > > 以上、よろしくお願いします。 > > >