BloGroonga

2016-08-29

Groonga 6.0.8リリース

Groonga 6.0.8をリリースしました！

それぞれの環境毎のインストール方法: インストール

変更内容

主な変更点は以下の通りです。

  • 最大レコード数の制限が緩和され、もっとレコードを保存できることがわかりました
  • column_createでおかしなインデックスを作成したときのチェックができるようになりました
  • load時に型と値があっていないとエラーになるようになった

最大レコード数の制限が緩和され、もっとレコードを保存できることがわかりました

今回のリリースでは、最大レコード数の記述を見直しました。

従来、テーブルの最大レコード数については、約2億6千万レコードとしていました。 再検証の結果、実際にはもっとレコードを格納できることがわかりました。2億じゃ足りないということでGroongaの採用を諦めていた人には朗報です。

テーブルのキーの型によって最大レコード数が次のように変わってきます。

  • TABLE_NO_KEY: 1,073,741,815 (2^30 - 9) (約10億7千万レコード)
  • TABLE_HASH_KEY: 536,870,912 (2^29) (約5億3千万レコード)
  • TABLE_PAT_KEY: 1,073,741,823 (2^30 - 1) (約10億7千万レコード)
  • TABLE_DAT_KEY: 268,435,455 (2^28 - 1) (約2億6千万レコード)

ただし、実際には他の諸条件の制約により上記の値まで到達しない場合もあります。

たとえば、大量のレコードを保存する場合はキーの型は小さいサイズの型を使う必要があります。なぜなら、最大レコード数の上限に達する前に最大総キーサイズの上限（4GiB）に達するからです。

もし、 UInt64 （8バイト）型を使って 2^29 レコード保存すると、総キーサイズは4GiB（= 8 * (2^29)）になります。この状態ではこれ以上レコードを追加できません。さらにレコードを保存したい場合は、キーのサイズを小さくする（たとえば UInt32 だと4バイト）か、 KEY_LARGE と TABLE_HASH_KEY を組みあわせて使うか、どちらかを選ぶことになります。

column_createでおかしなインデックスを作成したときのチェックができるようになりました

今回のリリースでは、不適切なインデックスカラムを作成しようとするとエラーとなるようになっています。

実際に、誤りの含まれているサンプルを試してみましょう。

table_create Tags TABLE_HASH_KEY ShortText

table_create Sites TABLE_HASH_KEY ShortText
column_create Sites tags COLUMN_VECTOR Tags

table_create TagsIndex TABLE_HASH_KEY ShortText
column_create TagsIndex sites_tags COLUMN_INDEX Sites tags

このサンプルでデータベースを構築してみましょう。

Groonga 6.0.7以前では次のように何もエラーが発生しません。

$ groonga -n testdb/db < sample.grn
[[0,1472192178.94475,0.006346225738525391],true]
[[0,1472192178.951148,0.006434917449951172],true]
[[0,1472192178.957618,0.009174346923828125],true]
[[0,1472192178.966841,0.006294727325439453],true]
[[0,1472192178.973179,0.01138973236083984],true]

Groonga 6.0.8を使うと、誤り（column_create TagsIndex sites_tags COLUMN_INDEX Sites tags）のある箇所で、エラーとなりました。

$ groonga -n testdb/db < sample.grn
[[0,1472192179.028527,0.00267481803894043],true]
[[0,1472192179.031259,0.002692937850952148],true]
[[0,1472192179.033985,0.004066228866577148],true]
[[0,1472192179.03809,0.002942562103271484],true]
[[-22,1472192179.041083,0.01088976860046387,"[column][index][source] index table must equal to source type: <TagsIndex> -> <Tags>: index-column:<TagsIndex.sites_tags> sourc",[["grn_obj_set_info_source_invalid_lexicon_error","db.c",8418]]],false]

エラーメッセージにもあるように、インデックスカラムのsites_tagsの定義で型が一致していません。 ここで問題となっているのは、ソースとして指定しているSitesテーブルのtagsカラム（参照型）で、その値の型はTagsです。しかし、ここでは語彙表にTagsではなく、TagIndexテーブルを使おうとしています。語彙表がTagsでない場合に正しく動作しません。

今回はこういった間違ったスキーマ定義をしてしまっているときに気づけるようになりました。

load時に型と値があっていないとエラーになるようになった

今回のリリースでは、load時に定義してある型と実際の値の型があっていないとエラーになるようになりました。

実際に、誤りの含まれているサンプルを試してみましょう。ageカラムはInt32の値を保持するのものなのに、文字列をloadさせようとしているのが誤っています。

table_create Users TABLE_NO_KEY
column_create Users age COLUMN_SCALAR Int32

load --table Users
[
{"age": "invalid number!"}
]

Groonga 6.0.7以前では次のようにエラーは発生しません。

$ groonga testdb/db < invalid.test
[[0,1472195681.942045,0.006659030914306641],true]
[[0,1472195681.948765,0.007688283920288086],true]
[[0,1472195681.956529,0.002389430999755859],1]
[[0,1472195681.958963,0.0009322166442871094],[[[1],[["_id","UInt32"],["age","Int32"]],[1,0]]]]

Groonga 6.0.8を使うと、誤りのある箇所で、エラーとなりました。

$ groonga -n testdb/db < invalid.test
[[0,1472195948.997128,0.005559444427490234],true]
[[0,1472195949.002747,0.007435083389282227],true]
[[-22,1472195949.01023,0.000843048095703125,"<Users.age>: failed to cast to <Int32>: <\"invalid number!\">",[["grn_obj_set_value_column_fix_size","db.c",7520]]],1]
[[0,1472195949.011117,0.000377655029296875],[[[1],[["_id","UInt32"],["age","Int32"]],[1,0]]]]

意図せず、誤ったデータをloadしようとしたときに気づけますね。

お知らせ

「MySQLとPostgreSQLと日本語全文検索3」開催のお知らせという記事でもお伝えしましたが、来月末に日本語全文検索を取りあげたイベントが開催されます。第3回となるイベントですが、今回でこのシリーズの最終回です。

興味があればぜひご参加ください！

さいごに

6.0.7からの詳細な変更点は6.0.8リリース 2016-08-29を確認してください。

それでは、Groongaでガンガン検索してください！