狠狠撸

Mroongaを使ったときの
MySQLの制限との戦い
Naoya(@naoa_y)
MySQL勉強会 in 大阪(第6回)
2014/4/24

LTやったことありません！
はじめに

● 大学は情報系
● 新卒で３年半ほど金融系のユーザSIでインフラSE
● 現在は３年半ほどITと無縁の仕事
自己紹介

やりたいこと
100種類以上の書誌事項が
あってサイズが400GiBぐ
らいで1000万レコードぐ
らいのデータベースを高
速に全文検索したい

サラリーマンなんで
できるだけ安く！
コスト

使ったもの
●
データベース
MySQL5.6.14
●
全文検索エンジン
Mroongaストレージエンジン

テーブルって正規化すれ
ばいいんでしょ？
知ってる知ってる。
教科書のってた。

正規化してJOINして
全文検索っと

mysql> EXPLAIN SELECT COUNT(*) FROM ftext INNER JOIN applicants ON applicants.id = ftext.id WHERE MATCH(title,abstract,description) AGAINST("+装置
" in boolean mode);
+----+-------------+------------+----------+---------------+---------+---------+----------------------+------+-----------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+------------+----------+---------------+---------+---------+----------------------+------+-----------------------------------+
| 1 | SIMPLE | ftext | fulltext | PRIMARY,ftext | ftext | 0 | NULL | 1 | Using where with pushed condition |
| 1 | SIMPLE | applicants | ref | PRIMARY | PRIMARY | 62 | test_relate.ftext.id | 4850 | NULL |
+----+-------------+------------+----------+---------------+---------+---------+----------------------+------+-----------------------------------+
2 rows in set (0.02 sec)
mysql> SELECT COUNT(*) FROM ftext INNER JOIN applicants ON applicants.id = ftext.id WHERE MATCH(title,abstract,description) AGAINST("+装置" in
boolean mode);
+----------+
| COUNT(*) |
+----------+
| 378523 |
+----------+
1 row in set (30.92 sec)
mysql> SHOW PROFILE;
+-------------------------+-----------+
| Status | Duration |
+-------------------------+-----------+
| starting | 0.002691 |
| checking permissions | 0.000007 |
| checking permissions | 0.000004 |
| Opening tables | 0.000022 |
| init | 0.000035 |
| System lock | 0.000010 |
| optimizing | 0.017265 |
| statistics | 0.009740 |
| preparing | 0.000014 |
| FULLTEXT initialization | 0.119833 |
| executing | 0.000010 |
| Sending data | 30.782097 |
| end | 0.000012 |
| query end | 0.000003 |
| closing tables | 0.000775 |
| freeing items | 0.000419 |
| logging slow query | 0.000002 |
| cleaning up | 0.000009 |
+-------------------------+-----------+
18 rows in set (0.00 sec)
データベースサイズが20GiBぐらいの例
全文検索+JOIN

全文検索しつつ大量のレ
コードをJOINしてパ
フォーマンスを保つのっ
てむずかしいんです
ね。。

Mroongaには、ベクターカ
ラムっていうのがあっ
て、1カラムに複数の値が
いれられるらしい。
(groonga-dev情報)

Mroongaのストレージモー
ドでは、SELECTとかUPDATE
とかでカラムを指定してや
ればカラム刈り込みが発生
するらしい。

じゃあ、テーブルを１つ
にしてしまおう！

てーぶるていぎ。
※わざわざディスプレイ
を縦にしました

くそみたいなテーブル
定義ですね。
まぁそれはおいておいて、
つくってみましょう。

ERROR 1069 (42000):
Too many keys specified;
max 64 keys allowed

インデックスは1テーブル
につき64個までしか許可
されていないそうで。。

Groongaにはそんな制限は
ありません。

こんなエラーこの世から
なくなってしまえばいい

sql/sql_table.cc
before
3696 if (key->name.str != ignore_key)
3697 key_parts+=key->columns.elements;
3698 else
3699 (*key_count)--;
3700 if (key->name.str && !tmp_table && (key->type != Key::PRIMARY) &&
3701 !my_strcasecmp(system_charset_info, key->name.str, primary_key_name))
3702 {
3703 my_error(ER_WRONG_NAME_FOR_INDEX, MYF(0), key->name.str);
3704 DBUG_RETURN(TRUE);
3705 }
3706 }
3707 tmp=file->max_keys();
3708 if (*key_count > tmp)
3709 {
3710 my_error(ER_TOO_MANY_KEYS,MYF(0),tmp);
3712 }
3713
3714 (*key_info_buffer)= key_info= (KEY*) sql_calloc(sizeof(KEY) * (*key_count));
3715 key_part_info=(KEY_PART_INFO*) sql_calloc(sizeof(KEY_PART_INFO)*key_parts);
3716 if (!*key_info_buffer || ! key_part_info)
3717 DBUG_RETURN(TRUE); // Out of memory
3718
3696 if (key->name.str != ignore_key)
3697 key_parts+=key->columns.elements;
3698 else
3699 (*key_count)--;
3700 if (key->name.str && !tmp_table && (key->type != Key::PRIMARY) &&
3701 !my_strcasecmp(system_charset_info, key->name.str, primary_key_name))
3702 {
3703 my_error(ER_WRONG_NAME_FOR_INDEX, MYF(0), key->name.str);
3705 }
3706 }
3707 tmp=file->max_keys();
3708
3709
3710
3711
3712
3713
3714 (*key_info_buffer)= key_info= (KEY*) sql_calloc(sizeof(KEY) * (*key_count));
3715 key_part_info=(KEY_PART_INFO*) sql_calloc(sizeof(KEY_PART_INFO)*key_parts);
3716 if (!*key_info_buffer || ! key_part_info)
3717 DBUG_RETURN(TRUE); // Out of memory
3718
after

