HAYASHI Kentaro
hayas****@clear*****
2014年 3月 29日 (土) 12:27:30 JST
林です。 今日は肉の日(3/29)ですね。先月は28日まででスキップしたので、しばらくぶりのリリースです。 Groonga 4.0.1をリリースしました！ http://groonga.org/ja/docs/news.html#release-4-0-1 それぞれの環境毎のインストール方法はこちらを見てください。 http://groonga.org/ja/docs/install.html 今回のリリースではデータベースのファイル形式に互換性のない変更がはいっています。 詳細はデータベースの肥大化のトピックを参照してください。 今回のリリースの主なトピックは次の通りです。 * データベースの肥大化を解消できるようになりました * 重みつきベクターカラムをサポートしました * 検索結果に対して重みを調整するadjusterオプションをサポートしました * [募集] コマンドリファレンスをいっしょに良いものにしませんか * [募集] groongaからGroongaへ 表記の統一を一緒にやってみませんか * [募集] 週刊Groongaの情報を海外向けに発信してみませんか ○ データベースの肥大化を解消できるようになりました 今回のリリースでは、データベースの肥大化を解消する仕組みが有効になりました。 前にもそんなことを聞いた気がする人がいるかもしれないので、 前回までの肥大化抑制のとりくみをおさらいしてみましょう。 * 3.1.0でGRN_JA_SKIP_SAME_VALUE_PUTを追加 同じ値なら更新をスキップすることで、新たに領域を確保せず肥大化を抑制する仕組みでした。 ただしまだ実験的な扱いで、使いたい人は明示的に設定を変更してくださいという扱いでした。 * 3.1.2でGRN_JA_SKIP_SAME_VALUE_PUT=yesが標準に それまで使いたい人がいたら使ってね、という扱いだったのを、必ず適用するようにしました。 これは、3.1.0で導入して以降、効果が認められたための措置です。 今回のリリースでは、可変長データの扱いを工夫することでデータベースの肥大化を解消できるように なりました。 詳細については、「Groongaでの可変長データの管理方法」が図入りでわかりやすいです。 Groongaでの可変長データの管理方法 http://www.clear-code.com/blog/2014/3/13.html ただし、後方互換とするために、肥大化抑制の恩恵を受けるためにはデータベースを新しくつくりなおす 必要があります。 まとめると * 4.0.0以前のデータベースは4.0.1でもそのまま開けます * ただし4.0.1のデータベースは以前のGroongaでは開けません * データベースを新しく作りなおすと肥大化抑制効果があります ということになります。 実際に肥大化抑制効果をongaeshiさんが検証してくれた結果がこちらのグラフです。 (このグラフもongaeshiさんが提供してくれました!ありがとうございます!) http://twitpic.com/dygc6d/full 以前のデータベースをそのまま継続して使っているとどんどん肥大化していっていますが(4.0.0-72-continue)、 データベースを新規につくりなおすと肥大化を抑制できていることがわかります。(4.0.0-72-new) ○ 重みつきベクターカラムをサポートしました 今回のリリースでは、ベクターカラムにキーと値のペアを複数格納できるようになりました。 これが重みつきベクターカラムです。 例えば、ユーザーの属性をタグ付けするのに、これまでだと"どんな属性か"というのは以下のようにして ベクターカラムを使って複数のタグ付けすることができました。 column_create Users tags COLUMN_VECTOR ShortText ただし、属性に偏りがあるばあいには、これだけでは不十分です。そのため属性に対応した重みは 属性ごとに別のカラムを追加して重みを格納するなどの工夫が必要でした。 (カラム定義だと次のようなイメージ) column_create Users tags COLUMN_VECTOR ShortText column_create Users tags_A COLUMN_SCALAR Int32 column_create Users tags_B COLUMN_SCALAR Int32 column_create Users tags_C COLUMN_SCALAR Int32... 重みつきベクターカラムをサポートしたことで、そういったカラムをひとつにまとめることができるようになりました。 (カラム定義だと次のようなイメージ) カラム定義で、WITH_WEIGHTを使うのがポイントです。 column_create Users tags COLUMN_VECTOR|WITH_WEIGHT ShortText こうすることで、次のようなキーと値のペアをベクターカラムに格納できるようになります。 {"タグA":重み1, "タグB":重み2, "タグC":重み3, ...} ○ 検索結果に対して重みを調整するadjusterオプションをサポートしました 今回のリリースでは、selectコマンドのオプションとしてadjusterオプションをサポートしました。 重みというと、これまででもmatch_columnでカラムに対する重みづけはできていたような、と思うかも 知れません。どんな違いがあるのかというと次のとおりです。 * match_column * マッチしているカラムの検索結果に対して重みづけをすることができる * adjuster * カラムの特定のキーについて重みづけをすることができる。 今回サポートされた重みつきベクターカラムとあわせて使うことで、よりきめこまかな検索を 行うことができます。 たとえば、Groongaをよく使っている人をリストアップしたいといった場合考えてみましょう。 よく使っている度合いを示す重みつきベクターカラムに格納しているとします。 サンプルとして使うスキーマ定義は次の通りです。 table_create User TABLE_HASH_KEY ShortText column_create User weight COLUMN_VECTOR|WITH_WEIGHT ShortText column_create User tags COLUMN_VECTOR ShortText table_create Weight TABLE_HASH_KEY ShortText column_create Weight weight_index COLUMN_INDEX|WITH_WEIGHT User weight table_create Tag TABLE_PAT_KEY ShortText column_create Tag tags_index COLUMN_INDEX User tags サンプルデータを次のようにしてロードします。 load --table User [ { "_key":"alice", "weight":{"Groonga":30, "Mroonga":20}, "tags": ["Groonga", "Mroonga"] }, { "_key":"bob", "weight":{"Groonga":50}, "tags": ["Groonga"] }, { "_key":"carol", "weight":{"Groonga":40,"Mroonga":30}, "tags": ["Groonga", "Mroonga"] } ] 単に、"Groonga"を使っているというだけなら次のようにして"tags"カラムに"Groonga"を含むレコードを検索すればよさそうです。 select User --output_columns _key,_score,* --sortby -_score --filter 'tags @ "Groonga"' しかし、欲しいのは使っている度合いに応じた結果です。そのためにadjusterオプションを次のようにして使います。 select User --output_columns _key,_score,* --sortby -_score --filter 'tags @ "Groonga"' --adjuster 'weight @ "Groonga" * 10' adjusterに渡しているパラメータは次のようになっています。 'weight @ "Groonga" * 10' これは、'weight'カラムに"Groonga"というキーワードがあるものの重みを10倍にする、ということを意味します。 そのため、重みを考慮したスコアの順に並びかえて結果を取得することができます。 Groongaの重みが大きい"bob"が一番上になりました。 ["bob",511,["Groonga"],{"Groonga":50}], ["carol",411,["Groonga","Mroonga"],{"Groonga":40,"Mroonga":30}], ["alice",311,["Groonga","Mroonga"],{"Groonga":30,"Mroonga":20}] Groongaだけじゃなくて、Mroongaも使っている人を重視したいなら、adjusterに"Mroonga"を指定すれば目的の結果が得られます。 select User --output_columns _key,_score,* --sortby -_score --filter 'tags @ "Groonga"' --adjuster 'weight @ "Mroonga" * 10' Mroongaの重みが大きい"carol"が一番上になりました。 ["carol",311,["Groonga","Mroonga"],{"Groonga":40,"Mroonga":30}], ["alice",211,["Groonga","Mroonga"],{"Groonga":30,"Mroonga":20}], ["bob",1,["Groonga"],{"Groonga":50}] ○ [募集] コマンドリファレンスをいっしょに良いものにしませんか APIのドキュメント化作業が一段落したので、次のステップとして コマンドリファレンスの改善作業をはじめました。 コマンドリファレンスは新規コマンドが追加されたり、機能が追加されたり する度に加筆修正していっているので、今では古いスタイルと 新しいスタイルとが混在している状態になっています。 これを新しいスタイルに統一しようというのが、このコマンドリファレンスの 改善作業の内容です。 ただ現状リソースが足りていないので、ユーザのみなさんにも協力していただけたらいいなと思っています。 具体的な作業手順の詳細については以下を参照してください。 もし、できそうだな、とかちょっとやってみよう、と思われたらぜひ参加して くれると嬉しいです。 http://groonga.org/ja/blog/2013/08/12/reference-command-documentation.html ○ [募集] groongaからGroongaへ 表記の統一を一緒にやってみませんか? リリースアナウンスや、公式ドキュメントをみてもうすでに気づいた人がいるかもしれませんが、 Groonga関連のソフトウェアの表記を「Groonga」（先頭が大文字）へ統一する作業をすすめています。 これは、世界中で広く使ってもらえることを視野に入れているからです。 それなりに分量があるので、ドキュメントに散らばっている「groonga」表記の統一をお手伝いしてくれる人を募集します。 コードを書かなくてもできる作業なので一緒にやってみませんか。 Groongaプロジェクトに名前を残せるチャンスですよ！ 具体的にどんなふうに作業をすすめたらいいかについては、エントリを書いたので、 そちらを参照してください。 http://groonga.org/ja/blog/2013/10/30/use-capitalized-notation.html すでに、yoku0825さんやcosmo0920さんが参加してくれています。 それらの成果はもちろん今回のリリースに反映されています。ありがとうござ います！ ○ [募集] 週刊Groongaの情報を海外向けに発信してみませんか 毎週木曜に Qiita http://qiita.com/ にてGroongaやMroonga,Rroongaなどの トピックを一つ投稿するという取り組みを続けています。 それなりにトピックがたまってきたので、これを翻訳して英語圏にも情報を発信して いこうかと考えています。 ただ、現状リソースがあまり足りていないので、ユーザのみなさんにも 翻訳作業を協力していただけたらいいなと思っています。 翻訳作業の詳細については以下を参照してください。 http://groonga.org/ja/blog/2013/07/22/qiita-translation.html ○ [参考] 隔週連載Groonga これまでも、groonga.orgにて利用事例 http://groonga.org/ja/users/ を 紹介してきましたが、それとは別に、http://gihyo.jp/にてGroonga関連の記事の連載を 隔週連載Groongaとしておよそ2013年4月から半年間連載しました。 まだGroongaを知らない人にもWebの連載記事を通じて知ってもらいたいとい うのが動機で始めましたが、この半年間でgroonga-devへの新規投稿が活発化する など、一定の成果をあげることができました。 ユーザーのみなさんの事例紹介の記事のおかげで、この企画を続けることが できました。ひとつの区切りとして連載は終了しましたが、ユーザー事例とその補足を 取り混ぜた連載です、ぜひ参考にしてみてください。 過去の記事(第1回から第10回)については隔週連載Groongaのページを参照してください。 http://gihyo.jp/dev/clip/01/groonga 似たような動機で、毎週木曜にQiitaでのGroonga関連の情報提供も続けています。 こちらも参考にどうぞ。 http://qiita.com/groonga ○ 変更点 さて、4.0.0からの変更点は以下の通りです。 http://groonga.org/ja/docs/news.html#release-4-0-1 改良 * [doc] 返り値のヘッダ詳細 (出力形式) についてのリンクを追加しました。 * JSONロード時のベクターの値とオブジェクトの値を表示できるようにしました。 ロードに失敗したときのデータの詳細がわかるようになりました。 * selectコマンドに adjuster オプションを追加しました。 adjusterオプションのシンタックスは INDEX_COLUMN @ STRING_LITERAL (* FACTOR) です。 * 重み付きベクターカラム をサポートしました。 重みつきベクターを使うにはカラム作成時に 'COLUMN_VECTOR|WITH_WEIGHT' を指定する必要があります。 * SunOSでビルドに必要なMIN/MAXの定義がなかったので追加しました。[GitHub#154] [Sebastian Wiedenrothさんがパッチ提供] * 使われなくなった領域を再利用するように改善しました。これによりデータべースの肥大化を抑制します。 * [doc] groonga-suggest-httpd のGETパラメータに関するドキュメントを追加しました。 * [doc] カラム のドキュメントを追加しました。 * [doc] ベクターカラム のドキュメントを追加しました。 * [column_list] 重みつきベクターカラムを表示できるようにしました。 * [column_create] マルチカラムインデックスを作成するときに、WITH_SECTIONフラグが指定されていない場合のエラーチェックを追加しました。 * [httpd] NginxHttpStubStatusModuleをgroonga-httpdで有効にしました。[長野雅広さんが提案] 修正 * 除算によるオーバーフローが発生する不具合を修正しました。 例えば、'COLUMN(最小値) / -1' をInt32やInt64で定義したカラムに適用すると発生します。[#2307] * 剰余演算 '%' ではなく、除算 '/' を行ってしまう不具合を修正しました。[#2307] * [doc] column_rename のドキュメントの説明の誤りを修正しました。[nise_nabeさんが報告] * 配列の領域外アクセスが発生しうる問題を修正しました。[GitHub#158] [dcb314さんが報告] 感謝 * nise_nabeさん * Sebastian Wiedenrothさん * 長野雅広さん * dcb314さん -- HAYASHI Kentaro <hayas****@clear*****>
