mysql trittonからmariadb mroongaへ移行中ですが、問題があり、質問させていただきます。
下記事象についてなにか対応方法がありますでしょうか? mroonga側のbugでしょうか？

問題の内容
descを指定した複合indexを指定したテーブルに対してselectすると、結果行があるはずなのに、Empty setになる

問題発生手順
CREATE TABLE item (
item_id bigint(20) unsigned NOT NULL auto_increment,
entry_id int unsigned NOT NULL default 0,
creation_date datetime NOT NULL default '1970-01-01 00:00:00',
PRIMARY KEY (item_id),
KEY entry_id_creation_date (entry_id desc, creation_date desc)
) ENGINE=Mroonga DEFAULT CHARSET=utf8mb4;

insert into item values (1, 1, '2010-6-11 00:00:00');
insert into item values (2, 2, '2010-6-11 00:00:00');
insert into item values (3, 3, '2010-6-11 00:00:00');
insert into item values (4, 1, '2010-6-12 00:00:00');
insert into item values (5, 2, '2010-6-12 00:00:00');
insert into item values (6, 3, '2010-6-12 00:00:00');
insert into item values (7, 1, '2010-6-13 00:00:00');
insert into item values (8, 2, '2010-6-13 00:00:00');
insert into item values (9, 3, '2010-6-13 00:00:00');
insert into item values (10, 1, '2010-6-14 00:00:00');
insert into item values (11, 2, '2010-6-14 00:00:00');
insert into item values (12, 3, '2010-6-14 00:00:00');

select * from item where entry_id in (1, 2) and creation_date >= '2010-6-12' order by entry_id desc, creation_date desc;
Empty set (0.001 sec)

select * from item where entry_id in (1, 2) and creation_date >= '2010-6-12';
Empty set (0.001 sec)

期待結果
+---------+----------+---------------------+
| item_id | entry_id | creation_date |
+---------+----------+---------------------+
| 11 | 2 | 2010-06-14 00:00:00 |
| 8 | 2 | 2010-06-13 00:00:00 |
| 5 | 2 | 2010-06-12 00:00:00 |
| 10 | 1 | 2010-06-14 00:00:00 |
| 7 | 1 | 2010-06-13 00:00:00 |
| 4 | 1 | 2010-06-12 00:00:00 |
+---------+----------+---------------------+
6 rows in set (0.000 sec)

確認環境
mariadb 10.11.4
mroonga 13.05

参考情報
storage engineがariaの場合、問題ありません。
indexにdescがない場合、問題ありません。

mysql tritonnからmariadb mroongaへ移行中ですが、問題があり、質問させていただきます。
下記事象についてなにか対応方法がありますでしょうか? mroonga側のbugでしょうか？

問題の内容
descを指定した複合indexを指定したテーブルに対してselectすると、結果行があるはずなのに、Empty setになる

問題発生手順
CREATE TABLE item (
item_id bigint(20) unsigned NOT NULL auto_increment,
entry_id int unsigned NOT NULL default 0,
creation_date datetime NOT NULL default '1970-01-01 00:00:00',
PRIMARY KEY (item_id),
KEY entry_id_creation_date (entry_id desc, creation_date desc)
) ENGINE=Mroonga DEFAULT CHARSET=utf8mb4;

insert into item values (1, 1, '2010-6-11 00:00:00');
insert into item values (2, 2, '2010-6-11 00:00:00');
insert into item values (3, 3, '2010-6-11 00:00:00');
insert into item values (4, 1, '2010-6-12 00:00:00');
insert into item values (5, 2, '2010-6-12 00:00:00');
insert into item values (6, 3, '2010-6-12 00:00:00');
insert into item values (7, 1, '2010-6-13 00:00:00');
insert into item values (8, 2, '2010-6-13 00:00:00');
insert into item values (9, 3, '2010-6-13 00:00:00');
insert into item values (10, 1, '2010-6-14 00:00:00');
insert into item values (11, 2, '2010-6-14 00:00:00');
insert into item values (12, 3, '2010-6-14 00:00:00');

select * from item where entry_id in (1, 2) and creation_date >= '2010-6-12' order by entry_id desc, creation_date desc;
Empty set (0.001 sec)

select * from item where entry_id in (1, 2) and creation_date >= '2010-6-12';
Empty set (0.001 sec)

期待結果
+---------+----------+---------------------+
| item_id | entry_id | creation_date |
+---------+----------+---------------------+
| 11 | 2 | 2010-06-14 00:00:00 |
| 8 | 2 | 2010-06-13 00:00:00 |
| 5 | 2 | 2010-06-12 00:00:00 |
| 10 | 1 | 2010-06-14 00:00:00 |
| 7 | 1 | 2010-06-13 00:00:00 |
| 4 | 1 | 2010-06-12 00:00:00 |
+---------+----------+---------------------+
6 rows in set (0.000 sec)

