Kentaro Hayashi
hayas****@clear*****
2016年 8月 29日 (月) 12:02:58 JST
Groonga 6.0.8をリリースしました！ http://groonga.org/ja/blog/2016/08/29/groonga-6-0-8.html # 変更内容 主な変更点は以下の通りです。 * 最大レコード数の制限が緩和され、もっとレコードを保存できることがわかりました * column_createでおかしなインデックスを作成したときのチェックができるようになりました * load時に型と値があっていないとエラーになるようになった 細かな変更点についてはニュースをご確認下さい。 http://groonga.org/ja/docs/news.html#release-6-0-8-2016-08-29 以下、主な変更点について紹介します。 #### 最大レコード数の制限が緩和され、もっとレコードを保存できることがわかりました 今回のリリースでは、最大レコード数の記述を見直しました。 従来、テーブルの最大レコード数については、約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」開催のお知らせ[1]という記事でも お伝えしましたが、来月末に日本語全文検索を取りあげたイベントが開催され ます。第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/ * 概要 MySQLで日本語全文検索する方法とその利用事例、PostgreSQLで日本語 全文検索する方法とその利用事例を紹介するイベントです。 興味があればぜひご参加ください！ [1] http://groonga.org/ja/blog/2016/08/17/mysql-and-postgresql-and-japanese-full-text-search3-announce.html ## 改良 * [object_list] value_size や n_elements といったメタデータのプロパ ティを表示できるようにしました。 * セレクタごとにオペレータを指定できるようになりました。この変更でセ レクタごとにインデックスを正しく選択できるようになりました。例えば between() が範囲検索のためのインデックスを選択したり、 in_values() が等価比較のためのインデックスを選択したりできるようになりました。 [GitHub#589] [村上さんが報告] * [debian] これまではGroongaの [log_reopen] コマンドを使っていました が、nginxのログを再オープンする機能を使うようにしました。これは log_reopen コマンドがワーカー1つのときだけきちんと動作するためです。 nginxのログを再オープンする機能は複数のワーカーに対しても問題なく 動作します。 * [table_copy] 指定したテーブルをコピーするための table_copy コマン ドを追加しました。 * [column_copy] 参照型のベクタをサポートしました。 * [admin] レスポンスがなくエラーになる場合に対応しました。 "Loading..."メッセージが表示されたままになる問題が解消します。 * [groonga 実行ファイル][http] 実装していない関数に対して400 Bad Requestを返すようにしました。 * [groonga-httpd] 失敗時にレスポンスボディを返すようにしました。 * [groonga-httpd] 大規模なデータをストリーム処理できるようになりまし た。 * key がインデックスカラムのソースカラムとして指定されているときに、 シーケンシャルサーチを _key でできるようになりました。 * ログレベルが info のときに、データカラムに対するアクセサが選んだイ ンデックスの情報を表示できるようになりました。 * [column_create] インデックスのソースを設定する際に、語彙表の妥当 性チェックを追加しました。もしユーザーが column_create で間違った インデックスを作成しようとすると、この妥当性チェックで詳細を表示 します。 * [doc] テーブルの制限に関する説明を更新しました。 ## 修正 * [column_create] ログを記録する際にバッファオーバーフローが発生する 不具合を修正しました。 * クリティカルなエラーが発生したときでも、レスポンスを出力するように しました。 * grn_ctx_send が呼ばれるたびに、出力バッファをクリアするようにしま した。ときどきレスポンスが壊れてしまう問題がおそらくこれで解決しま す。[GitHub#330] * [load] カラムの値を設定するときに失敗したらエラーを報告するように しました。カラムの型と実際の値が一致していないときに気づけるように なります。 * [groonga-httpd] 成功時に誤った HTTP ステータスが設定されている不具 合を修正しました。 * [fuzzy_search][in_values] シーケンシャルサーチでレコードIDを正しく 解決するようにしました。[GitHub#591,#592,#593] [村上さんがパッチ提 供] ## 感謝 * 村上さん -- Kentaro Hayashi <hayas****@clear*****> -------------- next part -------------- テキスト形式以外の添付ファイルを保管しました... ファイル名: 無し 型: application/pgp-signature サイズ: 801 バイト 説明: 無しDownload