tritonn使おうかな。
従いまして、MySQLにこのパッチを適用した場合、変わるのは基本的にはMyISAMのFULLTEXTインデックスの振る舞いのみで、後はこれまでと同様となっています。またこの図をご覧頂くとお分かりになるかと思いますが、MySQLへアクセスするアプリケーションから見ると、MySQLの上位層がSennaを隠蔽しているため、アプリケーション側で特にSennaを意識する必要はありません。
MATCH/AGAINSTを使ったSELECTでちょっぱやになる代わりに、
気になるのは、
INSERT時にどれだけ遅くなるのか?
実データに近い環境で計測してみる
test table<br />
+--------------+---------------------------+------+-----+---------------------+----------------+<br />
| Field | Type | Null | Key | Default | Extra |<br />
+--------------+---------------------------+------+-----+---------------------+----------------+<br />
| id | int(10) unsigned | NO | PRI | NULL | auto_increment |<br />
中略<br />
| title | varchar(255) | NO | | | |<br />
| description | text | YES | | NULL | |<br />
中略<br />
+--------------+---------------------------+------+-----+---------------------+----------------+<br />
14 rows in set (0.00 sec)</p>
<p>mysql> select count(*) from test;<br />
+----------+<br />
| count(*) |<br />
+----------+<br />
| 16648 |<br />
+----------+<br />
1 row in set (0.00 sec)</p>
<p>santrini% mysqldump testdb test -u root -p "--where=id >=19000" > mysqldump_test_over_19000.log<br />
このあとinsert文だけにしておく</p>
<p>mysql> delete from test where id>=19000;<br />
Query OK, 887 rows affected (0.90 sec)</p>
<p>santrini% /usr/sbin/mysqld --version<br />
/usr/sbin/mysqld Ver 5.0.51a-9+lenny2-log for debian-linux-gnu on x86_64 ((Debian))</p>
<p>santrini% cat bench.sh<br />
mysql testdb -u root --password=*********** < mysqldump_test_over_19000.log</p>
<p>santrini% /usr/bin/time ./bench.sh<br />
0.02user 0.01system 0:00.19elapsed 16%CPU (0avgtext+0avgdata 0maxresident)k<br />
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 (c) 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されたら見つからないかも、っていうのを許容できる人向けに。