13 Aug 2024 |
kou | "東京に深刻" だと「東京に深刻なダメージを与えました。」はヒットしますが、「東京都民に...」にはヒットしません。 「東京」と「に」と「深刻」がこの順番で出現していないからです。 | 08:42:35 |
kou | --query "東京都民に深刻" だとヒットするはずです。 | 08:43:11 |
vst-m | ご回答ありがとうございます 配列がキーワードの方がたとえば[0 => '東京',1 => 'に',2 => '深刻'] で、索引の方が[0 => '東京', 1 => '都民', 2=> 'に', 3 => '深刻'] となって、間に都民が挟まってしまうのでヒットしないという理解で大丈夫でしょうか? | 08:47:18 |
kou | はい、そうです。 | 08:48:13 |
vst-m | 早速のご回答ありがとうございました
大変助かりました
これからもmroongaを使う予定ですので、もしまた質問させていただく機会がありましたらよろしくお願いいたします | 08:50:29 |
21 Aug 2024 |
| Abe Tomoaki set a profile picture. | 07:28:34 |
25 Aug 2024 |
| ttsujie joined the room. | 06:37:39 |
ttsujie | Redacted or Malformed Event | 06:39:21 |
ttsujie | 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がない場合、問題ありません。
| 06:49:57 |
ttsujie | * 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がない場合、問題ありません。
| 06:51:20 |
26 Aug 2024 |
kou | TritonnからMroongaへ! 満を持してのアップグレードですね!
あぁ、KEY() でのDESC 指定は対応していないですねぇ。 それはそれで対応しておくとして、このくらいのクエリーならDESC なしでも高速に処理できると思うので、DESC なしで速度を測ってみてもらえますか?
| 03:01:46 |
30 Aug 2024 |
ttsujie | ご返信ありがとうございます。承知しました。
indexが使われないのはともかく、
検索結果が0件になるのは、信頼性が低くなりますので、
修正をお願いできたらと思います。
とりあえずはdescなしのindexで対応します。
速度は本番環境と同じデータ数で測ってみたいと思います。
少々お時間ください。 | 08:46:51 |
4 Sep 2024 |
kou | 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 を指定しなくても、これのせいでもとと速度が劇的に変わるということはないと思います。(他の要因で変わることはあるとは思います。)
| 01:08:05 |
9 Sep 2024 |
takoyaki-nyokki | お世話になります。
すでに過去お話が出ていたら申し訳ないのですが、
GroongaってAmazon Linux 2023には正式対応しているのでしょうか?
「ソースからビルド」の以下手順に沿ってインストールすれば使えるんだろうなとは思っているのですが、
「Amazon Linux2」向けのインストール手順はあるのに
「Amazon Linux 2023」向けのは一向出てこないので気になってまして……。
https://groonga.org/ja/docs/install/others.html#build-from-source | 04:28:11 |
kou | 対応しよっかなー
でも、必要な人いるのかなー
っていうので止まっていました!
https://github.com/groonga/groonga/issues/1845
やる気になるのでどんな感じで使っているか教えてもらえますか!? | 04:29:32 |
takoyaki-nyokki | 状況についてありがとうございます、大変たすかります。
やる気になるのでどんな感じで使っているか教えてもらえますか!?
ご希望の回答になるかわかりませんが、 自社製品の特定の機能で全文検索機能を用意しておりまして、 そこでGroonga、PGroongaを利用しておりました。
AmazonLinux2のサポートが切れるにあたって、移行先のOSをどうしようか調査しているところでしta。 ただAmazon Linux2023が対応していないのであれば、 AlmaLinux 9で進めることもできるな、とは思っておりました。
| 04:42:40 |
takoyaki-nyokki | * 状況についてありがとうございます、大変たすかります。
やる気になるのでどんな感じで使っているか教えてもらえますか!?
ご希望の回答になるかわかりませんが、 自社製品の特定の機能で全文検索機能を用意しておりまして、 そこでGroonga、PGroongaを利用しておりました。
AmazonLinux2のサポートが切れるにあたって、移行先のOSをどうしようか調査しているところでした。 ただAmazon Linux2023が対応していないのであれば、 AlmaLinux 9で進めることもできるな、とは思っておりました。
| 04:42:45 |
kou | なるほど!
Amazon Linux系を使い続けるならGroongaだけでなくPGroongaのパッケージも必要なんですね!
ちなみにMeCabは使っていますか?
Amazon Linux 2023にはMeCabのパッケージがないのでAmazon Linux 2023用のパッケージではMeCabを有効にできないんですよ。 | 04:44:08 |
takoyaki-nyokki | In reply to @ktou:matrix.org なるほど! Amazon Linux系を使い続けるならGroongaだけでなくPGroongaのパッケージも必要なんですね!
ちなみにMeCabは使っていますか? Amazon Linux 2023にはMeCabのパッケージがないのでAmazon Linux 2023用のパッケージではMeCabを有効にできないんですよ。 語弊がありました、すみません。 OSがどれであってもGroongaとPGroongaの両方はインストールしております。
MeCabについてもありがとうございます。 幸いこちらでは利用しておりませんでした。
| 04:53:10 |
kou | あ、いえ、ちゃんと理解しているつもりです。
Amazon Linux 2の移行先としてAmazon Linux 2023を選択した場合はAmazon Linux 2023用のGroongaとPGroongaのパッケージをインストールしたくなりますよねぇ(自分でソースからビルドじゃなくて)、というのを言いたかっただけでした。
MeCabは問題にならなそうですね。
PGroongaではレプリケーションは使っていますか?
Amazon Linux 2023にはMessagPackというやつのパッケージもないのですが、PGroongaのストリーミングレプリケーション https://pgroonga.github.io/ja/reference/streaming-replication.html はMessagePackがないと動かないんです。 | 05:02:55 |
kou | ユースケースを教えてもらえたので、次のリリースではAmazon Linux 2023用のパッケージを提供しますね。
https://github.com/groonga/groonga/pull/1949
(もしかしたら、AlmaLinux 9など他のOSの方が移行先として適切かもしれませんが。。。)
PGroongaでは採用事例を集めているので協力してもらえるとうれしいです。メンテナンスを継続するためのやる気にもつながりますし、採用事例を参考にして開発にお金を払ってくれる人が増えれば金銭面でも継続しやすくなります。
https://pgroonga.github.io/ja/users/ | 05:05:59 |
takoyaki-nyokki | さらに追加情報ありがとうございます。 MessagePackは利用していますが、レプリケーションする場合はpgpoolを使っているので、 そこ自体に影響はない認識です。
ただMessagePackがない(walが使えなくなる?)ということは、 万が一何か障害が起きたときにあまりよくないですよね……。
ユースケースを教えてもらえたので、次のリリースではAmazon Linux 2023用のパッケージを提供しますね。
本当ですか! ありがとうございます! それではこちらも引き続きOS調査していこうと思います。
PGroongaでは採用事例を集めているので協力してもらえるとうれしいです。
諸々ご回答いただいておきながら恐縮ではございますが、 私の判断では何ともお答えできないので、上長に一度相談させていただきます。
ありがとうございます。
| 05:33:43 |
kou |
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を使うんですよねぇ。
諸々ご回答いただいておきながら恐縮ではございますが、私の判断では何ともお答えできないので、上長に一度相談させていただきます。
はい、よろしくおねがいします!
| 05:41:26 |
takoyaki-nyokki | 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はあってもなくてもそこまで困らなそうな感じはありますね。 将来的に自動化していくとなった場合はネックになってしまうかもしれませんけれど。
| 06:02:53 |
kou | では大丈夫そうですね! | 06:07:08 |
10 Sep 2024 |
ttsujie | 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にも期待していました。 が、影響範囲が大きいということで、対応方法について承知しました。 もし、将来正式対応していただけたら、ありがたいです。
| 14:47:13 |
kou | 9秒は遅いですねぇ。
どんなクエリーですか? | 23:23:11 |
kou | (ちなみに、有償のサポートサービス https://www.clear-code.com/services/groonga を契約するといつ実装されるか(移行前に実装してとか)をコントールできるので、必要であればご検討ください。) | 23:25:29 |
11 Sep 2024 |
ttsujie | クエリーは最初の問題発生手順で書きました下記ですが、
entry_idとcreation_dateの範囲がユーザの入力により変化します。
select * from item where entry_id in (1, 2) and creation_date >= '2010-6-12' order by entry_id desc, creation_date desc;
有償サポートのご案内ありがとうございます!
当面はdescなしのindexで大丈夫です。 | 13:39:37 |
12 Sep 2024 |
kou | なるほど! ちなみに、0.1秒のクエリーはどんなクエリーですか?9秒のクエリーと同じで、entry_id のin のところとcreation_date の'2010-6-12' のところが違うだけですか? 0.1秒と9秒でヒットするレコード数は違いますか? もし、レコード数が違う場合(9秒のほうが大量ヒットだとは思います)、今のクエリーだとLIMIT なしですが、LIMIT をつけると傾向は変わりますか? | 00:03:52 |