2006-08-02

メモ

MySQL InnoDB

おなかへったー。でもうちには食べ物が何もないよ。

page_header_set_field関数他で頻繁に登場するut_adは通常のビルドでは何もしない。

#ifdef UNIV_DEBUG
#define ut_ad(EXPR)  	ut_a(EXPR)
#define ut_d(EXPR)	do {EXPR;} while (0)
#else
#define ut_ad(EXPR)
#define ut_d(EXPR)
#endif

とりあえず、以下のコードは、

UNIV_INLINE
void
page_header_set_field(
/*==================*/
	page_t*	page,	/* in: page */
	ulint	field,	/* in: PAGE_LEVEL, ... */
	ulint	val)	/* in: value */
{
	ut_ad(page);
	ut_ad(field <= PAGE_N_RECS);
	ut_ad(field == PAGE_N_HEAP || val < UNIV_PAGE_SIZE);
	ut_ad(field != PAGE_N_HEAP || (val & 0x7fff) < UNIV_PAGE_SIZE);

	mach_write_to_2(page + PAGE_HEADER + field, val);
}

こう読んでしまってよいっぽい。

UNIV_INLINE
void
page_header_set_field(
/*==================*/
	page_t*	page,	/* in: page */
	ulint	field,	/* in: PAGE_LEVEL, ... */
	ulint	val)	/* in: value */
{
	mach_write_to_2(page + PAGE_HEADER + field, val);
}

というか亀田の世界戦、かなりしんどかったですね〜。奇跡的な判定勝利。

2006-08-02

性能検証とか

MySQL Senna

条件は以下。

データ量は850MB（日本語版Wikipedia）あるいは3.4GB（日本語版Wikipedia x4）
マシンはDELL PowerEdge750(Pen4 3.2GHz HT無し、RAM2GB）要するに低スペックマシン、あるいはPowerEdge1850（Xeon 3.4GHz HT有り x2個、RAM 4GB、RAID 0有り）要するに普通のマシン
OSはLinux Kernel 2.6系、MySQLは5.0系です
key_buffer=512M、myisam_sort_buffer_size=512M、read_buffer_size=2M
C実装の独自ツールによるラッシュテスト、同時スレッド数は1〜192にて

でもって雑感。

LIKE演算子+ワイルドカードによる部分一致検索（MyISAM）と比べると、MySQL+Sennaは平均して1000倍以上の参照スループットを発揮します。もう部分一致検索なんてやってられないよっ！
ただし、SennaによるFULLTEXTインデックス無し（MyISAM）のときと比べると、PowerEdge750だと更新性能は平均して50%程度落ちます。PowerEdge1850だとFULLTEXTインデックス無しの更新性能がCPU性能+RAID0によりかなり向上（3倍以上)するのですが、Sennaを使った場合の向上は2倍程度にとどまります。つまり更新処理が肝。
MeCabを使った場合とN-gramを使った場合とを比べると、MeCabの方が参照性能が圧倒的に高いスループットを出します。MeCabとN-gramでは3倍程度の差があります。
ただし更新性能はN-gramの方がMeCabよりも30%-50%程度良いです。従って、検索結果の適合率・再現率のお話を別として単に性能だけで選ぶとすると、更新性能がボトルネックの場合はN-gram、そうでない場合にはMeCabがお奨めとなります。
また基本的に、OSのファイルキャッシュに乗っている場合とそうでない場合とで参照性能のスループットは100倍くらいは簡単に差がつきますのでその辺はご注意を。

という感じでしょうかね。