お知らせ - 11系#
11.1.3リリース - 2022-01-29#
改良#
[snippet] 32個以上のキーワードを使えるようにしました。 [GitHub#1313][Takashi Hashidaさんがパッチ提供]
いままで、
snippetは32個以上のキーワードを指定できませんでしたが、この改良によって、以下のように32個以上のキーワードを指定できます。table_create Entries TABLE_NO_KEY column_create Entries content COLUMN_SCALAR ShortText load --table Entries [ {"content": "Groonga is a fast and accurate full text search engine based on inverted index. One of the characteristics of Groonga is that a newly registered document instantly appears in search results. Also, Groonga allows updates without read locks. These characteristics result in superior performance on real-time applications.\nGroonga is also a column-oriented database management system (DBMS). Compared with well-known row-oriented systems, such as MySQL and PostgreSQL, column-oriented systems are more suited for aggregate queries. Due to this advantage, Groonga can cover weakness of row-oriented systems.\nThe basic functions of Groonga are provided in a C library. Also, libraries for using Groonga in other languages, such as Ruby, are provided by related projects. In addition, groonga-based storage engines are provided for MySQL and PostgreSQL. These libraries and storage engines allow any application to use Groonga. See usage examples."}, {"content": "In widely used DBMSs, updates are immediately processed, for example, a newly registered record appears in the result of the next query. In contrast, some full text search engines do not support instant updates, because it is difficult to dynamically update inverted indexes, the underlying data structure.\nGroonga also uses inverted indexes but supports instant updates. In addition, Groonga allows you to search documents even when updating the document collection. Due to these superior characteristics, Groonga is very flexible as a full text search engine. Also, Groonga always shows good performance because it divides a large task, inverted index merging, into smaller tasks."} ] select Entries \ --output_columns ' \ snippet(content, \ "groonga", "inverted", "index", "fast", "full", "text", "search", "engine", "registered", "document", \ "results", "appears", "also", "system", "libraries", "for", "mysql", "postgresql", "column-oriented", "dbms", \ "basic", "ruby", "projects", "storage", "allow", "application", "usage", "sql", "well-known", "real-time", \ "weakness", "merging", "performance", "superior", "large", "dynamically", "difficult", "query", "examples", "divides", \ { \ "default_open_tag": "[", \ "default_close_tag": "]", \ "width" : 2048 \ })' [ [ 0, 1643165838.691991, 0.0003311634063720703 ], [ [ [ 2 ], [ [ "snippet", null ] ], [ [ "[Groonga] is a [fast] and accurate [full] [text] [search] [engine] based on [inverted] [index]. One of the characteristics of [Groonga] is that a newly [registered] [document] instantly [appears] in [search] [results]. [Also], [Groonga] [allow]s updates without read locks. These characteristics result in [superior] [performance] on [real-time] [application]s.\n[Groonga] is [also] a [column-oriented] database management [system] ([DBMS]). Compared with [well-known] row-oriented [system]s, such as [MySQL] and [PostgreSQL], [column-oriented] [system]s are more suited [for] aggregate queries. Due to this advantage, [Groonga] can cover [weakness] of row-oriented [system]s.\nThe [basic] functions of [Groonga] are provided in a C library. [Also], [libraries] [for] using [Groonga] in other languages, such as [Ruby], are provided by related [projects]. In addition, [groonga]-based [storage] [engine]s are provided [for] [MySQL] and [PostgreSQL]. These [libraries] and [storage] [engine]s [allow] any [application] to use [Groonga]. See [usage] [examples]." ] ], [ [ "In widely used [DBMS]s, updates are immediately processed, [for] example, a newly [registered] record [appears] in the result of the next [query]. In contrast, some [full] [text] [search] [engine]s do not support instant updates, because it is [difficult] to [dynamically] update [inverted] [index]es, the underlying data structure.\n[Groonga] [also] uses [inverted] [index]es but supports instant updates. In addition, [Groonga] [allow]s you to [search] [document]s even when updating the [document] collection. Due to these [superior] characteristics, [Groonga] is very flexible as a [full] [text] [search] [engine]. [Also], [Groonga] always shows good [performance] because it [divides] a [large] task, [inverted] [index] [merging], into smaller tasks." ] ] ] ] ]
[NormalizerNFKC130] 新しいオプション
remove_symbolを追加しました。このオプションは、以下のように正規化対象の文字列から記号(例えば #, !, ", &, % 等)を削除します。
normalize 'NormalizerNFKC130("remove_symbol", true)' "#This & is %% a pen." WITH_TYPES [ [ 0, 1643595008.729597, 0.0005540847778320312 ], { "normalized": "this is a pen", "types": [ "alpha", "alpha", "alpha", "alpha", "others", "others", "alpha", "alpha", "others", "others", "alpha", "others", "alpha", "alpha", "alpha" ], "checks": [ ] } ]
[AlmaLinux] ARM64版 AlmaLinux 8 向けのパッケージをサポートしました。
[httpd] バンドルしているnginxのバージョンを1.21.5に更新しました。
[Documentation] ruby_eval の誤記を修正しました。[GitHub#1317][wi24rdさんがパッチ提供]
[Ubuntu] Ubuntu 21.04 (Hirsute Hippo)サポートをやめました。
Ubuntu 21.04 は、2022年1月20日でEOLとなったためです。
修正#
[load] 存在しないカラムを指定してロードした時にクラッシュする問題を修正しました。
この問題は、
loadの引数として、input_typeにapache-arrowを指定したときのみ発生します。Groongaが依存している arrow-libs がバージョンアップしたことによって、Groongaのバージョンアップが失敗する問題を修正しました。[groonga-talk,540][Josep Sanzさんの報告][Gitter,61eaaa306d9ba23328d23ce1][shibanao4870さんの報告][GitHub#1316][Keitaro YOSHIMURAさんの報告]
ただし、 arrow-libs がメジャーバージョンアップした場合は、この問題は再発します。その場合は、Groongaパッケージを再構築して対応する予定です。
既知の問題#
現在Groongaには、ベクターカラムに対してデータを大量に追加、削除、更新した際にデータが破損することがある問題があります。
*<と*>は、filter条件の右辺にquery()を使う時のみ有効です。もし、以下のように指定した場合、*<と*>は&&として機能します。'content @ "Groonga" *< content @ "Mroonga"'
GRN_II_CURSOR_SET_MIN_ENABLEが原因でマッチするはずのレコードを返さないことがあります。
感謝#
Takashi Hashidaさん
wi24rdさん
Josep Sanzさん
Keitaro YOSHIMURAさん
shibanao4870さん
11.1.1リリース - 2021-12-29#
改良#
[select] 組み合わせフレーズ近傍検索をサポートしました。
この機能は、
'*NP"..." OR *NP"..." OR ...'の短縮形です。例えば、以下のように、queryを使って*NPを複数実行する式のかわりに*NPPを使えます。query ("title * 10 || content", "*NP"a 1 x" OR *NP"a 1 y" OR *NP"a 1 z" OR *NP"a 2 x" OR *NP"a 2 y" OR *NP"a 2 z" OR *NP"a 3 x" OR *NP"a 3 y" OR *NP"a 3 z" OR *NP"b 1 x" OR *NP"b 1 y" OR *NP"b 1 z" OR *NP"b 2 x" OR *NP"b 2 y" OR *NP"b 2 z" OR *NP"b 3 x" OR *NP"b 3 y" OR *NP"b 3 z"")
この機能によって、上記の式を
*NPP"(a b) (1 2 3) (x y z)"と書くことができます。加えて、*NPP"(a b) (1 2 3) (x y z)"は、'*NP"..." OR *NP"..." OR ...'より高速です。query ("title * 10 || content", "*NPP"(a b) (1 2 3) (x y z)"")
この機能は、
'*NP"..." OR *NP"..." OR ...'のような近傍フレーズ検索のパフォーマンスを改善するために実装されました。[select] 順序付き組み合わせフレーズ近傍検索をサポートしました。
この機能は、
'*ONP"..." OR *ONP"..." OR ...'の短縮形です。例えば、以下のように、queryを使って*ONPを複数実行する式のかわりに*ONPPを使えます。query ("title * 10 || content", "*ONP"a 1 x" OR *ONP"a 1 y" OR *ONP"a 1 z" OR *ONP"a 2 x" OR *ONP"a 2 y" OR *ONP"a 2 z" OR *ONP"a 3 x" OR *ONP"a 3 y" OR *ONP"a 3 z" OR *ONP"b 1 x" OR *ONP"b 1 y" OR *ONP"b 1 z" OR *ONP"b 2 x" OR *ONP"b 2 y" OR *ONP"b 2 z" OR *ONP"b 3 x" OR *ONP"b 3 y" OR *ONP"b 3 z"")
この機能によって、上記の式を
*ONPP"(a b) (1 2 3) (x y z)"と書くことができます。加えて、*ONPP"(a b) (1 2 3) (x y z)"は、'*ONP"..." OR *ONP"..." OR ...'より高速です。query ("title * 10 || content", "*ONPP"(a b) (1 2 3) (x y z)"")
この機能は
'*ONP"..." OR *ONP"..." OR ...'のような順序付き近傍フレーズ検索のパフォーマンスを改善するために実装されました。[request_cancel] 検索実行中に
request_cancelを検知しやすくしました。request_cancelを検知するために、リターンコードのチェックを増やしたためです。[thread_dump] 新しいコマンド
thread_dumpを追加しました。現状、このコマンドはWindowsでしか動作しません。
このコマンド実行時の全てのスレッドのバックトレースをNOTICEレベルのログとして出力できます。
この機能は、Groongaが応答を返さない等の問題を解決するのに役立ちます。
[CentOS] CentOS 8のサポートをやめました。
CentOS 8は、2021年12月31日でEOLとなるためです。
修正#
無効なパラメータを持つインデックスカラムを削除できない問題を修正しました。 [GitHub#1301][Takashi Hashidaさんがパッチ提供]
例えば、以下のように
column_createを使って無効なインデックスカラムを作成した時、テーブルが削除できなくなります。table_create Statuses TABLE_NO_KEY column_create Statuses start_time COLUMN_SCALAR UInt16 column_create Statuses end_time COLUMN_SCALAR UInt16 table_create Times TABLE_PAT_KEY UInt16 column_create Times statuses COLUMN_INDEX Statuses start_time,end_time [ [ -22, 1639037503.16114, 0.003981828689575195, "grn_obj_set_info(): GRN_INFO_SOURCE: multi column index must be created with WITH_SECTION flag: <Times.statuses>", [ [ "grn_obj_set_info_source_validate", "../../groonga/lib/db.c", 9605 ], [ "/tmp/d.grn", 6, "column_create Times statuses COLUMN_INDEX Statuses start_time,end_time" ] ] ], false ] table_remove Times [ [ -22, 1639037503.16515, 0.0005414485931396484, "[object][remove] column is broken: <Times.statuses>", [ [ "remove_columns", "../../groonga/lib/db.c", 10649 ], [ "/tmp/d.grn", 8, "table_remove Times" ] ] ], false ]
既知の問題#
現在Groongaには、ベクターカラムに対してデータを大量に追加、削除、更新した際にデータが破損することがある問題があります。
*<と*>は、filter条件の右辺にquery()を使う時のみ有効です。もし、以下のように指定した場合、*<と*>は&&として機能します。'content @ "Groonga" *< content @ "Mroonga"'
GRN_II_CURSOR_SET_MIN_ENABLEが原因でマッチするはずのレコードを返さないことがあります。
感謝#
Takashi Hashidaさん
11.1.0リリース - 2021-11-29#
改良#
[load] ISO 8601 形式をサポートしました。[GitHub#1228][Takashi Hashidaさんがパッチ提供]
この変更によって、
loadは、以下のフォーマットをサポートします。YYYY-MM-ddThh:mm:ss.sZ
YYYY-MM-ddThh:mm:ss.s+10:00
YYYY-MM-ddThh:mm:ss.s-10:00
この構文の
TとZの代わりにtとzを使うこともできます。-の代わりに/を使うこともできます。ただし、/は、ISO 8601 形式ではないことに注意してください。/は互換性のためにサポートしています。plugin_register functions/time table_create Logs TABLE_NO_KEY column_create Logs case COLUMN_SCALAR ShortText column_create Logs created_at COLUMN_SCALAR Time column_create Logs created_at_text COLUMN_SCALAR ShortText load --table Logs [ {"case": "timezone: Z", "created_at": "2000-01-01T10:00:00Z", "created_at_text": "2000-01-01T10:00:00Z"}, {"case": "timezone: z", "created_at": "2000-01-01t10:00:00z", "created_at_text": "2000-01-01T10:00:00z"}, {"case": "timezone: 00:00", "created_at": "2000-01-01T10:00:00+00:00", "created_at_text": "2000-01-01T10:00:00+00:00"}, {"case": "timezone: +01:01", "created_at": "2000-01-01T11:01:00+01:01", "created_at_text": "2000-01-01T11:01:00+01:01"}, {"case": "timezone: +11:11", "created_at": "2000-01-01T21:11:00+11:11", "created_at_text": "2000-01-01T21:11:00+11:11"}, {"case": "timezone: -01:01", "created_at": "2000-01-01T08:59:00-01:01", "created_at_text": "2000-01-01T08:59:00-01:01"}, {"case": "timezone: -11:11", "created_at": "1999-12-31T22:49:00-11:11", "created_at_text": "1999-12-31T22:49:00-11:11"}, {"case": "timezone hour threshold: +23:00", "created_at": "2000-01-02T09:00:00+23:00", "created_at_text": "2000-01-02T09:00:00+23:00"}, {"case": "timezone minute threshold: +00:59", "created_at": "2000-01-01T10:59:00+00:59", "created_at_text": "2000-01-01T10:59:00+00:59"}, {"case": "timezone omitting minute: +01", "created_at": "2000-01-01T11:00:00+01", "created_at_text": "2000-01-01T11:00:00+01"}, {"case": "timezone omitting minute: -01", "created_at": "2000-01-01T09:00:00-01", "created_at_text": "2000-01-01T09:00:00-01"}, {"case": "timezone: localtime", "created_at": "2000-01-01T19:00:00", "created_at_text": "2000-01-01T19:00:00"}, {"case": "compatible: date delimiter: /", "created_at": "2000/01/01T10:00:00Z", "created_at_text": "2000/01/01T10:00:00Z"}, {"case": "decimal", "created_at": "2000-01-01T11:01:00.123+01:01", "created_at_text": "2000-01-01T11:01:00.123+01:01"} ] select Logs \ --limit -1 \ --output_columns "case, time_format_iso8601(created_at), created_at_text" [ [ 0, 0.0, 0.0 ], [ [ [ 14 ], [ [ "case", "ShortText" ], [ "time_format_iso8601", null ], [ "created_at_text", "ShortText" ] ], [ "timezone: Z", "2000-01-01T19:00:00.000000+09:00", "2000-01-01T10:00:00Z" ], [ "timezone: z", "2000-01-01T19:00:00.000000+09:00", "2000-01-01T10:00:00z" ], [ "timezone: 00:00", "2000-01-01T19:00:00.000000+09:00", "2000-01-01T10:00:00+00:00" ], [ "timezone: +01:01", "2000-01-01T19:00:00.000000+09:00", "2000-01-01T11:01:00+01:01" ], [ "timezone: +11:11", "2000-01-01T19:00:00.000000+09:00", "2000-01-01T21:11:00+11:11" ], [ "timezone: -01:01", "2000-01-01T19:00:00.000000+09:00", "2000-01-01T08:59:00-01:01" ], [ "timezone: -11:11", "2000-01-01T19:00:00.000000+09:00", "1999-12-31T22:49:00-11:11" ], [ "timezone hour threshold: +23:00", "2000-01-01T19:00:00.000000+09:00", "2000-01-02T09:00:00+23:00" ], [ "timezone minute threshold: +00:59", "2000-01-01T19:00:00.000000+09:00", "2000-01-01T10:59:00+00:59" ], [ "timezone omitting minute: +01", "2000-01-01T19:00:00.000000+09:00", "2000-01-01T11:00:00+01" ], [ "timezone omitting minute: -01", "2000-01-01T19:00:00.000000+09:00", "2000-01-01T09:00:00-01" ], [ "timezone: localtime", "2000-01-01T19:00:00.000000+09:00", "2000-01-01T19:00:00" ], [ "compatible: date delimiter: /", "2000-01-01T19:00:00.000000+09:00", "2000/01/01T10:00:00Z" ], [ "decimal", "2000-01-01T19:00:00.123000+09:00", "2000-01-01T11:01:00.123+01:01" ] ] ] ]
[select] 新しい
query_flagsDISABLE_PREFIX_SEARCHを追加しました。以下のように、
DISABLE_PREFIX_SEARCHによって、前方一致検索の演算子の^と*を検索キーワードとして使えます。この機能は、
^や*を含むドキュメントを検索したい時に便利です。table_create Users TABLE_PAT_KEY ShortText load --table Users [ {"_key": "alice"}, {"_key": "alan"}, {"_key": "ba*"} ] select Users \ --match_columns "_key" \ --query "a*" \ --query_flags "DISABLE_PREFIX_SEARCH" [[0,0.0,0.0],[[[1],[["_id","UInt32"],["_key","ShortText"]],[3,"ba*"]]]]
table_create Users TABLE_PAT_KEY ShortText load --table Users [ {"_key": "alice"}, {"_key": "alan"}, {"_key": "^a"} ] select Users \ --query "_key:^a" \ --query_flags "ALLOW_COLUMN|DISABLE_PREFIX_SEARCH" [[0,0.0,0.0],[[[1],[["_id","UInt32"],["_key","ShortText"]],[3,"^a"]]]]
[select] 新しい
query_flagsDISABLE_AND_NOTを追加しました。以下のように、
DISABLE_AND_NOTによって、AND NOTの演算子の-を検索キーワードとして使えます。この機能は、
-を含むドキュメントを検索したい時に便利です。table_create Users TABLE_PAT_KEY ShortText load --table Users [ {"_key": "alice"}, {"_key": "bob"}, {"_key": "cab-"} ] select Users --match_columns "_key" --query "b - a" --query_flags "DISABLE_AND_NOT" [[0,0.0,0.0],[[[1],[["_id","UInt32"],["_key","ShortText"]],[3,"cab-"]]]]
修正#
[ブラウザーベースの管理ツール] レコード一覧の管理モードのチェックボックスにチェックを入れても、非管理モードに入力された検索クエリーが送信される問題を修正しました。 [Github#1186][Takashi Hashidaさんがパッチ提供]
既知の問題#
現在Groongaには、ベクターカラムに対してデータを大量に追加、削除、更新した際にデータが破損することがある問題があります。
*<と*>は、filter条件の右辺にquery()を使う時のみ有効です。もし、以下のように指定した場合、*<と*>は&&として機能します。'content @ "Groonga" *< content @ "Mroonga"'
GRN_II_CURSOR_SET_MIN_ENABLEが原因でマッチするはずのレコードを返さないことがあります。
感謝#
Takashi Hashidaさん
11.0.9リリース - 2021-11-04#
改良#
[snippet] 正規表現を使ってスニペットの区切り文字を見つける新しいオプション
delimiter_regexpを追加しました。snippet は、検索キーワードの周辺のテキストを抽出します。 snippet で抽出したテキストをスニペットと呼びます。
通常、 snippet は、検索キーワードの周辺の200byteのテキストを返しますが、 snippet は、センテンスの区切りを考慮しません。スニペットは、複数のセンテンスで構成されることがあります。
delimiter_regexpオプションは、検索キーワードと同じセンテンスのテキストのみを抽出したいときに便利です。例えば、以下のように、\.\s*を使って対象のセンテンス内のテキストのみを抽出できます。文字列は、\でエスケープする必要があることに注意してください。table_create Documents TABLE_NO_KEY column_create Documents content COLUMN_SCALAR Text table_create Terms TABLE_PAT_KEY ShortText --default_tokenizer TokenBigram --normalizer NormalizerAuto column_create Terms documents_content_index COLUMN_INDEX|WITH_POSITION Documents content load --table Documents [ ["content"], ["Groonga is a fast and accurate full text search engine based on inverted index. One of the characteristics of groonga is that a newly registered document instantly appears in search results. Also, groonga allows updates without read locks. These characteristics result in superior performance on real-time applications."], ["Groonga is also a column-oriented database management system (DBMS). Compared with well-known row-oriented systems, such as MySQL and PostgreSQL, column-oriented systems are more suited for aggregate queries. Due to this advantage, groonga can cover weakness of row-oriented systems."] ] select Documents \ --output_columns 'snippet(content, \ { \ "default_open_tag": "[", \ "default_close_tag": "]", \ "delimiter_regexp": "\\\\.\\\\s*" \ })' \ --match_columns content \ --query "fast performance" [ [ 0, 1337566253.89858, 0.000355720520019531 ], [ [ [ 1 ], [ [ "snippet", null ] ], [ [ "Groonga is a [fast] and accurate full text search engine based on inverted index", "These characteristics result in superior [performance] on real-time applications" ] ] ] ] ]
[window_rank] 新しい関数
window_rank()を追加しました。ギャップを含む各レコードの順位を計算できます。通常、順位は、複数のレコードが同じ順位の時は増加しません。例えば、ソートキーの値が 100、 100、 200の場合、これらの順位は 1、 1、 3です。1位のレコードが2つあるので、最後のレコードの順位は2ではなく3です。
これは、 window_record_number と似ていますが、 window_record_number はギャップを考慮しません。
table_create Points TABLE_NO_KEY column_create Points game COLUMN_SCALAR ShortText column_create Points score COLUMN_SCALAR UInt32 load --table Points [ ["game", "score"], ["game1", 100], ["game1", 200], ["game1", 100], ["game1", 400], ["game2", 150], ["game2", 200], ["game2", 200], ["game2", 200] ] select Points \ --columns[rank].stage filtered \ --columns[rank].value 'window_rank()' \ --columns[rank].type UInt32 \ --columns[rank].window.sort_keys score \ --output_columns 'game, score, rank' \ --sort_keys score [ [ 0, 1337566253.89858, 0.000355720520019531 ], [ [ [ 8 ], [ [ "game", "ShortText" ], [ "score", "UInt32" ], [ "rank", "UInt32" ] ], [ "game1", 100, 1 ], [ "game1", 100, 1 ], [ "game2", 150, 3 ], [ "game2", 200, 4 ], [ "game2", 200, 4 ], [ "game1", 200, 4 ], [ "game2", 200, 4 ], [ "game1", 400, 8 ] ] ] ]
[in_values] テーブル検索時に自動的にキャストするようにしました。
例えば、 キーの型が
UInt64のテーブルにUInt32の値をロードした場合、Groongaは、in_values()でテーブルを検索するときに自動的に値をUInt64にキャストします。ただ、in_values(_key, 10)はこの機能の対象外です。10は、Int32として解釈されるためです。table_create Numbers TABLE_HASH_KEY UInt64 load --table Numbers [ {"_key": 100}, {"_key": 200}, {"_key": 300} ] select Numbers --output_columns _key --filter 'in_values(_key, 200, 100)' --sortby _id [[0,0.0,0.0],[[[2],[["_key","UInt64"]],[100],[200]]]]
[httpd] バンドルしているnginxのバージョンを1.21.3に更新しました。
[AlmaLinux] AlmaLinux 8 向けのパッケージをサポートしました。
[Ubuntu] Ubuntu 21.10 (Impish Indri)をサポートしました。
修正#
Groongaがコマンドエラー(例えば、filterのシンタックスエラー)発生時に応答を返さない問題を修正しました。
これは、
--output_type apache-arrowを使っているときのみ発生します。
既知の問題#
現在Groongaには、ベクターカラムに対してデータを大量に追加、削除、更新した際にデータが破損することがある問題があります。
[ブラウザーベースの管理ツール] 現在Groongaには、レコード一覧の管理モードのチェックボックスにチェックを入れても、非管理モードに入力された検索クエリーが送信されるという問題があります。
*<と*>は、filter条件の右辺にquery()を使う時のみ有効です。もし、以下のように指定した場合、*<と*>は&&として機能します。'content @ "Groonga" *< content @ "Mroonga"'
GRN_II_CURSOR_SET_MIN_ENABLEが原因でマッチするはずのレコードを返さないことがあります。
11.0.7リリース - 2021-09-29#
改良#
[load] "[int, int,...]" のような文字列を [int, int,...] のような整数のベクターにキャストするようにしました。
例えば、以下のように、"[1, -2]" のようなベクターを文字列としてロードしたとしても、 [1, -2] のように整数のベクターとして扱います。
table_create Data TABLE_NO_KEY column_create Data numbers COLUMN_VECTOR Int16 table_create Numbers TABLE_PAT_KEY Int16 column_create Numbers data_numbers COLUMN_INDEX Data numbers load --table Data [ {"numbers": "[1, -2]"}, {"numbers": "[-3, 4]"} ] dump --dump_plugins no --dump_schema no load --table Data [ ["_id","numbers"], [1,[1,-2]], [2,[-3,4]] ] column_create Numbers data_numbers COLUMN_INDEX Data numbers select Data --filter 'numbers @ -2' [[0,0.0,0.0],[[[1],[["_id","UInt32"],["numbers","Int16"]],[1,[1,-2]]]]]
この機能は以下の型をサポートします。
Int8
UInt8
Int16
UInt16
Int32
UInt32
Int64
UInt64
[load] 文字列として表現されたJSON配列を文字列のベクターとしてロードできるようにしました。
例えば、以下のように "["hello", "world"]" のような文字列として表現されたJSON配列をロードした場合、 ["hello", "world"] のように2つの要素を持つベクターとして扱います。
table_create Data TABLE_NO_KEY [[0,0.0,0.0],true] column_create Data strings COLUMN_VECTOR ShortText [[0,0.0,0.0],true] table_create Terms TABLE_PAT_KEY ShortText --normalizer NormalizerNFKC130 --default_tokenizer TokenNgram [[0,0.0,0.0],true] column_create Terms data_strings COLUMN_INDEX Data strings [[0,0.0,0.0],true] load --table Data [ {"strings": "[\"Hello\", \"World\"]"}, {"strings": "[\"Good-bye\", \"World\"]"} ] [[0,0.0,0.0],2] dump --dump_plugins no --dump_schema no load --table Data [ ["_id","strings"], [1,["Hello","World"]], [2,["Good-bye","World"]] ] column_create Terms data_strings COLUMN_INDEX Data strings select Data --filter 'strings @ "bye"' [ [ 0, 0.0, 0.0 ], [ [ [ 1 ], [ [ "_id", "UInt32" ], [ "strings", "ShortText" ] ], [ 2, [ "Good-bye", "World" ] ] ] ] ]
以前のバージョンでは、 "["hello", "world"]" のような文字列として表現されたJSON配列をロードした場合は、 ["["hello", "world"]"] のような一つの要素を持つベクターとして扱っていました。
[Documentation] 以下の項目についてのドキュメントを追加しました。
[column_create]
WEIGHT_FLOAT32フラグについてのドキュメントを追加しました。[NormalizerNFKC121]
NormalizerNFKC121についてのドキュメントを追加しました。[NormalizerNFKC130]
NormalizerNFKC130についてのドキュメントを追加しました。[NormalizerTable]
NormalizerTableについてのドキュメントを追加しました。
Groongaが要求する Apache Arrow のバージョンを 3.0.0 に更新しました。[GitHub#1265][Takashi Hashidaさんがパッチ提供]
修正#
テーブル作成時に無効なオプションを持つトークナイザーを指定するとメモリーリークする問題を修正しました。
Hashテーブルに新しいエントリーを追加できなくなることがある問題を修正しました。
このバグは、Groonga 11.0.6 でのみ発生し、頻繁にデータを追加、削除すると発生することがあります。もし、このバグが発生した場合は、以下の手順を実行することで、この問題を解決できます。
Groongaを11.0.6から11.0.7以降にアップグレードします。
元のテーブルと同じスキーマを持つ新しいテーブルを作ります。
元のテーブルから新しいテーブルにデータをコピーします。
[Windows] メモリー不足によって、新しくファイルのオープンに失敗した時にリソースリークする問題を修正しました。
既知の問題#
現在Groongaには、ベクターカラムに対してデータを大量に追加、削除、更新した際にデータが破損することがある問題があります。
[ブラウザーベースの管理ツール] 現在Groongaには、レコード一覧の管理モードのチェックボックスにチェックを入れても、非管理モードに入力された検索クエリーが送信されるという問題があります。
*<と*>は、filter条件の右辺にquery()を使う時のみ有効です。もし、以下のように指定した場合、*<と*>は&&として機能します。'content @ "Groonga" *< content @ "Mroonga"'
GRN_II_CURSOR_SET_MIN_ENABLEが原因でマッチするはずのレコードを返さないことがあります。
感謝#
Takashi Hashidaさん
11.0.6リリース - 2021-08-29#
警告
Groonga 11.0.6 には、Hashテーブルに新しいエントリーを追加できなくなることがある問題があります。
この問題は、Groonga 11.0.7で修正しました。この問題は、Groonga 11.0.6でのみ発生します。したがって、Groonga 11.0.6をお使いの方は、Groonga 11.0.7以降を使うことを強くおすすめします。
改良#
クラッシュ時に自動でリカバリーする機能を追加しました。(実験的な機能です。)
この機能は実験的な機能です。現状、この機能はまだ安定していません。
この機能によって、Groongaがクラッシュした時、Groongaはクラッシュした後、最初のデータベースオープン時に自動的にデータベースをリカバリーします。ただ、全てのクラッシュケースで自動的にデータベースをリカバリーできるわけではありません。クラッシュのタイミングによっては、手動でデータベースのリカバリーが必要になります。
この機能が有効な時、GroongaはWAL(ログ先行書き込み)を実行します。以下のツールを使うことでWALをダンプできますが、現状これらをユーザーが使う必要はありません。
[grndb]
dump-walコマンドdump-wal.rbスクリプト
[cache_limit]
cache_limit 0を実行したときにキャッシュを削除するようにしました。[GitHub#1224][higchiさんからの報告]Groongaは内部的なテーブルにクエリーキャッシュを保存しています。このテーブルは、ハッシュテーブルなので、トータルのキーサイズは最大で4GiBです。そのため、もし多くの巨大なクエリーを実行した場合、トータルのキーサイズの最大値4GiBを超え、Groongaがクエリーをキャッシュできない可能性があります。このようなケースで、
cache_limit 0を実行することで、クエリーキャッシュ用のテーブルをクリアーし、Groongaがクエリーキャッシュを保存できるようにします。
修正#
同時期に複数のスレッドで同じオブジェクトをオープンした時に、Groongaがロックを解除しない問題を修正しました。
同時期に複数のスレッドが同じオブジェクトをオープンすると、最初にオブジェクトを開いたスレッド以外のスレッドは対象のオブジェクトが開かれるまで待ちます。この時、対象のオブジェクトが開かれるのを待っているスレッドもロックを取得しますが、これらのロックは解放されません。したがって、Groongaのプロセスを再起動するまでこれらのロックが残り、その新しいスレッドは、Groongaが再起動するまで、そのオブジェクトを開けません。
ただ、スレッドがオブジェクトを開く時間は非常に短いため、このバグは滅多に起こりません。
[query_parallel_or]
query()と結果が異なることがある問題を修正しました。例えば、
query("tags || tags2", "beginner man")とした場合は、以下のレコードはマッチしますが、query_parallel_or("tags || tags2", "beginner man")とした場合は、今までは、以下のレコードはマッチしませんでした。{"_key": "Bob", "comment": "Hey!", "tags": ["expert", "man"], "tags2": ["beginner"]}
今回の変更によって、
query_parallel_or("tags || tags2", "beginner man")を使った場合であっても、上記のレコードがマッチするようになりました。
既知の問題#
現在Groongaには、ベクターカラムに対してデータを大量に追加、削除、更新した際にデータが破損することがある問題があります。
[ブラウザーベースの管理ツール] 現在Groongaには、レコード一覧の管理モードのチェックボックスにチェックを入れても、非管理モードに入力された検索クエリーが送信されるという問題があります。
*<と*>は、filter条件の右辺にquery()を使う時のみ有効です。もし、以下のように指定した場合、*<と*>は&&として機能します。'content @ "Groonga" *< content @ "Mroonga"'
GRN_II_CURSOR_SET_MIN_ENABLEが原因でマッチするはずのレコードを返さないことがあります。
感謝#
higchiさん
11.0.5リリース - 2021-07-29#
改良#
[ノーマライザー] ノーマライザーを複数指定できるようになりました。
テーブル作成時に
--normalizersオプションを使うことで、複数のノーマライザーを指定できます。互換性のため、既存の--normalizerを使っても複数のノーマライザーを指定できます。Groonga 11.0.4 でノーマライザーをカスタマイズするための
NormalizerTableを追加しました。このNormalizerTableと既存のノーマライザーを組み合わせることでより柔軟な制御ができます。例えば、この機能は、以下のようなケースで有用です。
電話番号を検索します。ただし、データはOCRで手書きのデータを取り込みます。OCRは数字と文字列をご認識することがあります。(例えば、 5とS など)
具体的には以下の通りです。
table_create Normalizations TABLE_PAT_KEY ShortText column_create Normalizations normalized COLUMN_SCALAR ShortText load --table Normalizations [ {"_key": "s", "normalized": "5"} ] table_create Tels TABLE_NO_KEY column_create Tels tel COLUMN_SCALAR ShortText table_create TelsIndex TABLE_PAT_KEY ShortText \ --normalizers 'NormalizerNFKC130("unify_hyphen_and_prolonged_sound_mark", true), \ NormalizerTable("column", "Normalizations.normalized")' \ --default_tokenizer 'TokenNgram("loose_symbol", true, "loose_blank", true)' column_create TelsIndex tel_index COLUMN_INDEX|WITH_SECTION Tels tel load --table Tels [ {"tel": "03-4S-1234"} {"tel": "03-45-9876"} ] select --table Tels \ --filter 'tel @ "03-45-1234"' [ [ 0, 1625227424.560146, 0.0001730918884277344 ], [ [ [ 1 ], [ [ "_id", "UInt32" ], [ "tel", "ShortText" ] ], [ 1, "03-4S-1234" ] ] ] ]
既存のノーマライザーでは、このようなケースには対応できませんでしたが、このリリースから既存のノーマライザーと
NormalizerTableを組み合わせることで、このようなケースにも対応できます。[query_parallel_or][query] シーケンシャルサーチのしきい値をカスタマイズできるようにしました。
以下のオプションを使うことで、シーケンシャルサーチを使うかどうかのしきい値をクエリーごとにカスタマイズできます。
{"max_n_enough_filtered_records": xx}max_n_enough_filtered_recordsは、レコード数を指定します。queryまたは、query_parallel_orで、この値以下までレコードが絞り込めそうな場合、シーケンシャルサーチを使います。{"enough_filtered_ratio": x.x}enough_filtered_ratioは、全体に占める割合を指定します。queryまたは、query_parallel_orで、この割合以下までレコードが絞り込めそうな場合、シーケンシャルサーチを使います。例えば、{"enough_filtered_ratio": 0.5}とした場合、queryまたはquery_parallel_orで全体の半分まで絞り込めそうな場合はシーケンシャルサーチを使います。
具体的には以下の通りです。
table_create Products TABLE_NO_KEY column_create Products name COLUMN_SCALAR ShortText table_create Terms TABLE_PAT_KEY ShortText --normalizer NormalizerAuto column_create Terms products_name COLUMN_INDEX Products name load --table Products [ ["name"], ["Groonga"], ["Mroonga"], ["Rroonga"], ["PGroonga"], ["Ruby"], ["PostgreSQL"] ] select \ --table Products \ --filter 'query("name", "r name:Ruby", {"enough_filtered_ratio": 0.5})'
table_create Products TABLE_NO_KEY column_create Products name COLUMN_SCALAR ShortText table_create Terms TABLE_PAT_KEY ShortText --normalizer NormalizerAuto column_create Terms products_name COLUMN_INDEX Products name load --table Products [ ["name"], ["Groonga"], ["Mroonga"], ["Rroonga"], ["PGroonga"], ["Ruby"], ["PostgreSQL"] ] select \ --table Products \ --filter 'query("name", "r name:Ruby", {"max_n_enough_filtered_records": 10})'
[between][in_values] シーケンシャルサーチのしきい値をカスタマイズできるようにしました。
[between] と [in_values] は、検索対象のレコードが十分に絞り込まれている時に、シーケンシャルサーチに切り替える機能があります。
GRN_IN_VALUES_TOO_MANY_INDEX_MATCH_RATIO/GRN_BETWEEN_TOO_MANY_INDEX_MATCH_RATIOの値は、Groongaがシーケンシャルサーチを実行するかインデックスを使った検索をするかのしきい値として使われます。今までは、以下の環境変数でのみカスタマイズ可能でした。
in_values():# Don't use auto sequential search GRN_IN_VALUES_TOO_MANY_INDEX_MATCH_RATIO=-1 # Set threshold to 0.02 GRN_IN_VALUES_TOO_MANY_INDEX_MATCH_RATIO=0.02
between():# Don't use auto sequential search GRN_BETWEEN_TOO_MANY_INDEX_MATCH_RATIO=-1 # Set threshold to 0.02 GRN_BETWEEN_TOO_MANY_INDEX_MATCH_RATIO=0.02
環境変数によるカスタマイズは、すべてのクエリーに対して適用されますが、この機能を使うことで、クエリーごとにしきい値を指定できます。
具体的には以下の通りです。
{"too_many_index_match_ratio": x.xx}オプションでしきい値を指定できます。このオプションの値の型はdouble型です。table_create Memos TABLE_HASH_KEY ShortText column_create Memos timestamp COLUMN_SCALAR Time table_create Times TABLE_PAT_KEY Time column_create Times memos_timestamp COLUMN_INDEX Memos timestamp load --table Memos [ {"_key": "001", "timestamp": "2014-11-10 07:25:23"}, {"_key": "002", "timestamp": "2014-11-10 07:25:24"}, {"_key": "003", "timestamp": "2014-11-10 07:25:25"}, {"_key": "004", "timestamp": "2014-11-10 07:25:26"}, {"_key": "005", "timestamp": "2014-11-10 07:25:27"}, {"_key": "006", "timestamp": "2014-11-10 07:25:28"}, {"_key": "007", "timestamp": "2014-11-10 07:25:29"}, {"_key": "008", "timestamp": "2014-11-10 07:25:30"}, {"_key": "009", "timestamp": "2014-11-10 07:25:31"}, {"_key": "010", "timestamp": "2014-11-10 07:25:32"}, {"_key": "011", "timestamp": "2014-11-10 07:25:33"}, {"_key": "012", "timestamp": "2014-11-10 07:25:34"}, {"_key": "013", "timestamp": "2014-11-10 07:25:35"}, {"_key": "014", "timestamp": "2014-11-10 07:25:36"}, {"_key": "015", "timestamp": "2014-11-10 07:25:37"}, {"_key": "016", "timestamp": "2014-11-10 07:25:38"}, {"_key": "017", "timestamp": "2014-11-10 07:25:39"}, {"_key": "018", "timestamp": "2014-11-10 07:25:40"}, {"_key": "019", "timestamp": "2014-11-10 07:25:41"}, {"_key": "020", "timestamp": "2014-11-10 07:25:42"}, {"_key": "021", "timestamp": "2014-11-10 07:25:43"}, {"_key": "022", "timestamp": "2014-11-10 07:25:44"}, {"_key": "023", "timestamp": "2014-11-10 07:25:45"}, {"_key": "024", "timestamp": "2014-11-10 07:25:46"}, {"_key": "025", "timestamp": "2014-11-10 07:25:47"}, {"_key": "026", "timestamp": "2014-11-10 07:25:48"}, {"_key": "027", "timestamp": "2014-11-10 07:25:49"}, {"_key": "028", "timestamp": "2014-11-10 07:25:50"}, {"_key": "029", "timestamp": "2014-11-10 07:25:51"}, {"_key": "030", "timestamp": "2014-11-10 07:25:52"}, {"_key": "031", "timestamp": "2014-11-10 07:25:53"}, {"_key": "032", "timestamp": "2014-11-10 07:25:54"}, {"_key": "033", "timestamp": "2014-11-10 07:25:55"}, {"_key": "034", "timestamp": "2014-11-10 07:25:56"}, {"_key": "035", "timestamp": "2014-11-10 07:25:57"}, {"_key": "036", "timestamp": "2014-11-10 07:25:58"}, {"_key": "037", "timestamp": "2014-11-10 07:25:59"}, {"_key": "038", "timestamp": "2014-11-10 07:26:00"}, {"_key": "039", "timestamp": "2014-11-10 07:26:01"}, {"_key": "040", "timestamp": "2014-11-10 07:26:02"}, {"_key": "041", "timestamp": "2014-11-10 07:26:03"}, {"_key": "042", "timestamp": "2014-11-10 07:26:04"}, {"_key": "043", "timestamp": "2014-11-10 07:26:05"}, {"_key": "044", "timestamp": "2014-11-10 07:26:06"}, {"_key": "045", "timestamp": "2014-11-10 07:26:07"}, {"_key": "046", "timestamp": "2014-11-10 07:26:08"}, {"_key": "047", "timestamp": "2014-11-10 07:26:09"}, {"_key": "048", "timestamp": "2014-11-10 07:26:10"}, {"_key": "049", "timestamp": "2014-11-10 07:26:11"}, {"_key": "050", "timestamp": "2014-11-10 07:26:12"} ] select Memos \ --filter '_key == "003" && \ between(timestamp, \ "2014-11-10 07:25:24", \ "include", \ "2014-11-10 07:27:26", \ "exclude", \ {"too_many_index_match_ratio": 0.03})'
table_create Tags TABLE_HASH_KEY ShortText table_create Memos TABLE_HASH_KEY ShortText column_create Memos tag COLUMN_SCALAR Tags load --table Memos [ {"_key": "Rroonga is fast!", "tag": "Rroonga"}, {"_key": "Groonga is fast!", "tag": "Groonga"}, {"_key": "Mroonga is fast!", "tag": "Mroonga"}, {"_key": "Groonga sticker!", "tag": "Groonga"}, {"_key": "Groonga is good!", "tag": "Groonga"} ] column_create Tags memos_tag COLUMN_INDEX Memos tag select \ Memos \ --filter '_id >= 3 && \ in_values(tag, \ "Groonga", \ {"too_many_index_match_ratio": 0.7})' \ --output_columns _id,_score,_key,tag
[between]
GRN_EXPR_OPTIMIZE=yesをサポートしました。between()で、条件式の評価順序の最適化をサポートしました。[query_parallel_or][query] match_columns を vector で指定できるようにしました。[GitHub#1238][naoaさんがパッチ提供]
以下のように、
queryとquery_parallel_orのmatch_columnsに vector を使えます。table_create Users TABLE_NO_KEY column_create Users name COLUMN_SCALAR ShortText column_create Users memo COLUMN_SCALAR ShortText column_create Users tag COLUMN_SCALAR ShortText table_create Terms TABLE_PAT_KEY ShortText \ --default_tokenizer TokenNgram \ --normalizer NormalizerNFKC130 column_create Terms name COLUMN_INDEX|WITH_POSITION Users name column_create Terms memo COLUMN_INDEX|WITH_POSITION Users memo column_create Terms tag COLUMN_INDEX|WITH_POSITION Users tag load --table Users [ {"name": "Alice", "memo": "Groonga user", "tag": "Groonga"}, {"name": "Bob", "memo": "Rroonga user", "tag": "Rroonga"} ] select Users \ --output_columns _score,name \ --filter 'query(["name * 100", "memo", "tag * 10"], \ "Alice OR Groonga")'
[select] 前方一致検索でセクションと重みをサポートしました。[GitHub#1240][naoaさんがパッチ提供]
前方一致検索でマルチカラムインデックスと、スコアーの調整ができます。
table_create Memos TABLE_NO_KEY column_create Memos title COLUMN_SCALAR ShortText column_create Memos tags COLUMN_VECTOR ShortText table_create Terms TABLE_PAT_KEY ShortText column_create Terms index COLUMN_INDEX|WITH_SECTION Memos title,tags load --table Memos [ {"title": "Groonga", "tags": ["Groonga"]}, {"title": "Rroonga", "tags": ["Groonga", "Rroonga", "Ruby"]}, {"title": "Mroonga", "tags": ["Groonga", "Mroonga", "MySQL"]} ] select Memos \ --match_columns "Terms.index.title * 2" \ --query 'G*' \ --output_columns title,tags,_score [ [ 0, 0.0, 0.0 ], [ [ [ 1 ], [ [ "title", "ShortText" ], [ "tags", "ShortText" ], [ "_score", "Int32" ] ], [ "Groonga", [ "Groonga" ], 2 ] ] ] ]
[grndb]
grndb recoverで使用したオブジェクトを即時閉じるようにしました。これにより、メモリ消費を抑制できます。おそらくパフォーマンスは低下していますが、許容可能な低下です。
grndb checkはまだ、使用したオブジェクトを即時閉じないので注意してください。[query_parallel_or][query] 以下のように、
match_columnsにscorer_tf_idfを指定できるようにしました。table_create Tags TABLE_HASH_KEY ShortText table_create Users TABLE_HASH_KEY ShortText column_create Users tags COLUMN_VECTOR Tags load --table Users [ {"_key": "Alice", "tags": ["beginner", "active"]}, {"_key": "Bob", "tags": ["expert", "passive"]}, {"_key": "Chris", "tags": ["beginner", "passive"]} ] column_create Tags users COLUMN_INDEX Users tags select Users \ --output_columns _key,_score \ --sort_keys _id \ --command_version 3 \ --filter 'query_parallel_or("scorer_tf_idf(tags)", \ "beginner active")' { "header": { "return_code": 0, "start_time": 0.0, "elapsed_time": 0.0 }, "body": { "n_hits": 1, "columns": [ { "name": "_key", "type": "ShortText" }, { "name": "_score", "type": "Float" } ], "records": [ [ "Alice", 2.098612308502197 ] ] } }
[query_expand] 展開後の語の重みを操作できるようにしました。
展開後の語に対して、重みを指定できます。
スコアーを増やしたい場合は、
>を使います。スコアーを減らしたい場合は、<を指定します。数字でスコアーの量を指定できます。負の数も指定できます。
table_create TermExpansions TABLE_NO_KEY column_create TermExpansions term COLUMN_SCALAR ShortText column_create TermExpansions expansions COLUMN_VECTOR ShortText load --table TermExpansions [ {"term": "Rroonga", "expansions": ["Rroonga", "Ruby Groonga"]} ] query_expand TermExpansions "Groonga <-0.2Rroonga Mroonga" \ --term_column term \ --expanded_term_column expansions [[0,0.0,0.0],"Groonga <-0.2((Rroonga) OR (Ruby Groonga)) Mroonga"]
[httpd] バンドルしているnginxのバージョンを1.21.1に更新しました。
バンドルしているApache Arrowを5.0.0に更新しました。
[Ubuntu] Ubuntu 20.10 (Groovy Gorilla)サポートをやめました。
Ubuntu 20.10 は、2021年7月22日でEOLとなったためです。
修正#
[query_parallel_or][query]
query_optionsとその他のオプションを指定すると、その他のオプションが無視される問題を修正しました。例えば、以下のケースでは、
"default_operator": "OR"オプションは無視されていました。plugin_register token_filters/stop_word table_create Memos TABLE_NO_KEY column_create Memos content COLUMN_SCALAR ShortText table_create Terms TABLE_PAT_KEY ShortText \ --default_tokenizer TokenBigram \ --normalizer NormalizerAuto \ --token_filters TokenFilterStopWord column_create Terms memos_content COLUMN_INDEX|WITH_POSITION Memos content column_create Terms is_stop_word COLUMN_SCALAR Bool load --table Terms [ {"_key": "and", "is_stop_word": true} ] load --table Memos [ {"content": "Hello"}, {"content": "Hello and Good-bye"}, {"content": "and"}, {"content": "Good-bye"} ] select Memos \ --filter 'query_parallel_or( \ "content", \ "Hello and", \ {"default_operator": "OR", \ "options": {"TokenFilterStopWord.enable": false}})' \ --match_escalation_threshold -1 \ --sort_keys -_score [ [ 0, 0.0, 0.0 ], [ [ [ 1 ], [ [ "_id", "UInt32" ], [ "content", "ShortText" ] ], [ 2, "Hello and Good-bye" ] ] ] ]
既知の問題#
現在Groongaには、ベクターカラムに対してデータを大量に追加、削除、更新した際にデータが破損することがある問題があります。
[ブラウザーベースの管理ツール] 現在Groongaには、レコード一覧の管理モードのチェックボックスにチェックを入れても、非管理モードに入力された検索クエリーが送信されるという問題があります。
*<と*>は、filter条件の右辺にquery()を使う時のみ有効です。もし、以下のように指定した場合、*<と*>は&&として機能します。'content @ "Groonga" *< content @ "Mroonga"'
多くのデータを削除し、同じデータを再度loadすることを繰り返すと、Groongaがヒットすべきレコードを返さないことがあります。
感謝#
naoaさん
11.0.4リリース - 2021-06-29#
改良#
[Normalizer] カスタマイズされたノーマライザーを使えるようになりました。
この機能を使うためにノーマライズ用のテーブルを定義し、このテーブルを使ってノーマライズします。つまり、カスタマイズされたノーマライザーを使うことができます。
例えば、以下の例では、 "S" を "5" に正規化するよう定義しています。
Substitutionsテーブルが正規化用のテーブルです。table_create Substitutions TABLE_PAT_KEY ShortText column_create Substitutions substituted COLUMN_SCALAR ShortText load --table Substitutions [ {"_key": "S", "substituted": "5"} ] table_create TelLists TABLE_NO_KEY column_create TelLists tel COLUMN_SCALAR ShortText table_create Terms TABLE_HASH_KEY ShortText \ --default_tokenizer TokenNgram \ --normalizer 'NormalizerTable("column", "Substitutions.substituted", \ "report_source_offset", true)' column_create Terms tel_index COLUMN_INDEX|WITH_POSITION TelLists tel load --table TelLists [ {"tel": "03-4S-1234"} ] select TelLists --filter 'tel @ "03-45-1234"' [ [ 0, 1624686303.538532, 0.001319169998168945 ], [ [ [ 1 ], [ [ "_id", "UInt32" ], [ "tel", "ShortText" ] ], [ 1, "03-4S-1234" ] ] ] ]
例えば、手書きの文字を取り込む際に誤認識されやすい語を定義できます。そうすることで、誤ったデータを正規化して正しいデータにできます。
この正規化用のテーブルを更新した場合は、インデックスの再構築が必要なことに注意してください。
新しいコマンド
object_warmを追加しました。このコマンドは、GroongaのDBをOSのページキャッシュに乗せます。
OS起動後、Groongaを一度も起動していない場合、GroongaのDBはOSのページキャッシュ上に存在しません。そのため、Groongaに対する最初の操作は遅くなります。
予めこのコマンドを実行した場合、Groongaへの最初の操作は速くなります。Linuxでは、
cat *.db > dev/nullで同等のことができますが、Windowsでは、いままで、同様のことはできませんでした。このコマンドを使うことで、LinuxでもWindowsでもGroongaのDBをOSのページキャッシュへ乗せることができます。また、テーブル、カラム、インデックス単位でも同様のことができます。したがって、よく使うテーブルやカラム、インデックスのみをOSのページキャッシュに乗せることができます。
このコマンドは、以下のように様々な対象に対して実行できます。
object_warm --name index_nameと指定した場合は、指定したインデックスがOSのページキャッシュへ転送されます。object_warm --name column_nameと指定した場合は、指定したカラムがOSののページキャッシュへ転送されます。object_warm --name table_nameと指定した場合は、指定したテーブルをOSのページキャッシュへ転送します。object_warmと指定した場合は、GroongaのDB全体がOSのページキャッシュへ転送されます。
ただ、メモリーに空きスペースが無い場合は、このコマンドは効果がないことに注意してください。
[select]
--filter内で特定のレコードのスコアーを調整できるようにしました。*~という演算子を使うことで、特定のレコードのスコアーを調整できます。*~は&&や||と同じ論理演算子です。したがって、&&や||と同じように使えます。*~のデフォルトの重みは -1 です。したがって、例えば、
'content @ "Groonga" *~ content @ "Mroonga"'は以下の操作を意味します。'content @ "Groonga"とcontent @ "MySQL"にマッチしたレコードを抽出します。以下のようにスコアーを追加します。
'content @ "Groonga"のスコアーを計算します。content @ "Mroonga"'のスコアーを計算します。bのスコアーを -1 倍します。
このレコードのスコアーは a + b です。したがって、 aのスコアー 1 で bのスコアーが1 の場合、このレコードのスコアーは 1 + (1 * -1) = 0 です。
また、
*~${score_quantity}とすることで、スコアーの量を指定できます。具体的には、 以下の条件(
'content @ "Groonga" *~2.5 content @ "MySQL"') にマッチしたレコードのスコアーを調整します。table_create Memos TABLE_NO_KEY column_create Memos content COLUMN_SCALAR ShortText table_create Terms TABLE_PAT_KEY ShortText \ --default_tokenizer TokenBigram \ --normalizer NormalizerAuto column_create Terms index COLUMN_INDEX|WITH_POSITION Memos content load --table Memos [ {"content": "Groonga is a full text search engine."}, {"content": "Rroonga is the Ruby bindings of Groonga."}, {"content": "Mroonga is a MySQL storage engine based of Groonga."} ] select Memos \ --command_version 3 \ --filter 'content @ "Groonga" *~2.5 content @ "Mroonga"' \ --output_columns 'content, _score' \ --sort_keys -_score,_id { "header": { "return_code": 0, "start_time": 1624605205.641078, "elapsed_time": 0.002965450286865234 }, "body": { "n_hits": 3, "columns": [ { "name": "content", "type": "ShortText" }, { "name": "_score", "type": "Float" } ], "records": [ [ "Groonga is a full text search engine.", 1.0 ], [ "Rroonga is the Ruby bindings of Groonga.", 1.0 ], [ "Mroonga is a MySQL storage engine based of Groonga.", -1.5 ] ] } }
adjuster を使っても同様のことができます。adjuster を使う場合、アプリケーション上で、
--filter条件と--adjuster条件を作る必要がありますが、この改良で、--filter条件のみを作成すればよくなりました。以下のように、
query()を使って、filter条件を記述することもできます。--filter 'content @ "Groonga" *~2.5 content @ "Mroonga"'
[select] 重み付き
&&をサポートしました。*<と*>を使うことで、重み付きの&&を使えます。*<のデフォルトの重みは 0.5です。*>のデフォルトの重みは 2.0 です。*<${score_quantity}や*>${score_quantity}とすることで、スコアーの量を指定できます。また、*<${score_quantity}と指定した場合は、 ${score_quantity} の正負の符号が反転します。例えば、
'content @ "Groonga" *<2.5 query("content", "MySQL")'は以下の操作を意味します。'content @ "Groonga"とcontent @ "MySQL"にマッチしたレコードを抽出します。以下のようにスコアーを追加します。
'content @ "Groonga"のスコアーを計算します。query("content", "MySQL")のスコアーを計算します。bのスコアーは、
*<によって -2.5倍されます。このレコードのスコアーは a + b です。したがって、 aのスコアー 1 で bのスコアーが1 の場合、このレコードのスコアーは 1 + (1 * -2.5) = −1.5 です。
具体的には、 以下の条件(
'content @ "Groonga" *~2.5 query("content", "MySQL")'にマッチしたレコードのスコアーを調整します。table_create Memos TABLE_NO_KEY column_create Memos content COLUMN_SCALAR ShortText table_create Terms TABLE_PAT_KEY ShortText \ --default_tokenizer TokenBigram \ --normalizer NormalizerAuto column_create Terms index COLUMN_INDEX|WITH_POSITION Memos content load --table Memos [ {"content": "Groonga is a full text search engine."}, {"content": "Rroonga is the Ruby bindings of Groonga."}, {"content": "Mroonga is a MySQL storage engine based of Groonga."} ] select Memos \ --command_version 3 \ --filter 'content @ "Groonga" *<2.5 query("content", "Mroonga")' \ --output_columns 'content, _score' \ --sort_keys -_score,_id { "header": { "return_code": 0, "start_time": 1624605205.641078, "elapsed_time": 0.002965450286865234 }, "body": { "n_hits": 3, "columns": [ { "name": "content", "type": "ShortText" }, { "name": "_score", "type": "Float" } ], "records": [ [ "Groonga is a full text search engine.", 1.0 ], [ "Rroonga is the Ruby bindings of Groonga.", 1.0 ], [ "Mroonga is a MySQL storage engine based of Groonga.", -1.5 ] ] } }
[ログ] 標準出力、標準エラー出力への出力をサポートしました。
[プロセスログ] と [クエリーログ] が標準出力と標準エラー出力への出力をサポートしました。
--log-path -や--query-log-path -と指定した場合、Groongaはログを標準出力に出力します。--log-path +や--query-log-path +と指定した場合、Groongaはログを標準エラー出力に出力します。
[プロセスログ] はGroongaの動作全てに関することのログです。 [クエリーログ] は、クエリー処理に関することだけのログです。
この機能はDocker上でGroongaを実行する際に有用です。Dockerは標準で標準出力と標準エラー出力を記録する機能を持っています。したがって、Groongaのログを取得するために、Dockerの環境にログインする必要がなくなります。
例えば、この機能は、以下のようなケースで有用です。
Docker上のGroongaのスロークエリーを解析したい場合。
Groonga起動時に
--query-log-path -と指定している場合、以下のコマンドを実行するだけでスロークエリーを解析できます。docker logs ${container_name} | groonga-query-log-analyze
このように、 Groonga上のDockerから出力したクエリーログを使って、簡単にスロークエリの解析ができます。
[ドキュメント]
string_substringに不足している内容を追加しました。[Github#1209][Takashi Hashidaさんがパッチ提供]
既知の問題#
現在Groongaには、ベクターカラムに対してデータを大量に追加、削除、更新した際にデータが破損することがある問題があります。
[ブラウザーベースの管理ツール] 現在Groongaには、レコード一覧の管理モードのチェックボックスにチェックを入れても、非管理モードに入力された検索クエリーが送信されるという問題があります。
*<と*>は、filter条件の右辺にquery()を使う時のみ有効です。もし、以下のように指定した場合、*<と*>は&&として機能します。'content @ "Groonga" *< content @ "Mroonga"'
感謝#
Takashi Hashidaさん
11.0.3リリース - 2021-05-29#
改良#
[query] クエリー毎に
TokenFilterStemを無効にできるようになりました。TokenFilterStemは語幹を使った検索ができます。例えばdevelopもdevelopingもdevelopedもdevelopsも、すべてステミングするとdevelopになります。そのため、developsというクエリーでdevelopもdevelopingもdevelopedも検索できます。今回のリリースでは、以下のように特定のクエリーでのみ
TokenFilterStemを無効にして検索できるようになりました。plugin_register token_filters/stem table_create Memos TABLE_NO_KEY column_create Memos content COLUMN_SCALAR ShortText table_create Terms TABLE_PAT_KEY ShortText \ --default_tokenizer TokenBigram \ --normalizer NormalizerAuto \ --token_filters 'TokenFilterStem("keep_original", true)' column_create Terms memos_content COLUMN_INDEX|WITH_POSITION Memos content load --table Memos [ {"content": "I develop Groonga"}, {"content": "I'm developing Groonga"}, {"content": "I developed Groonga"} ] select Memos \ --match_columns content \ --query '"developed groonga"' \ --query_options '{"TokenFilterStem.enable": false}' [ [ 0, 0.0, 0.0 ], [ [ [ 1 ], [ [ "_id", "UInt32" ], [ "content", "ShortText" ] ], [ 3, "I developed Groonga" ] ] ] ]
この機能は、通常は語幹を使った検索がしたいが、時々、以下のように(ステミングされていない)正確な語で検索したいときに有用です。
ステミングされた語を使った検索だとGroongaが大量の検索結果を返す場合。
TokenFilerStemが間違ったステミング結果を返す場合。(ステミングされていない)正確な語を含むレコードのみを検索したい場合。
[query] クエリー毎に
TokenFilterStopWordを無効にできるようになりました。TokenFilterStopWordは、予め登録したストップワードを検索から除外します。これは、andやisなどの頻出語を無視することで検索ノイズを減らすために使います。ただ、ときどき、特定のクエリーでのみこれらの語を含めて検索したいときがあります。今回のリリースでは、以下のように特定のクエリーでのみ
TokenFilterStopWordを無効にして検索できるようになりました。plugin_register token_filters/stop_word table_create Memos TABLE_NO_KEY column_create Memos content COLUMN_SCALAR ShortText table_create Terms TABLE_PAT_KEY ShortText \ --default_tokenizer TokenBigram \ --normalizer NormalizerAuto \ --token_filters TokenFilterStopWord column_create Terms memos_content COLUMN_INDEX|WITH_POSITION Memos content column_create Terms is_stop_word COLUMN_SCALAR Bool load --table Terms [ {"_key": "and", "is_stop_word": true} ] load --table Memos [ {"content": "Hello"}, {"content": "Hello and Good-bye"}, {"content": "Good-bye"} ] select Memos \ --match_columns content \ --query "Hello and" \ --query_options '{"TokenFilterStopWord.enable": false}' \ --match_escalation_threshold -1 \ --sort_keys -_score [ [ 0, 0.0, 0.0 ], [ [ [ 1 ], [ [ "_id", "UInt32" ], [ "content", "ShortText" ] ], [ 2, "Hello and Good-bye" ] ] ] ]
上記の例では、
--query-optionsを使って、TokenFilterStopWord.enableを指定していますが、以下のように{"options": {"TokenFilterStopWord.enable": false}}を使っても指定できます。plugin_register token_filters/stop_word table_create Memos TABLE_NO_KEY column_create Memos content COLUMN_SCALAR ShortText table_create Terms TABLE_PAT_KEY ShortText \ --default_tokenizer TokenBigram \ --normalizer NormalizerAuto \ --token_filters TokenFilterStopWord column_create Terms memos_content COLUMN_INDEX|WITH_POSITION Memos content column_create Terms is_stop_word COLUMN_SCALAR Bool load --table Terms [ {"_key": "and", "is_stop_word": true} ] load --table Memos [ {"content": "Hello"}, {"content": "Hello and Good-bye"}, {"content": "Good-bye"} ] select Memos \ --filter 'query("content", \ "Hello and", \ {"options": {"TokenFilterStopWord.enable": false}})' \ --match_escalation_threshold -1 \ --sort_keys -_score [ [ 0, 0.0, 0.0 ], [ [ [ 1 ], [ [ "_id", "UInt32" ], [ "content", "ShortText" ] ], [ 2, "Hello and Good-bye" ] ] ] ]
この機能は、よく使われる語を含めて検索しないとGroongaが正しい結果を返さない時に便利です。(例えば、曲名や店名等を検索する場合です。)
[ノーマライザー][NormalizerNFKC] 新しいオプション
remove_new_lineを追加しました。データを格納するテーブルのキーを正規化したい場合、そのテーブルにノーマライザーを設定しますが、通常ノーマライザーは改行を削除します。
ノーマライザーが改行を削除してしまうと、Groongaは改行のみのキーを扱えません。
このオプションを使うことで、改行のみのデータをキーとして登録できます。
[string_slice] 新しい関数
string_slice()を追加しました。 [Github#1177][Takashi Hashidaさんがパッチ提供]string_slice()は、文字列の部分文字列を抽出します。この関数を使うには、
functions/stringプラグインの登録が必要です。以下のように、引数によって２つの異なる抽出方法を使えます。
位置を使った抽出:
plugin_register functions/string table_create Memos TABLE_HASH_KEY ShortText load --table Memos [ {"_key": "Groonga"} ] select Memos --output_columns '_key, string_slice(_key, 2, 3)' [ [ 0, 1337566253.89858, 0.000355720520019531 ], [ [ [ 1 ], [ [ "_key", "ShortText" ], [ "string_slice", null ] ], [ "Groonga", "oon" ] ] ] ]
正規表現を使った抽出:
plugin_register functions/string table_create Memos TABLE_HASH_KEY ShortText load --table Memos [ {"_key": "Groonga"} ] select Memos --output_columns '_key, string_slice(_key, "(Gro+)(.*)", 2)' [ [p 0, 1337566253.89858, 0.000355720520019531 ], [ [ [ 1 ], [ [ "_key", "ShortText" ], [ "string_slice", null ] ], [ "Groonga", "nga" ] ] ] ]
[Ubuntu] Ubuntu 16.04 LTS (Xenial Xerus)のサポートをやめました。
Visual Studio 用の EditorConfig を追加しました。[GitHub#1191][Takashi Hashidaさんがパッチ提供]
多くの設定は、Visual Studio 専用です。
[httpd] バンドルしているnginxのバージョンを1.20.1に更新しました。
CVE-2021-23017のセキュリティの修正が含まれています。
修正#
オプションをサポートしているトークナイザーやノーマライザー、トークンフィルターが使われている際、多くの検索クエリーを送信するとGroongaが応答を返さなくなることがある問題を修正しました。
既知の問題#
現在Groongaには、ベクターカラムに対してデータを大量に追加、削除、更新した際にデータが破損することがある問題があります。
[ブラウザーベースの管理ツール] 現在Groongaには、レコード一覧の管理モードのチェックボックスにチェックを入れても、非管理モードに入力された検索クエリーが送信されるという問題があります。
感謝#
Takashi Hashidaさん
11.0.2リリース - 2021-05-10#
改良#
[Documentation]
ruby_loadコマンドのリファレンスを削除しました。 [GitHub#1172][Anthony M. Cookさんがパッチ提供]このコマンドはすでに削除されているためです。
[Debian GNU/Linux] Debian 11(Bullseye) をサポートしました。
[select]
--post_filterをサポートしました。以下のように、
filteredステージの動的カラムに対してpost_filterを使ってフィルターできます。table_create Items TABLE_NO_KEY column_create Items price COLUMN_SCALAR UInt32 load --table Items [ {"price": 100}, {"price": 150}, {"price": 200}, {"price": 250}, {"price": 300} ] select Items \ --filter "price >= 150" \ --columns[price_with_tax].stage filtered \ --columns[price_with_tax].type UInt32 \ --columns[price_with_tax].flags COLUMN_SCALAR \ --columns[price_with_tax].value "price * 1.1" \ --post_filter "price_with_tax <= 250" [ [ 0, 0.0, 0.0 ], [ [ [ 2 ], [ [ "_id", "UInt32" ], [ "price_with_tax", "UInt32" ], [ "price", "UInt32" ] ], [ 2, 165, 150 ], [ 3, 220, 200 ] ] ] ]
[select]
--slices[].post_filterをサポートしました。以下のように、
--slices[].filterの条件でフィルターされた結果に対してpost_filterを使えます。table_create Items TABLE_NO_KEY column_create Items price COLUMN_SCALAR UInt32 load --table Items [ {"price": 100}, {"price": 200}, {"price": 300}, {"price": 1000}, {"price": 2000}, {"price": 3000} ] select Items \ --slices[expensive].filter 'price >= 1000' \ --slices[expensive].post_filter 'price < 3000' [ [ 0, 0.0, 0.0 ], [ [ [ 6 ], [ [ "_id", "UInt32" ], [ "price", "UInt32" ] ], [ 1, 100 ], [ 2, 200 ], [ 3, 300 ], [ 4, 1000 ], [ 5, 2000 ], [ 6, 3000 ] ], { "expensive": [ [ 2 ], [ [ "_id", "UInt32" ], [ "price", "UInt32" ] ], [ 4, 1000 ], [ 5, 2000 ] ] } ] ]
[select]
--sort_keys内に式を記述できるようになりました。--sort_keysに式を記述できます。存在しないキーが sort_keys の式に含まれていた場合、それらは、無視され警告がログに出力されます。
これによって、例えば、
--sort_keysにVECTOR_COLUMNの要素を指定し、VECTOR_COLUMNの要素で結果をソートできます。以前のバージョンでも動的カラムを使えば、
VECTOR COLUMNの要素で結果をソートできましたが、この機能によって、動的カラムを使わずにVECTOR_COLUMNの要素で結果をソートできます。table_create Values TABLE_NO_KEY column_create Values numbers COLUMN_VECTOR Int32 load --table Values [ {"numbers": [127, 128, 129]}, {"numbers": [126, 255]}, {"numbers": [128, -254]} ] select Values --sort_keys 'numbers[1]' --output_columns numbers [ [ 0, 0.0, 0.0 ], [ [ [ 3 ], [ [ "numbers", "Int32" ] ], [ [ 128, -254 ] ], [ [ 127, 128, 129 ] ], [ [ 126, 255 ] ] ] ] ]
[トークンフィルター] オプションをつけた複数のトークンフィルターを使えるようにしました。
--token_filters 'TokenFilterStopWord("column", "ignore"), TokenFilterNFKC130("unify_kana", true)'のように複数のトークンフィルターを指定できます。 [Github#mroonga/mroonga#399][MASUDA Kazuhiroさんが報告]
[query] 複雑な式で
result_setステージの動的カラムを扱えるようにしました。複雑な式とは、以下のように一時的な内部結果セットが必要な式です。
'(true && query("name * 10", "ali", {"score_column": "ali_score"})) || \ (true && query("name * 2", "li", {"score_column": "li_score"}))'
上記の式では、
trueの評価結果を格納するために一時的な結果セットを使用します。したがって、例えば、以下の式では、式の中で
result_setステージの動的カラムの値を使えます。以下の式では、一時的な内部結果セットが必要ないためです。'(query("name * 10", "ali", {"score_column": "ali_score"})) || \ (query("name * 2", "li", {"score_column": "li_score"}))'
今回のリリースでは、以下のように
li_scoreに値を設定できます。(以前のバージョンでは、2番めの式が動的カラムの値を取得出来なかったため、li_scoreの値は0になっていました。)table_create Users TABLE_NO_KEY column_create Users name COLUMN_SCALAR ShortText table_create Lexicon TABLE_HASH_KEY ShortText \ --default_tokenizer TokenBigramSplitSymbolAlphaDigit \ --normalizer NormalizerAuto column_create Lexicon users_name COLUMN_INDEX|WITH_POSITION Users name load --table Users [ {"name": "Alice"}, {"name": "Alisa"}, {"name": "Bob"} ] select Users \ --columns[ali_score].stage result_set \ --columns[ali_score].type Float \ --columns[ali_score].flags COLUMN_SCALAR \ --columns[li_score].stage result_set \ --columns[li_score].type Float \ --columns[li_score].flags COLUMN_SCALAR \ --output_columns name,_score,ali_score,li_score \ --filter '(true && query("name * 10", "ali", {"score_column": "ali_score"})) || \ (true && query("name * 2", "li", {"score_column": "li_score"}))' [ [ 0, 0.0, 0.0 ], [ [ [ 2 ], [ [ "name", "ShortText" ], [ "_score", "Int32" ], [ "ali_score", "Float" ], [ "li_score", "Float" ] ], [ "Alice", 14, 10.0, 2.0 ], [ "Alisa", 14, 10.0, 2.0 ] ] ] ]
以下のように、
result_setステージの動的ベクターカラムも扱えるようにしました。table_create Users TABLE_NO_KEY column_create Users name COLUMN_SCALAR ShortText table_create Lexicon TABLE_HASH_KEY ShortText \ --default_tokenizer TokenBigramSplitSymbolAlphaDigit \ --normalizer NormalizerAuto column_create Lexicon users_name COLUMN_INDEX|WITH_POSITION Users name load --table Users [ {"name": "Alice"}, {"name": "Alisa"}, {"name": "Bob"} ] select Users \ --columns[tags].stage result_set \ --columns[tags].type ShortText \ --columns[tags].flags COLUMN_VECTOR \ --output_columns name,tags \ --filter '(true && query("name", "al", {"tags": ["al"], "tags_column": "tags"})) || \ (true && query("name", "sa", {"tags": ["sa"], "tags_column": "tags"}))' [ [ 0, 0.0, 0.0 ], [ [ [ 2 ], [ [ "name", "ShortText" ], [ "tags", "ShortText" ] ], [ "Alice", [ "al" ] ], [ "Alisa", [ "al", "sa" ] ] ] ] ]
動的ベクターカラムを使う場合、格納する値は各要素が追加された値になります。
[Ubuntu] Ubuntu 21.04 (Hirsute Hippo)をサポートしました。
[httpd] バンドルしているnginxのバージョンを1.19.10に更新しました。
既知の問題#
現在Groongaには、ベクターカラムに対してデータを大量に追加、削除、更新した際にデータが破損することがある問題があります。
[ブラウザーベースの管理ツール] 現在Groongaには、レコード一覧の管理モードのチェックボックスにチェックを入れても、非管理モードに入力された検索クエリーが送信されるという問題があります。 [Github#1186][potiさんが報告]
感謝#
Anthony M. Cookさん
MASUDA Kazuhiroさん
potiさん
11.0.1リリース - 2021-03-31#
改良#
[Debian GNU/Linux] ARM64向けのパッケージをサポートしました。
[select] キーワードごとに重みをカスタマイズできるようにしました。
今まで、スコアーを調整するには、すべてのキーワードに対して
<や>を指定する必要がありました。デフォルトのスコアの重み(1)より、デフォルトの重みの調整量(6 または 4)のほうが大きいためです。例えば、
A <Bでは、 "A" の重みは1、 "B" の重みは4になります。デクリメントされていない "A" の重み(1)より、デクリメントされた "B" の重み(4)のほうが大きくなります。これは、期待した動作ではありません。"B" に "A" より小さい重みを使うためには、>A <Bと指定する必要があります。>A <Bでは、 "A" の重みは6、 "B" の重みは4になります。
今回のリリースから、対象のキーワードに
<${WEIGHT}または>${WEIGHT}と指定するだけで、キーワードごとに重みの調整量をカスタマイズできます。例えば、A <0.1Bでは、 "A" の重みは1、 "B" の重みは0.9になります。("B" の重みを0.1デクリメントしています。)ただし、これらの形式(
>${WEIGHT}...,<${WEIGHT}..., and~${WEIGHT}...)は互換性が無いことに注意してください。
[select] Apache Arrow形式で
FloatとFloat32の値を出力できるようにしました。例えば、以下のように出力します。
table_create Data TABLE_NO_KEY column_create Data float COLUMN_SCALAR Float load --table Data [ {"float": 1.1} ] select Data \ --command_version 3 \ --output_type apache-arrow return_code: int32 start_time: timestamp[ns] elapsed_time: double -- metadata -- GROONGA:data_type: metadata return_code start_time elapsed_time 0 0 1970-01-01T09:00:00+09:00 0.000000 ======================================== _id: uint32 float: double -- metadata -- GROONGA:n_hits: 1 _id float 0 1 1.100000
[select] 結果出力時に、インデックスカラム経由で参照先のデータを取得できるようになりました。
今までは、 出力値に
index_column.xxxのように指定すると、Groongaは意図しない値を返していました。例えば以下の例では、--columns[tags].value purchases.tagの値は、["apple",["many"]],["banana",["man"]],["cacao",["man"]]になりました。このケースでは、期待される値は、["apple",["man","many"]],["banana",["man"]],["cacao",["woman"]]でした。今回のリリースから、以下のように、インデックスカラム経由で参照先の正しい値を取得できます。table_create Products TABLE_PAT_KEY ShortText table_create Purchases TABLE_NO_KEY column_create Purchases product COLUMN_SCALAR Products column_create Purchases tag COLUMN_SCALAR ShortText column_create Products purchases COLUMN_INDEX Purchases product load --table Products [ {"_key": "apple"}, {"_key": "banana"}, {"_key": "cacao"} ] load --table Purchases [ {"product": "apple", "tag": "man"}, {"product": "banana", "tag": "man"}, {"product": "cacao", "tag": "woman"}, {"product": "apple", "tag": "many"} ] select Products \ --columns[tags].stage output \ --columns[tags].flags COLUMN_VECTOR \ --columns[tags].type ShortText \ --columns[tags].value purchases.tag \ --output_columns _key,tags [ [ 0, 0.0, 0.0 ], [ [ [ 3 ], [ [ "_key", "ShortText" ], [ "tags", "ShortText" ] ], [ "apple", [ "man", "many" ] ], [ "banana", [ "man" ] ], [ "cacao", [ "woman" ] ] ] ] ]
[select] ネストされたインデックスの一部として直接インデックスカラムを指定できるようになりました。
index_column.except_source_columnを使ってフィルター後にソーステーブルを検索できます。例えば、以下の例では、検索時にcomments.contentを指定しています。この場合、最初に、このクエリはCommentsテーブルのcontentカラムを全文検索し、次にCommentsテーブルを検索した結果のレコードを参照するArticlesテーブルのレコードを取得します。table_create Articles TABLE_HASH_KEY ShortText table_create Comments TABLE_NO_KEY column_create Comments article COLUMN_SCALAR Articles column_create Comments content COLUMN_SCALAR ShortText column_create Articles content COLUMN_SCALAR Text column_create Articles comments COLUMN_INDEX Comments article table_create Terms TABLE_PAT_KEY ShortText \ --default_tokenizer TokenBigram \ --normalizer NormalizerNFKC130 column_create Terms articles_content COLUMN_INDEX|WITH_POSITION \ Articles content column_create Terms comments_content COLUMN_INDEX|WITH_POSITION \ Comments content load --table Articles [ {"_key": "article-1", "content": "Groonga is fast!"}, {"_key": "article-2", "content": "Groonga is useful!"}, {"_key": "article-3", "content": "Mroonga is fast!"} ] load --table Comments [ {"article": "article-1", "content": "I'm using Groonga too!"}, {"article": "article-3", "content": "I'm using Mroonga!"}, {"article": "article-1", "content": "I'm using PGroonga!"} ] select Articles --match_columns comments.content --query groonga \ --output_columns "_key, _score, comments.content [ [ 0, 0.0, 0.0 ], [ [ [ 1 ], [ [ "_key", "ShortText" ], [ "_score", "Int32" ], [ "comments.content", "ShortText" ] ], [ "article-1", 1, [ "I'm using Groonga too!", "I'm using PGroonga!" ] ] ] ] ]
[load] オブジェクトリテラルを使って、参照先のレコードをロードできるようにしました。
例えば、以下のように、
"key" : "[ { "key" : "value", ..., "key" : "value" } ]"のようなデータをロードできます。table_create Purchases TABLE_NO_KEY column_create Purchases item COLUMN_SCALAR ShortText column_create Purchases price COLUMN_SCALAR UInt32 table_create Settlements TABLE_HASH_KEY ShortText column_create Settlements purchases COLUMN_VECTOR Purchases column_create Purchases settlements_purchases COLUMN_INDEX Settlements purchases load --table Settlements [ { "_key": "super market", "purchases": [ {"item": "apple", "price": 100}, {"item": "milk", "price": 200} ] }, { "_key": "shoes shop", "purchases": [ {"item": "sneakers", "price": 3000} ] } ]
この機能によって、参照カラムにJSONデータを追加しやすくなります。
現状、この機能は、JSONの入力のみをサポートしています。
[load] JSON文字列で、参照先のレコードをロードできるようにしました。
以下のように、JSONテキストを使ってソーステーブルから参照ベクターへデータをロードできます。
table_create Purchases TABLE_HASH_KEY ShortText column_create Purchases item COLUMN_SCALAR ShortText column_create Purchases price COLUMN_SCALAR UInt32 table_create Settlements TABLE_HASH_KEY ShortText column_create Settlements purchases COLUMN_VECTOR Purchases column_create Purchases settlements_purchases COLUMN_INDEX Settlements purchases load --table Settlements [ { "_key": "super market", "purchases": "[{\"_key\": \"super market-1\", \"item\": \"apple\", \"price\": 100}, {\"_key\": \"super market-2\", \"item\": \"milk\", \"price\": 200}]" }, { "_key": "shoes shop", "purchases": "[{\"_key\": \"shoes shop-1\", \"item\": \"sneakers\", \"price\": 3000}]" } ] dump \ --dump_plugins no \ --dump_schema no load --table Purchases [ ["_key","item","price"], ["super market-1","apple",100], ["super market-2","milk",200], ["shoes shop-1","sneakers",3000] ] load --table Settlements [ ["_key","purchases"], ["super market",["super market-1","super market-2"]], ["shoes shop",["shoes shop-1"]] ] column_create Purchases settlements_purchases COLUMN_INDEX Settlements purchases
現状、この機能は、ネストされた参照レコードをサポートしていません。
[Windows]
time_classify_*関数で UNIXエポック を扱えるようになりました。Groongaは、現地時刻でタイムスタンプを扱っています。したがって、例えば日本でUNIXエポックを入力した場合、入力した時刻はUNIXエポックの9時間前になります。
WindowsのAPIはUNIXエポックより前の時間が入力されるとエラーになります。
今回のリリースから、以下のようにUNIXエポックを
time_classify_*内で使えるようにplugin_register functions/time table_create Timestamps TABLE_PAT_KEY Time load --table Timestamps [ {"_key": 0}, {"_key": "2016-05-06 00:00:00.000001"}, {"_key": "2016-05-06 23:59:59.999999"}, {"_key": "2016-05-07 00:00:00.000000"}, {"_key": "2016-05-07 00:00:00.000001"}, {"_key": "2016-05-08 23:59:59.999999"}, {"_key": "2016-05-08 00:00:00.000000"} ] select Timestamps \ --sortby _id \ --limit -1 \ --output_columns '_key, time_classify_day_of_week(_key)' [ [ 0, 0.0, 0.0 ], [ [ [ 7 ], [ [ "_key", "Time" ], [ "time_classify_day_of_week", null ] ], [ 0.0, 4 ], [ 1462460400.000001, 5 ], [ 1462546799.999999, 5 ], [ 1462546800.0, 6 ], [ 1462546800.000001, 6 ], [ 1462719599.999999, 0 ], [ 1462633200.0, 0 ] ] ] ]
[query_parallel_or] クエリーを並行して実行できる新しい関数を追加しました。
query_parallel_orでクエリーを並行で処理するためにはApache Arrowが必要です。Apache Arrowが無い場合は、query_parallel_orはクエリーをシーケンシャルに実行します。query_parallel_orは、match_columnsとquery_stringの組み合わせを平行に処理します。query_parallel_orの構文は以下の通りです。:query_parallel_or(match_columns, query_string1, query_string2, . . . query_stringN, {"option": "value", ...})
[select] 存在しないソートキーを無視するようにしました。
今まで、存在しないソートキーを指定したとき、Groongaはエラーを出力していましたが、今回のリリースから存在しないソートキーを無視します。(エラーを出力しなくなります。)
この機能は、一貫性のために実装しています。
output_columnsも無効な値を無視します。また、sort_keysも無効な値のほとんどを無視します。
[select] drilldowns[].table で存在しないテーブルを無視します。 [GitHub#1169][naoaさんが報告]
今まで、
drilldowns[].tableで存在しないテーブルを指定したとき、Groongaはエラーを出力していましたが、今回のリリースから存在しないテーブルを無視します。(エラーを出力しなくなります。)この機能は、一貫性のために実装しています。
output_columnsも無効な値を無視します。また、sort_keysも無効な値のほとんどを無視します。
[httpd] バンドルしているnginxのバージョンを1.19.8に更新しました。
修正#
[reference_acquire] 参照の自動リリースが発生する前に、テーブルにカラムが追加されテーブルの参照が獲得されたときにGroongaがクラッシュする問題を修正しました。
追加されたカラムの参照は獲得されませんが、自動リリースの対象になるためです。
[Windows] 別のスレッドで、他のバックトレースロギングプロセスが動作しているときに、新しくバックトレースロギングプロセスが開始されると、1つ以上のプロセスがSEGVのバックトレースの出力に失敗する問題を修正しました。
既知の問題#
現在Groongaには、ベクターカラムに対してデータを大量に追加、削除、更新した際にデータが破損することがある問題があります。
感謝#
naoaさん
11.0.0リリース - 2021-02-09#
メジャーバージョンアップです! メジャーバージョンアップですが、互換性は壊れていないので、データベースを再構築することなく11.0.0へアップグレードできます。
改良#
[select] ネストされたインデックス経由でスカラーカラムとベクターカラムの値を出力できるようになりました。
ネストされたインデックスとは、以下のような構造です。
table_create Products TABLE_PAT_KEY ShortText table_create Purchases TABLE_NO_KEY column_create Purchases product COLUMN_SCALAR Products column_create Purchases tag COLUMN_SCALAR ShortText column_create Products purchases COLUMN_INDEX Purchases product
上記の例では、
Products.purchasesカラムはPurchases.productカラムのインデックスです。また、Purchases.productカラムは、Productsテーブルへの参照です。今までは、ネストされたインデックス経由の検索は、期待した結果を返しませんでした。
今までの結果は以下のようになっていました。
{"product": "apple", "tag": "man"}が出力されていないことがわかります。table_create Products TABLE_PAT_KEY ShortText table_create Purchases TABLE_NO_KEY column_create Purchases product COLUMN_SCALAR Products column_create Purchases tag COLUMN_SCALAR ShortText column_create Products purchases COLUMN_INDEX Purchases product load --table Products [ {"_key": "apple"}, {"_key": "banana"}, {"_key": "cacao"} ] load --table Purchases [ {"product": "apple", "tag": "man"}, {"product": "banana", "tag": "man"}, {"product": "cacao", "tag": "woman"}, {"product": "apple", "tag": "many"} ] select Products \ --output_columns _key,purchases.tag [ [ 0, 1612504193.380738, 0.0002026557922363281 ], [ [ [ 3 ], [ [ "_key", "ShortText" ], [ "purchases.tag", "ShortText" ] ], [ "apple", "many" ], [ "banana", "man" ], [ "cacao", "man" ] ] ] ]
このリリースから、結果は以下のようになります。
{"product": "apple", "tag": "man"}が出力されているのがわかります。select Products \ --output_columns _key,purchases.tag [ [ 0, 0.0, 0.0 ], [ [ [ 3 ], [ [ "_key", "ShortText" ], [ "purchases.tags", "Tags" ] ], [ "apple", [ [ "man", "one" ], [ "child", "many" ] ] ], [ "banana", [ [ "man", "many" ] ] ], [ "cacao", [ [ "woman" ] ] ] ] ] ]
[Windows] Linux上のMinGWを使ってクロスコンパイルしていたWindows向けパッケージの提供をやめました。
おそらく、ほとんどの人がこのパッケージを使っていないためです。
上記のパッケージはこれまで、以下のような名前で提供されていたものです。
groonga-x.x.x-x86.exegroonga-x.x.x-x86.zipgroonga-x.x.x-x64.exegroonga-x.x.x-x86.zip
これからは、以下のパッケージを使用してください。
groonga-latest-x86-vs2019-with-vcruntime.zipgroonga-latest-x64-vs2019-with-vcruntime.zip
既に Microsoft Visual C++ Runtime Library がインストール済みのシステムの場合は、以下のパッケージを使用してください。
groonga-latest-x86-vs2019.zipgroonga-latest-x64-vs2019.zip
修正#
インデックス内のデータを大量に追加、削除、更新した際にインデックスが破損することがある問題を修正しました。
この問題は、インデックス内のデータを大量に削除しただけでも発生します。ただ、インデックスにデータを追加しただけでは発生しません。
この問題によって破損したインデックスは、インデックスを再構築することで修復できます。
この問題は、壊れたインデックスを参照しない限り発覚しません。したがって、既にインデックスが破損しているかもしれません。
[index_column_diff] コマンドを使うことで、インデックスが破損しているかどうかを確認できます。