確認環境
mariadb 10.11.4
mroonga 13.05

参考情報
storage engineがariaの場合、問題ありません。
indexにdescがない場合、問題ありません。

TritonnからMroongaへ！
満を持してのアップグレードですね！

あぁ、KEY()でのDESC指定は対応していないですねぇ。
それはそれで対応しておくとして、このくらいのクエリーならDESCなしでも高速に処理できると思うので、DESCなしで速度を測ってみてもらえますか？

INDEX (column DESC)について調べてみたのですが、MySQL 8.0未満、MariaDB 10.8未満では単に無視されていたようです。
https://dev.mysql.com/worklog/task/?id=1074
https://jira.mariadb.org/browse/MDEV-13756

それより新しい場合はこの問題が発生するんだと思います。
MySQLの場合はこのタイミングでストレージエンジンが対応していなかったらインデックス定義時にエラーになるようになっていました。そのため、MySQL + Mroongaの場合はこの問題は発生しません。（発生する前にエラーになる。）
一方、MariaDBはMariaDB側でそういうチェックを追加しなかったのでストレージエンジンがなにかしないと今回のように変な結果を返すようになっていました。今回はMariaDB 10.11.4へのアップグレードだったのでこの問題に遭遇したのだと思います。（もう少し古いMariaDBなら発生しなそう。）

ちょっと、INDEX (column DESC)の対応を作りかけてみたのですが、やることが多くてすぐに仕上がらなそうだったので、MariaDBの場合でもインデックス定義時にエラーになるようにしました。

ということで、もともと無視されていたので、DESCを指定しなくても、これのせいでもとと速度が劇的に変わるということはないと思います。（他の要因で変わることはあるとは思います。）

状況についてありがとうございます、大変たすかります。

やる気になるのでどんな感じで使っているか教えてもらえますか！？

ご希望の回答になるかわかりませんが、
自社製品の特定の機能で全文検索機能を用意しておりまして、
そこでGroonga、PGroongaを利用しておりました。

AmazonLinux2のサポートが切れるにあたって、移行先のOSをどうしようか調査しているところでしta。
ただAmazon Linux2023が対応していないのであれば、
AlmaLinux 9で進めることもできるな、とは思っておりました。

状況についてありがとうございます、大変たすかります。

やる気になるのでどんな感じで使っているか教えてもらえますか！？

ご希望の回答になるかわかりませんが、
自社製品の特定の機能で全文検索機能を用意しておりまして、
そこでGroonga、PGroongaを利用しておりました。

AmazonLinux2のサポートが切れるにあたって、移行先のOSをどうしようか調査しているところでした。
ただAmazon Linux2023が対応していないのであれば、
AlmaLinux 9で進めることもできるな、とは思っておりました。

In reply to @ktou:matrix.org
なるほど！
Amazon Linux系を使い続けるならGroongaだけでなくPGroongaのパッケージも必要なんですね！

ちなみにMeCabは使っていますか？
Amazon Linux 2023にはMeCabのパッケージがないのでAmazon Linux 2023用のパッケージではMeCabを有効にできないんですよ。

語弊がありました、すみません。
OSがどれであってもGroongaとPGroongaの両方はインストールしております。

MeCabについてもありがとうございます。
幸いこちらでは利用しておりませんでした。

さらに追加情報ありがとうございます。
MessagePackは利用していますが、レプリケーションする場合はpgpoolを使っているので、
そこ自体に影響はない認識です。

ただMessagePackがない(walが使えなくなる？)ということは、
万が一何か障害が起きたときにあまりよくないですよね……。

ユースケースを教えてもらえたので、次のリリースではAmazon Linux 2023用のパッケージを提供しますね。

本当ですか！　ありがとうございます！
それではこちらも引き続きOS調査していこうと思います。

PGroongaでは採用事例を集めているので協力してもらえるとうれしいです。

諸々ご回答いただいておきながら恐縮ではございますが、
私の判断では何ともお答えできないので、上長に一度相談させていただきます。

ありがとうございます。

MessagePackは利用していますが、レプリケーションする場合はpgpoolを使っているので、そこ自体に影響はない認識です。

うーん、Pgpool-IIはストリーミングレプリケーションを使ってレプリケーションすることもあるんですよねぇ。
https://www.pgpool.net/docs/pgpool-II-4.5.1/ja/html/configuring-pgpool.html の設定を確認しておいたほうがよいかもしれません。

PostgreSQL 15以上を使っているならMessagePackを使わずにストリーミングレプリケーションできるhttps://pgroonga.github.io/ja/reference/streaming-replication-wal-resource-manager.html を使えます。

