tritonn使おうかな。
これがいい
Tritonnを使うとMySQLはどう変わるの?
従いまして、MySQLにこのパッチを適用した場合、変わるのは基本的にはMyISAMのFULLTEXTインデックスの振る舞いのみで、後はこれまでと同様となっています。またこの図をご覧頂くとお分かりになるかと思いますが、MySQLへアクセスするアプリケーションから見ると、MySQLの上位層がSennaを隠蔽しているため、アプリケーション側で特にSennaを意識する必要はありません。
MATCH/AGAINSTを使ったSELECTでちょっぱやになる代わりに、
気になるのは、
INSERT時にどれだけ遅くなるのか?
実データに近い環境で計測してみる
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
|
time/insert = 0.19[s] / 887[rows] = 0.000214[s]
mysqldをシンボリックリンクでtritonnのmysqldに向けて再起動
FULLTEXT INDEXはデフォルトのNGRAMを使用
`
santrini% /usr/sbin/mysqld –version
/usr/sbin/mysqld Ver 5.0.51a-modified for redhat-linux-gnu on x86_64 (MySQL Community Server (GPL) (portions © Tritonn Project))
mysql> delete from test where id>=19000;
Query OK, 887 rows affected (0.07 sec)
mysql> create fulltext index title_description on test(title,description);
Query OK, 15761 rows affected (7.23 sec)
Records: 15761 Duplicates: 0 Warnings: 0
mysql> show index from test;
+——-+————+——————-+————–+————-+———–+————-+———-+——–+——+————+———+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |
+——-+————+——————-+————–+————-+———–+————-+———-+——–+——+————+———+
| test | 0 | PRIMARY | 1 | id | A | 16648 | NULL | NULL | | BTREE | |
中略
| test | 1 | title_description | 1 | title | NULL | 1 | NULL | NULL | | FULLTEXT | |
| test | 1 | title_description | 2 | description | NULL | 1 | NULL | NULL | YES | FULLTEXT | |
+——-+————+——————-+————–+————-+———–+————-+———-+——–+——+————+———+
6 rows in set (0.00 sec)
santrini% /usr/bin/time ./bench.sh
0.02user 0.01system 0:15.89elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k`
time/insert = 15.89[s] / 887[rows] = 0.0175[s]
ベンチマーク方法自信無い。
前のはINDEX張ってないので目的は比較ではないのだが、目標スペックがないのでなんとも。
まー使ってみましょう。
INSERT時にインデクサ動かしてるんだろうなぁ。
クライアントへはすぐに制御を返して、裏で非同期でインデクサを動かすオプション、があってもいいのかも、と思った。
INSERT直後にSELECTされたら見つからないかも、っていうのを許容できる人向けに。