Kouhei Sutou
kou****@clear*****
2016年 1月 15日 (金) 00:14:55 JST
須藤です。 In <20160****@domai*****> "[groonga-dev,03849] Re: Mroonga で timestamp 型の index が破損するパターンがある（ストレージモード）（解決）" on Wed, 13 Jan 2016 13:27:36 +0900, 各務 洋 <kagam****@outwa*****> wrote: > ご教示いただきました通り、Ver.up だけで解消しているのを確認いたしました。 確認ありがとうございます！ うまく動くようになってよかったです。 > mroonga_log_level の設定で、もっともっとログを吐くと何か見つけられるか > もと思ったのですが、どうでしょうか？ > （Disk I/O をログ出力に持っていかれて、DEBUG だと遅い！という位出て > も良いのかなぁと思いました。） 今は↓みたいなDBUG_PRINT()というMySQLが提供しているマクロで デバッグログを吐いているところがあるんですが、 https://github.com/mroonga/mroonga/blob/master/ha_mroonga.cpp#L1997-L1998 これを、↓みたいなGRN_LOG()というGroongaが提供しているマクロ を使うように変えたほうがいいかもしれませんねぇ。 https://github.com/mroonga/mroonga/blob/master/ha_mroonga.cpp#L739-L741 DBUG_PRINT()はビルド時に出力のオンオフを切り替えるので、デバッ グビルドではないときはオーバーヘッドがないんですが、ビルド時 に切り替えることしかできません。 一方、GRN_LOG()は実行時に出力のオンオフを切り替えるので、デ バッグビルドでなくても実行時にmroonga_log_levelで出力のオン オフを切り替えられます。その代わり実行時に出力するかどうかを 判断するのでわずかにオーバーヘッドがあります。 オーバーヘッドがあるといっても、全体からみるとそんなに変わら ないと思うので、GRN_LOG()でもいいかなぁという気がします。 マクロの呼び出し方を変えるだけの簡単な変更なので、だれか興味 がある人は少しずつ変更してpull requestを送ってもらえると取り 込みます。（逆に1つのpull requestで全部こられるとチェックす る気が失せて取り込むのが遅くなると思います。） （この変更はさすがに面倒すぎて私はやらないと思います。。。 自分がものすごく困ったらやるとは思いますが。。。） >>> 修正以前の場合でも、テーブルに更新が入ると概算見積も変わるのが期待され >>> る挙動だと思うのですが、一度のこの状態になると INSERT / DELETE で変わ >>> らなくなっていたように見受けられる点がちょっと気になりました。 >> >> それは、レコードを削除してもインデックスのキーは消えないから > > ！？！？最後の1つを消す以外は。でよいでしょうか？ いえ、最後の1つを消す時も消しません。 MySQLのインデックスの実装は1つのインデックスで完結して、複数 のインデックス間での連携はまったくないので消しているのかもし れませんが、Groongaのインデックスはもっと一般的なものなので、 おいそれと消せないのです。 たとえば、Groongaでは、インデックスのキーに付加情報を追加す ることができたり(*1)、インデックスのキーを複数のインデックス で共有できたり(*2)します。これはMySQLのインデックスではでき ないことです。 (*1) タグのインデックスを作るときに、キーは全部小文字で 「groonga」とか「mroonga」にするけど、表示するときのラベルと して「Groonga」とか「Mroonga」とかをキーに付加することができ る。 (*2) created_atとupdated_atは同じ時刻の範囲になることが多い ので、インデックスのキーを共有するとキーが使うスペースを減ら せる。 なので、あるインデックスを更新したときに本当にそれが「最後の 1つ」なのか調べるのは単純ではないのです。やればできますが、 その分更新処理が重くなります。例えば、チェックする時間が増え ますし、チェックしている間に他の処理が入ると整合性が壊れるの でロックの範囲が大きくなって同時更新時の性能が落ちると思いま す。 実際に作って計測してみたらそうでもなかったという場合もあると 思うので、だれか興味のある方はチャレンジしてみてください。 > それとももっと別のタイミングで消すのでしょうか？ 自動的には消さないです。 理由は前述の通りです。 手動では、インデックスを作りなおせば消えます。 > ここが仮に精度上がったとしても MySQL の Planner でのメリットは無さそう > なので、見積0件でも1件と返すという事なのですね。 先頭nキーにレコードがないときは全体をみてもそんなにないこと の方が多いと思うので、1件とか少ない件数を返すのはプランナー にそんなに悪くない情報を提供できていると思うんですけど ねぇ。。。 -- 須藤 功平 <kou****@clear*****> 株式会社クリアコード <http://www.clear-code.com/> Groongaベースの全文検索システムを総合サポート: http://groonga.org/ja/support/ パッチ採用 - プログラミングが楽しい人向けの採用プロセス: http://www.clear-code.com/recruitment/ リーダブルコードワークショップ: http://www.clear-code.com/services/code-reader/readable-code-workshop.html
