Kentaro Hayashi
null+****@clear*****
Fri Aug 26 16:27:10 JST 2016
Kentaro Hayashi 2016-08-26 16:27:10 +0900 (Fri, 26 Aug 2016) New Revision: 232a2796aec2698d5ebfb7ae26fd289ed222e8f7 https://github.com/groonga/groonga.org/commit/232a2796aec2698d5ebfb7ae26fd289ed222e8f7 Message: blog ja: add 6.0.8 entry Added files: ja/_posts/2016-08-29-groonga-6.0.8.md Added: ja/_posts/2016-08-29-groonga-6.0.8.md (+139 -0) 100644 =================================================================== --- /dev/null +++ ja/_posts/2016-08-29-groonga-6.0.8.md 2016-08-26 16:27:10 +0900 (d18403a) @@ -0,0 +1,139 @@ +--- +layout: post.ja +title: Groonga 6.0.8リリース +description: Groonga 6.0.8をリリースしました！ +published: false +--- + +## Groonga 6.0.8リリース + +[Groonga 6.0.8](/ja/docs/news.html#release-6-0-8)をリリースしました！ + +それぞれの環境毎のインストール方法: [インストール](/ja/docs/install.html) + +### 変更内容 + +主な変更点は以下の通りです。 + +* 最大レコード数の制限が緩和され、もっとレコードを保存できることがわかりました +* column_createでおかしなインデックスを作成したときのチェックができるようになりました +* load時に型と値があっていないとエラーになるようになった + +#### 最大レコード数の制限が緩和され、もっとレコードを保存できることがわかりました + +今回のリリースでは、最大レコード数の記述を見直しました。 + +従来、[テーブルの最大レコード数](/ja/docs/limitations.html)については、約2億6千万レコードとしていました。 +再検証の結果、実際にはもっとレコードを格納できることがわかりました。2億じゃ足りないということでGroongaの採用を諦めていた人には朗報です。 + +テーブルのキーの型によって最大レコード数が次のように変わってきます。 + +* [TABLE_NO_KEY](/ja/docs/reference/tables.html#table-no-key): 1,073,741,815 (2^30 - 9) (約10億7千万レコード) +* [TABLE_HASH_KEY](/ja/docs/reference/tables.html#table-hash-key): 536,870,912 (2^29) (約5億3千万レコード) +* [TABLE_PAT_KEY](/ja/docs/reference/tables.html#table-pat-key): 1,073,741,823 (2^30 - 1) (約10億7千万レコード) +* [TABLE_DAT_KEY](/ja/docs/reference/tables.html#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」開催のお知らせ](/ja/blog/2016/08/17/mysql-and-postgresql-and-japanese-full-text-search3-announce.html)という記事でもお伝えしましたが、来月末に日本語全文検索を取りあげたイベントが開催されます。第3回となるイベントですが、今回でこのシリーズの最終回です。 + +* [MySQLとPostgreSQLと日本語全文検索3](https://groonga.doorkeeper.jp/events/50541) + * 2016-09-29（金）19:30 - 21:30 [DMM.comラボ 東京都渋谷区恵比寿4-20-3 恵比寿ガーデンプレイスタワー21階](http://labo.dmm.com/about/access/) （DMM.comラボ） + * MySQLで日本語全文検索する方法とその利用事例、PostgreSQLで日本語全文検索する方法とその利用事例を紹介するイベントです。 + +興味があればぜひご参加ください！ + +### さいごに + +6.0.7からの詳細な変更点は[6.0.8リリース 2016-08-29](/ja/docs/news.html#release-6-0-8)を確認してください。 + +それでは、Groongaでガンガン検索してください！ -------------- next part -------------- HTML����������������������������...Download