groonga 試してみた、のその後

ちょっと感想をメモ。

  • 試してみた状況
    • すでに動いている master (fulltext key なし) に、どでかいテーブル 1 つを ENGINE=gronnga にした slave をいれた
    • カラムは id INT NOT NULL auto_increment, foo text, PRIMARY KEY (id), FULLTEXT KEY (foo) みたいな感じ
    • auto_increment は現在 5 億数千万くらいで、 MYD で言うと 70GB くらい。
  • 全般的な感想
    • ふつうに使うぶんにはだいたい動いてる
    • 慣れてない (or 枯れてない) に由来するオペミスの意味で、データロストの危険はあるとおもう
    • まだ本格投入 (正常に動いてる前提なサービス) は厳しい気がする
  • auto_increment はちゃんと動いてる
    • 去年ばっと話題になった時点では auto_increment 未対応だったような気がしますが、いまんとこちゃんと動いてます。
    • これを理由に「ねーな」と思った人は試してみるべき
  • multi column index は未対応
    • まあ、絶対必要な場面はよくわからん
  • fulltext key を使わないクエリはダメな場合がある
    • explain して pushed condition に行った場合に、残念な結果になることがあった。まだ調査中。
    • slave の 1 つなんで、別のサーバ向けちゃえばいいよ。とりあえず。
  • メモリをばんばん使っていく
    • ぎりぎりのところで動き続けている様子
    • なんとなく気持ち悪いが、データ保全のために定期的に mysqld 落としてスナップショットとっているのでいまんとこ大丈夫そう
    • myisam_use_mmap で flush tables 的なのはなさそう
  • ファイルたくさんできる
    • カラムの作り方次第ではありますが、tritonn で 120GB, InnoDB (compact, fulltext なし) で 200GB, mroonga で 140GB ってとこ。
    • けっこう I/O 激しめ。
  • パフォーマンスは、ちゃんと見てません
    • 現状の肥大化した tritonn がヤバすぎなので比較対象としては意味ないが、それよりかはサクサク動いてます。
  • その他
    • load data を 5 億件やったら死んだ
      • GRN_IO_SEG_REF で mmap failed!!! と言われた
      • 1 億件 load -> mysqld restart 繰り返したらいけました。
    • (たぶん) slave sql が insert 中に mysqld 落としたらデータロスト
      • duplicate key で slave 止まってたので skip counter したら特定のカラムだけ空っぽのデータが入っちゃってた
      • 1回しか見かけてないので嘘かもしれないし MySQL 側の問題かも
        • transaction 中に stop slave すると rollback せずにやり直しちゃうとかありましたよね
    • しばらく負荷かけてたら lock failed
      • grn_io_lock が失敗して timeout
      • "groonga ./データファイル" して、 clearlock して念のため mysqld restart したら動いてるようです。
      • これも GRN_ATOMIC_ADD_EX に失敗してる系かな?

なんにしても、 MySQL で動く限り (fulltext 使わない件のように) MySQL 的運用の仕方が援用できるので、 tritonn が破綻寸前な人はけっこうよさそうですね。よくあるストーリーとしては「tritonn でデータ増えすぎ → partition 使えたらその場凌げそうだけど mysql-5.0 なんだよな → groonga で 5.1 以降にいける! 」なんじゃないかなー。

にしても、この例ではデータ多すぎなようです。斯波さんも参加してることだし、やっぱ spider に行くべきですかね。