ちょっと感想をメモ。
- 試してみた状況
- すでに動いている 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 つなんで、別のサーバ向けちゃえばいいよ。とりあえず。
- メモリをばんばん使っていく
- ファイルたくさんできる
- パフォーマンスは、ちゃんと見てません
- 現状の肥大化した 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 に失敗してる系かな?
- load data を 5 億件やったら死んだ
なんにしても、 MySQL で動く限り (fulltext 使わない件のように) MySQL 的運用の仕方が援用できるので、 tritonn が破綻寸前な人はけっこうよさそうですね。よくあるストーリーとしては「tritonn でデータ増えすぎ → partition 使えたらその場凌げそうだけど mysql-5.0 なんだよな → groonga で 5.1 以降にいける! 」なんじゃないかなー。
にしても、この例ではデータ多すぎなようです。斯波さんも参加してることだし、やっぱ spider に行くべきですかね。