ただMessagePackがない(walが使えなくなる？)ということは、万が一何か障害が起きたときにあまりよくないですよね……。

PGroongaが持っているデータはすべてPostgreSQLも持っているので、もし障害でPGroongaのデータが壊れたとしても、基本的にREINDEXでPGroongaのインデックスを作り直せば復旧できます。

そのあたりを自動化する https://pgroonga.github.io/ja/reference/crash-safe.html もあるのですが、これもMessagePackを使うんですよねぇ。

諸々ご回答いただいておきながら恐縮ではございますが、私の判断では何ともお答えできないので、上長に一度相談させていただきます。

はい、よろしくおねがいします！

In reply to @ktou:matrix.org

MessagePackは利用していますが、レプリケーションする場合はpgpoolを使っているので、そこ自体に影響はない認識です。

うーん、Pgpool-IIはストリーミングレプリケーションを使ってレプリケーションすることもあるんですよねぇ。
https://www.pgpool.net/docs/pgpool-II-4.5.1/ja/html/configuring-pgpool.html の設定を確認しておいたほうがよいかもしれません。

PostgreSQL 15以上を使っているならMessagePackを使わずにストリーミングレプリケーションできるhttps://pgroonga.github.io/ja/reference/streaming-replication-wal-resource-manager.html を使えます。

ただMessagePackがない(walが使えなくなる？)ということは、万が一何か障害が起きたときにあまりよくないですよね……。

PGroongaが持っているデータはすべてPostgreSQLも持っているので、もし障害でPGroongaのデータが壊れたとしても、基本的にREINDEXでPGroongaのインデックスを作り直せば復旧できます。

そのあたりを自動化する https://pgroonga.github.io/ja/reference/crash-safe.html もあるのですが、これもMessagePackを使うんですよねぇ。

諸々ご回答いただいておきながら恐縮ではございますが、私の判断では何ともお答えできないので、上長に一度相談させていただきます。

はい、よろしくおねがいします！

うーん、Pgpool-IIはストリーミングレプリケーションを使ってレプリケーションすることもあるんですよねぇ。

ありがとうございます。
改めて確認いたしましたが、ネイティブレプリケーションモードを設定しておりました。

PGroongaが持っているデータはすべてPostgreSQLも持っているので、
もし障害でPGroongaのデータが壊れたとしても、基本的にREINDEXでPGroongaのインデックスを作り直せば復旧できます。

何から何までありがとうございます。
そうなると、こちらとしてはMessagePackはあってもなくてもそこまで困らなそうな感じはありますね。
将来的に自動化していくとなった場合はネックになってしまうかもしれませんけれど。

In reply to @ktou:matrix.org

INDEX (column DESC)について調べてみたのですが、MySQL 8.0未満、MariaDB 10.8未満では単に無視されていたようです。
https://dev.mysql.com/worklog/task/?id=1074
https://jira.mariadb.org/browse/MDEV-13756

それより新しい場合はこの問題が発生するんだと思います。
MySQLの場合はこのタイミングでストレージエンジンが対応していなかったらインデックス定義時にエラーになるようになっていました。そのため、MySQL + Mroongaの場合はこの問題は発生しません。（発生する前にエラーになる。）
一方、MariaDBはMariaDB側でそういうチェックを追加しなかったのでストレージエンジンがなにかしないと今回のように変な結果を返すようになっていました。今回はMariaDB 10.11.4へのアップグレードだったのでこの問題に遭遇したのだと思います。（もう少し古いMariaDBなら発生しなそう。）

ちょっと、INDEX (column DESC)の対応を作りかけてみたのですが、やることが多くてすぐに仕上がらなそうだったので、MariaDBの場合でもインデックス定義時にエラーになるようにしました。

ということで、もともと無視されていたので、DESCを指定しなくても、これのせいでもとと速度が劇的に変わるということはないと思います。（他の要因で変わることはあるとは思います。）

詳細調べていただき、またご対応いただきありがとうございます。

また、本番環境と似た環境で速度を測りました。
（以前お送りしたcreate table文は、問題の再現のためのもので、今回は実際のものを利用しましたので、少し違います）
where句のentry_id, creation_dateをいくつか変えてみましたら、結構ばらつきがありました。

結果
0.1 〜 9 秒程度

測定条件
データ数: 約4000万件
サーバスペック: AWS EC2 r5.4xlarge instance
OS: AlmaLinux 9

実は、MariaDBの最近のバージョンへのアップグレードということでdesc indexにも期待していました。
が、影響範囲が大きいということで、対応方法について承知しました。
もし、将来正式対応していただけたら、ありがたいです。