[groonga-dev,01673] Re: GRN_NOT_ENOUGH_SPACEのエラーメッセージの意味と回避方法について

Back to archive index

Naoya Murakami visio****@gmail*****
2013年 8月 23日 (金) 17:09:30 JST


お世話になっております。村上です。

>> 余談ですが、テーブル参照もいろいろいじってみたのですが、SQLで参照元カラム名.参照先カラムという
>> 指定ができなかったので、現状、mroongaでは、参照先の主キーしか扱えず、TEXT型、LONGTEXT型の
>> テーブル参照はできないと認識しました。間違ってたら教えてください。

>す、すみません。ピンとこないので、具体的なスキーマ定義とクエ
>リーを教えてもらえるとうれしいです!

以下を参照すると、参照元カラムのみを指定したときは、 "参照元カラム名._key" と
同様の扱いとなり、参照先レコードの主キーが取り出されます。
と記載されています。

http://groonga.org/ja/docs/tutorial/data.html#reference-types

以下のテストケースは、この"参照元カラムのみを指定したとき"に
相当するテーブルの作り方とinsertの仕方だと認識しています。

https://github.com/mroonga/mroonga/blob/master/test/sql/suite/mroonga/storage/column/groonga/scalar/r/reference.result
CREATE TABLE Tags (
name VARCHAR(64) PRIMARY KEY
) DEFAULT CHARSET=utf8
COLLATE=utf8_bin;

CREATE TABLE Bugs (
id INT UNSIGNED PRIMARY KEY,
tag TEXT COMMENT 'type "Tags"'
) DEFAULT CHARSET=utf8;

INSERT INTO Bugs (id, tag) VALUES (1, "Linux");


また、以下には、テーブル参照のカラムがあるときは、 reference/commands/select
コマンドの output_columns 引数に "参照元カラム.参照先カラム" と指定することにより、
参照先カラムの値を取り出すことができます。と記載されています。
http://groonga.org/ja/docs/tutorial/data.html#reference-types


この方法をmroongaでSQLで実現する方法がわかりませんでした。
参照先テーブルTagsのtextを参照元テーブルBugsからSQLで実行
する方法がわかりません。

CREATE TABLE Tags (
name VARCHAR(64) PRIMARY KEY,
text TEXT NOT NULL
) DEFAULT CHARSET=utf8
COLLATE=utf8_bin;

CREATE TABLE Bugs (
id INT UNSIGNED PRIMARY KEY,
tag TEXT COMMENT 'type "Tags"'
) DEFAULT CHARSET=utf8;

INSERT INTO Bugs (id, tag, tag.text) VALUES (1, "Linux","Linux strings.");
SQLでは、この指定ではテーブル名.カラム名と認識されるので、
Unknown column 'tag.text' in 'field list'と言われてしまいます。

あまり、理解できていないので、わかりづらくすいません。


以上です。



2013年8月23日 15:42 Kouhei Sutou <kou****@clear*****>:

> 須藤です。
>
> > このことから、実はgroongaの1カラムには最大データサイズの制限というのがあるんじゃないかなぁと思っています。
> > (たぶん最大インデックスと同じ256GB?)認識に間違いがなければ、ドキュメントに記載があると親切かもしれません。
> > 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:
>
> > お世話になっております。村上です。
> >
> > 度々の自己レスですいません。
> > 大きいサイズのカラムを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万レコード目ぐらいで必ず発生します。
> >>
> >> この制限に引っかかった場合、テーブルを水平分割せざるを得ないという認識でよろしいでしょうか?
> >> キーやサイズがでかすぎることが原因という場合は、大きいカラムをテーブル参照とかに
> >> 置き換えれば回避可能でしょうか?
> >>
> >> 以上、よろしくお願いします。
> >>
> >>
> >>
> > _______________________________________________
> > groonga-dev mailing list
> > groon****@lists*****
> > http://lists.sourceforge.jp/mailman/listinfo/groonga-dev
>
> _______________________________________________
> groonga-dev mailing list
> groon****@lists*****
> http://lists.sourceforge.jp/mailman/listinfo/groonga-dev
>



groonga-dev メーリングリストの案内
Back to archive index