ひとつのエラーが
この世から消えました

もっかいつくって
みましょう

ERROR 1071 (42000):
Specified key was too long;
max key length is 3072 bytes

エラーメッセージが
変わった！
やった！(やってない)

1テーブルの合計最大キー長
は3072バイトだそうで。。

sql/sql_table.cc
before after
4001 if (key->type == Key::MULTIPLE)
4002 {
4003 /* not a critical problem */
4004 push_warning_printf(thd, Sql_condition::WARN_LEVEL_WARN,
4005 ER_TOO_LONG_KEY, ER(ER_TOO_LONG_KEY),
4006 key_part_length);
4007 /* Align key length to multibyte char boundary */
4008 key_part_length-= key_part_length % sql_field->charset->mbmaxlen;
4009 /*
4010 If SQL_MODE is STRICT, then report error, else report warning
4011 and continue execution.
4012 */
4013 if (thd->is_error())
4014 DBUG_RETURN(true);
4015 }
(中略)
4054 {
4055 /* not a critical problem */
4056 push_warning_printf(thd, Sql_condition::WARN_LEVEL_WARN,
4057 ER_TOO_LONG_KEY, ER(ER_TOO_LONG_KEY),
4058 key_part_length);
4061 /*
4064 */
4067 }
4002 {
4003
4004
4005
4006
4009 /*
4012 */
4015 }
(中略)
4054 {
4055
4056
4057
4058
4061 /*
4064 */
4067 }

もう一度つくって
みましょう

エラーなし。
テーブルつくれました。
やった！！！

mysql> SELECT COUNT(*) FROM ftext WHERE
MATCH(title,abstract,claims,freeword,description_19xx,description_200x,description_201
x,description_ocr) AGAINST("+データベース"　in boolean mode) AND kind LIKE "A%";
+----------+
| COUNT(*) |
+----------+
| 326093 |
+----------+
1 row in set (3 min 52.77 sec)
全文検索+その他絞込み(最適化なし)

全文検索しつつその他の
条件で絞込みって、レ
コード数が多いとイン
デックスが使われないか
らかなり遅いんです
ね。。

Mroongaには複数のイン
デックスが使われるよう
に最適化される所定の条
件があります。

Groongaの構文を使えば複数
インデックスが使えるよう
になる方法があります。
(groonga-dev情報)

ややこしい
ので方法は割愛。
興味ある方は以下を参照
http://blog.createfield.com/entry/2014/04/13/170301

全文検索+その他絞込み(最適化あり)
mysql> SELECT COUNT(*) FROM ftext WHERE
MATCH(title,abstract,claims,freeword,description_19xx,description_200x,description_201
x,description_ocr) AGAINST("+データベース +kind:A*" in boolean mode);
+----------+
| COUNT(*) |
+----------+
| 326093 |
+----------+
1 row in set (0.40 sec)

400GiBのデータベースが
サーバ1台でそこそこ実用
的な速度に！やった！

まとめと補足
● 全文検索しつつ大量のレコードをJOINしてパフォーマンスを保
つのは難しい。ベクターカラムを使うと１対ｎの関係でもテー
ブルを1つにまとめることができる。カラムストアなのでカラ
ム増による性能への影響は軽微。
●
インデックスは1テーブルに64個まで。
エラー処理を回避すればMroongaでは64個以上使用可。
(補足) MAX_INDEXESのCMAKEオプションがあるみたいだったが、なぜかMyISAMのイ
ンデックスが使えなくなったのでソース改変で回避。
● 1テーブルの最大合計キー長は3072byteまで。
エラー処理を回避すればMroongaでは3072byte以上使用可。
(補足) InnoDBでは3500バイトに制限されている記載がドキュメントに有。
● 全文検索の他に絞込み条件を追加して高速に検索するためには
最適化条件を守るか、Groongaの構文を使う必要がある。

ありがとうございました

狠狠撸

Mroongaを使ったときの MySQLの制限との戦い

Recommended

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Mroongaを使ったときの MySQLの制限との戦い (20)

Mroongaを使ったときの MySQLの制限との戦い