Kouhei Sutou
kou****@clear*****
2013年 8月 23日 (金) 15:42:13 JST
須藤です。 > このことから、実はgroongaの１カラムには最大データサイズの制限というのがあるんじゃないかなぁと思っています。 > （たぶん最大インデックスと同じ２５６ＧＢ？）認識に間違いがなければ、ドキュメントに記載があると親切かもしれません。 > http://groonga.org/ja/docs/limitations.html > http://mroonga.org/ja/docs/reference/limitations.html > ソースをのぞいてみたところ、最大データサイズにも制限がありそ うでした。たぶん、以下の計算式で計算できて、256GiBが最大値で あっていると思います。 (1 << 22) * (1 << (38 - 22)) = 256GiB 後でもりさんに確認してドキュメントを更新しておきますね。 > 余談ですが、テーブル参照もいろいろいじってみたのですが、SQLで参照元カラム名.参照先カラムという > 指定ができなかったので、現状、mroongaでは、参照先の主キーしか扱えず、TEXT型、LONGTEXT型の > テーブル参照はできないと認識しました。間違ってたら教えてください。 す、すみません。ピンとこないので、具体的なスキーマ定義とクエ リーを教えてもらえるとうれしいです！ In <CANM+Hhcvv98_EqYN-****@mail*****> "[groonga-dev,01663] Re: GRN_NOT_ENOUGH_SPACEのエラーメッセージの意味と回避方法について" on Fri, 23 Aug 2013 06:43:33 +0900, Naoya Murakami <visio****@gmail*****> wrote: > お世話になっております。村上です。 > > 度々の自己レスですいません。 > 大きいサイズのカラムを２つのカラムにわけることにより、grn_ja file is fullのメッセージを回避できました！ > したがって、以下で自己完結としておきます！ > 当方の認識に間違いがある場合にのみ、時間があるときにでもご指摘いただければ幸いです。 > > 今月のリリースも期待しております！ > > ----------------------- > まず、レコード数が上限になっているのかどうかを切りわけるため、最もサイズの大きいlongtextのカラムの > データをごく短い文字列（aa）に変えてテーブルインサートしたところ、grn_ja file is fullのメッセージは > 発生しませんでした。このことからレコード数は関係ないなと思いました。 > > また、インデックスは無効な状態のままインサートしていてこのメッセージが発生するということから推測すると、 > テーブルの制限の１つのキーの最大サイズ４Ｋバイトでもなく、キーサイズ合計４Ｇバイトでもなく、 > インデックスのレコード数、語彙数の上限２億６千万、最大インデックスサイズ２５６ＧＢでもなく、 > 実は１カラムの最大データサイズにも制限があり、これにひっかかっているんじゃないかなぁと思いました。 > > そこで、単純にでかいカラムを分けるだけでいけるんじゃないかと、最もでかいlongtextのカラムを２つのカラムに分割しました。 > こうすると、インデックス無効の状態でインサートしても、grn_ja file is fullのメッセージは発生しなくなりました。 > > このことから、実はgroongaの１カラムには最大データサイズの制限というのがあるんじゃないかなぁと思っています。 > （たぶん最大インデックスと同じ２５６ＧＢ？）認識に間違いがなければ、ドキュメントに記載があると親切かもしれません。 > http://groonga.org/ja/docs/limitations.html > http://mroonga.org/ja/docs/reference/limitations.html > > インデックス構築してみて、他の制限にひっかかったり、構築後のパフォーマンスがあまり芳しくない場合は、 > 素直に水平分割構成に戻して、SPIDERつかったりして対応します。 > > 水平分割すると、スケールしやすいだとか、パーティション刈り込みができればはやいとか > 管理しやすいとかいろいろメリットがあるとは思いますが、 > 複数インデックスを使おうとしてもorder by limitの最適化は、分散したテーブル全部をソートしなければ > いけなかったりするのでテーブル数が多いと結局時間がかかってしまったり、 > mroonga_commandを使えないので個別にしかドリルダウンができなかったりして、一長一短なんですよね。 > （とくに、複数インデックスをつかって、ソートしないという手段がとれないのが。。） > なので、１テーブルで耐えうる性能がでるのかどうか試して見て判断したいなぁと思っています。 > > なお、当方、システム構築の実務経験がないので、設計自体がナンセンスという可能性は大です。 > > 余談ですが、テーブル参照もいろいろいじってみたのですが、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にした状態で大量のデータをインサートして、 >> １１００万レコード目ぐらいで必ず発生します。 >> >> この制限に引っかかった場合、テーブルを水平分割せざるを得ないという認識でよろしいでしょうか？ >> キーやサイズがでかすぎることが原因という場合は、大きいカラムをテーブル参照とかに >> 置き換えれば回避可能でしょうか？ >> >> 以上、よろしくお願いします。 >> >> >> > _______________________________________________ > groonga-dev mailing list > groon****@lists***** > http://lists.sourceforge.jp/mailman/listinfo/groonga-dev
