2023-03-28
第30回「grn_objの構造について」を開催しました！
第30回「grn_objの構造について」を開催しました！の内容をまとめました！
grn_objの構造について解説いただきました！
grn_objの構造
C言語は手続き型の言語で、その後オブジェクト指向という概念が出てきたので言語レベルではC言語はオブジェクト指向をサポートしていません。
C言語でオブジェクト指向的なことを実行できるようにしています。
どのように実現しているのでしょうか？
C言語のメモリーレイアウトの考え方を使って実現しています。
例えば、継承（のような仕組み）を実現するには以下のようにします。
各オブジェクトで共通する内容を抽出して下記のような構造体を作ります。
typedef struct {
int type;
} Animal;
上記を継承したデータを作るには以下のような構造体を作って実現します。
typedef struct {
int type;
char *name;
} Dog;
typedef struct {
int type;
char *job;
} Human;
上記のように定義すると、Dog型の構造体をAnimal型の構造体にキャストできます。
上記のように共通している情報を同じ位置に揃えることで、メモリー上のレイアウトも同じ位置に共通の情報が配置されるためです。
grn_objでもC言語の特徴を利用して以下のように、すべてのオブジェクトで共通する情報をgrn_obj_header型で保持します。
grn_obj_headerに自分がなんのオブジェクトなのかを表すメタデータが入っています。
struct _grn_obj {
grn_obj_header header;
union {
struct {
char *head;
char *curr;
char *tail;
} b;
struct {
grn_obj *body;
grn_section *sections;
uint32_t n_sections;
} v;
} u;
};
また、unionを使っているのは容量を削減するためです。
grn_objの中にはGRN_BULK、GRN_VECTORがあります。bはBULKのbでvはVECTORのvでuはUNIONのuです。
grn_objはVECTORになるかもしれないし、BULKになるかもしれませんが、両方一気になることはないためUNIONで十分表現できるのでこの構造になっています。
2023-03-27
PostgreSQL用高速日本語全文検索モジュールPGroonga（ぴーじーるんが） 2.4.7リリース
PostgreSQLで高速日本語全文検索をできるようにするPGroonga2.4.7をリリースしました！
ハイライト
- UUID型のカラムに対してPGroongaのインデックスを設定するとPGroongaがクラッシュする問題を修正しました。
まとめ
新規ユーザーの方は、PGroongaについても参照してください。
PostgreSQLで高速に日本語全文検索をしたいという方はPGroongaを使ってガンガン検索してください！
2023-03-24
PostgreSQL用高速日本語全文検索モジュールPGroonga（ぴーじーるんが） 2.4.6リリース
PostgreSQLで高速日本語全文検索をできるようにするPGroonga2.4.6をリリースしました！
ハイライト
-
&^ 演算子 pgroonga_full_text_search_condition をサポートしました。
以下の構文を使用することで、シーケンシャルサーチのときにもPGroongaのインデックスに指定した検索オプションを使えます。
column &^ (prefix, NULL, index_name)::pgroonga_full_text_search_condition
-
&= 演算子 新しい演算子 &= を追加しました。
&= 演算子は完全一致を実行します。
&= 演算子は以下の構文をサポートしているため、シーケンシャルサーチのときにもPGroongaのインデックスに指定した検索オプションを使えます。
column &= (keyword, NULL, index_name)::pgroonga_full_text_search_condition
まとめ
新規ユーザーの方は、PGroongaについても参照してください。
PostgreSQLで高速に日本語全文検索をしたいという方はPGroongaを使ってガンガン検索してください！
2023-03-24
Groonga 13.0.1リリース
Groonga 13.0.1をリリースしました！
それぞれの環境毎のインストール方法: インストール
変更内容
主な変更点は以下の通りです。
改良
-
ノーマライザー NormalizerNFKC* に新しいオプションを追加しました。
以下のオプションを追加しました。これらのオプションはすべての NormalizerNFKC で使えます。
これらのオプションの詳細は、 NormalizerNFKC150 を参照してください。
unify_kana_prolonged_sound_markunify_kana_hyphenunify_katakana_trailing_o
-
MessagePack v6.0.0 をサポートしました。
今まで、Groongaは configure または cmake 実行時にMessagePack v6.0.0以降のMessagePackを検出できませんでした。
このリリースから、MessagePackがv6.0.0以降であっても検出できるようになります。
修正
-
highlight_html loose_symbol=true の時にハイライト位置がずれることがある問題を修正しました。
-
Normalizers NormalizerNFKC が不正な正規化をする問題を修正しました。
この問題は、 unify_kana_case と unify_katakana_v_sounds を同時に使う場合に発生します。
例えば、 unify_kana_case と unify_katakana_v_sounds を同時に使うとき、 ヴァ が バア にノーマライズされていました。しかし ヴァ は バ と正規化されるべきです。
これは、 unify_kana_case で ヴァ が ヴア と正規化され、その後、 unify_katakana_v_sounds によって ヴア が バア と正規化されていたことが原因です。 unify_katakana_v_sounds が unify_kana_case より前に適用されるように修正しました。
以下は以前のバージョンでの問題の発生例です。
normalize \
'NormalizerNFKC150("unify_katakana_v_sounds", true, \
"unify_kana_case", true)' \
"ヴァーチャル"
#[
# [
# 0,
# 1678097412.913053,
# 0.00019073486328125
# ],
# {
# "normalized":"ブアーチヤル",
# "types":[],
# "checks":[]
# }
このバージョンから、 ヴァーチャル は バーチヤル にノーマライズされます。
既知の問題
-
現在Groongaには、ベクターカラムに対してデータを大量に追加、削除、更新した際にデータが破損することがある問題があります。
-
*< と *> は、filter条件の右辺に query() を使う時のみ有効です。もし、以下のように指定した場合、 *< と *> は && として機能します。
'content @ "Groonga" *< content @ "Mroonga"'
-
GRN_II_CURSOR_SET_MIN_ENABLE が原因でマッチするはずのレコードを返さないことがあります。
さいごに
詳細については、以下のお知らせ、リリース自慢会も参照してください。
お知らせ 13.0.1リリース
リリース自慢会
リリース自慢会は、リリースノートを見ながら、Groongaの新機能・バグ修正を開発者が自慢する会です。
毎月リリースされている最新バージョンについて、開発者的に「これ！」という機能や、「ここをがんばった！」ということを紹介しています。
Liveチャットでコメントも受け付けていますので、気になっていることを質問したり、気になっていたあの機能について聞いたりすることも可能です。
それでは、Groongaでガンガン検索してください！
2023-03-07
グルカイ！第28回「Apache ParquetフォーマットのデータをGroongaに読み込むには？」を開催しました！
グルカイ！第28回「Apache ParquetフォーマットのデータをGroongaに読み込むには？」を開催しました！の内容をまとめました！
今回は、Apache ParquetフォーマットのデータをどうやってGroongaに読み込むのか？について解説いただきました！
Apache Parquetとは？
まず、Apache Parquetフォーマットについて解説いただきました。
列指向のフォーマットで、必要なカラムの値のみ取り出せるのでCSV等の行指向のフォーマットに比べて入力するデータを選択できる点が強みです。
Apache Parquetはストレージ用フォーマットであるため、なるべくディスク容量を小さくしたくなります。
例えば、時系列データなどは増えていく一方であり、ストレージも無料ではないのでなるべくディスク容量を抑えたくなります。
また、使用するディスク容量が少ないほうがI/Oの負荷も少ないためパフォーマンス的にも有利になります。
読み書きの速度とディスク容量はトレードオフになりやすいですが、Apache Parquetフォーマットは読み書きの速度とディスク容量のバランスをうまくとっています。
Apache Parquetフォーマットは型があるので、データ量を小さくしやすくなっています。
例えば、文字列だと8byte必要だが数字であれば4byteで表現できるなど、型があることで容量を節約できるケースがあります。
GroongaでApache Parquetフォーマットは読めるのか？
読み込めません！
ただ、Apache Arrowを使うことでGroongaに読み込めるようになります。
Apache Arrowとは列指向で型がついているデータフォーマットです。
Apache Parquetとの違いはインメモリ用のフォーマットであることです。
速く計算できることと、速くデータを交換（異なるデータフォーマットでやり取り）することを大事にしています。
GroongaはApache Arrowフォーマットのデータを読むことができます。
そのため、ストレージにあるApache ParquetのデータをApache Arrowフォーマットにしてメモリー読み込んでGroongaに渡す。ということができます。
このようすれば、Apache ParquetのデータをGroongaに読むことができます。
その他のストレージ用フォーマットApache ORC/AVROなどのフォーマットもApache Arrow形式にして扱うことができます。
したがって、Apache Arrowフォーマットをサポートすることで、様々なデータフォーマットのデータを読むことができるようになります。
2023-03-06
PostgreSQL用高速日本語全文検索モジュールPGroonga（ぴーじーるんが） 2.4.5リリース
PostgreSQLで高速日本語全文検索をできるようにするPGroonga2.4.5をリリースしました！
ハイライト
[クラッシュセーフ] GroongaのWALによる復旧が失敗したときに、PGroongaのインデックスの復旧に失敗する問題を修正しました。
PGroongaのクラッシュセーフは、PGroongaのインデックスの変更点をGroongaのWALでに随時書き出しています。
PostgreSQLのクラッシュなどで正常にシャットダウンされなかった時に、書き出していたGroongaのWALを使って復旧を試みますが、GroongaのWALでも復旧に失敗した場合は、既存のGroongaのデータベースを削除して、新しくGroongaのデータベースを作り、 REINDEX を実行しPostgreSQLのデータからPGroongaのインデックスを再生成します。
今回の問題は、上記のようにGroongaのWALを使った復旧に失敗したあとの REINDEX が正しく実行されていませんでした。
結果として、GroongaのWALを使った復旧に失敗すると、PGroongaのインデックスは破損したままになります。
まとめ
新規ユーザーの方は、PGroongaについても参照してください。
PostgreSQLで高速に日本語全文検索をしたいという方はPGroongaを使ってガンガン検索してください！
