レポート

モーショノロジー2012 #1「検索はシステムを救う」実施レポート

この記事を読むのに必要な時間:およそ 5.5 分

CROOZMALLでの全文検索の課題と検証

CROOZ株式会社の長谷川さんからはECサイト「CROOZMALL」の検索機能についての課題と検証についてお話しいただきました。

画像

これまで同社は,MySQL5.1.x系に形態素解析をMeCabを利用し,ストレージエンジンはMyISAMを利用していました。しかしながら,爆発的に増え続ける商品や何パターンものソート処理など運用する上で,テーブルロックなどが発生することがあり,運用でカバーしつつも問題になりつつありました。

辞書を熟成するべくMeCabを利用した解析の方法も問題ではありましたが,それより先に今後爆発的に増えていくデータに適したシステム的な理想を整理するのが先決だという結論に至りました。

まずECサイトにおける「検索」に期待する事をきちんと定義し,その中から検索の位置づけを定義付けます。ECサイトを運用する目的は多くのユーザに買っていただくことであるため,ECサイトにおける検索システムは買っていただくための確率を上げる事が目的です。

検索対象の商品が無かったとしても「not fond」と正直レスポンスをしては行けません。そこからさらにバック系のシステムで近似検索をかけたりすると同時に,無かった商品に関しては拡充することができないか営業,マーケティングに活用する必要があります。

CROOZでは今後,EC系モールシステムと既存のBlog,コーデノートなど商品と直結できるシステムを構築し,ビックデータマイニングを実現する方法を検討しています。このあたりの詳細は,勉強会内でもお話ししたのですが,今回はテーブルロックを回避するためにgroongaストレージエンジンを検証したので,その内容を紹介します。

図1 groongaストレージエンジンの導入,インストール

rpm -ivh http://packages.groonga.org/centos/groonga-repository-1.0.0-0.noarch.rpm
yum update
yum -y install MySQL-client
yum -y install MySQL-devel
yum -y install MySQL-embedded
yum -y install MySQL-server
yum -y install MySQL-shared
yum -y install MySQL-test
yum install -y groonga groonga-tokenizer-mecab groonga-devel
yum -y install mysql-groonga
mysql -u root
mysql> INSTALL PLUGIN groonga SONAME 'ha_groonga.so';
mysql> CREATE FUNCTION last_insert_grn_id RETURNS INTEGER soname 'ha_groonga.so';
mysql> SHOW ENGINES;
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
| Engine             | Support | Comment                                                        | Transactions | XA   | Savepoints |
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
| InnoDB             | DEFAULT | Supports transactions, row-level locking, and foreign keys     | YES          | YES  | YES        |
| CSV                | YES     | CSV storage engine                                             | NO           | NO   | NO         |
| MyISAM             | YES     | MyISAM storage engine                                          | NO           | NO   | NO         |
| BLACKHOLE          | YES     | /dev/null storage engine (anything you write to it disappears) | NO           | NO   | NO         |
| MRG_MYISAM         | YES     | Collection of identical MyISAM tables                          | NO           | NO   | NO         |
| MEMORY             | YES     | Hash based, stored in memory, useful for temporary tables      | NO           | NO   | NO         |
| groonga            | YES     | CJK-ready fulltext search, column store                        | NO           | NO   | NO         |
| PERFORMANCE_SCHEMA | YES     | Performance Schema                                             | NO           | NO   | NO         |
| FEDERATED          | NO      | Federated MySQL storage engine                                 | NULL         | NULL | NULL       |
| ARCHIVE            | YES     | Archive storage engine                                         | NO           | NO   | NO         |
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
10 rows in set (0.00 sec)

centOS5系にて実施。実際の環境によって手順など異なることがあります。

表2 データ(約38万件)サイズ(約128MB)のinsert検証

単独INSERTMyISAMgroonga
Real2m22.907s1m33.408s
User0m9.024s0m7.599s
Sys0m3.334s0m2.867s

表3 insert時のランダムselectテスト(本番サービスでの利用は難しいですが,MyISAM側は明示的にロックは行わずに検証を実施)

 MyISAM(ロックせず検証)groonga
SELECT(回/秒)INSERT(回/秒)SELECT(回/秒)INSERT(回/秒)
30~ 60万件
(INSERTのみ)
 2714 4135
60~ 90万件
(INSERTのみ)
 2341 3710
90~120万件
(INSERTのみ)
 2276 3533
120万件
(SELECTのみ)
610 208 
120~150万件
(SELECT+INSERT)
1232156175746
150万件
(SELECTのみ)
509 180 
150~180万件
(SELECT+INSERT中)
962019168667
180万件
(SELECTのみ)
406 165 

全体的にinsertに関する処理は圧倒的にgroongaの方が高速であることがわかりました。また,selectに関してはMyISAMに軍配が上がるものの,明示的にロックせずに参照していること,実際のクエリを完全に一致させることが難しく,取り急ぎ行ってみたといった感じの検証であるため,今後,参照側もチューニングなどを重ねるに連れてgroongaストレージエンジンを採用する可能性(使いどころの検討)が高まってくるかと思います。

当日利用したスライドは以下で公開されています。ぜひご覧ください。

20120126-mnlgy-1-11336943
URL:http://www.slideshare.net/sususlideshare/20120126-mnlgy-1-11336943

全文検索のちょっとちがった使い方(仮)

グリー株式会社でログ分析システムに従事している一井さんよりお話しいただきました。

画像

グリーでの数値指標管理では,基本となるデータ総数が「1億キー×最大7年」と現時点でも膨大な上に,現在でも時間と共に増えるアプリIDと組み合わせる必要があり,よくある「あのキーってなんだっけ?」「PV? pageview?」⁠そもそもこの数値って事前集計されてるんだっけ?」といった問題が頻繁に起こり,人間が管理するには限界があると感じていたそうです。

今ではHadoopやMongoDBなどの選択肢もある中,あえてそれらを利用せず,⁠MySQLでKVS」という構成で行っています。どうしてこの構成で行けると思っているかというと,やはり担当者が膨大なデータに埋まることなく,主たる目的を理解しているためです。

スライドにも記載されていた通り,

  • やりたいことはただのKVS
    • ただしkeyの種類がものすごく多い
    • keyは人間が扱うので,記憶はあやふや
  • 種類が多いぶん,それなりに構造は持っている/パターンも決まってはいる

と問題,要件を整理します。そして全文検索でkeyを探すのです。

  • 構造があるkeyでも,単にserializeして書いておけばよい
  • keystringに対して全文検索
  • 必要なkeyがわかれば,あとはいつものKVS

こうすると,MySQLに慣れていれば運用的にもメリットがあり,当面はこの構成で問題ないとのことでした。

ただし,このパターンはユーザなどの第三者が検索ワードを入力する事などは想定しておらず,自分言語に近い形でkeyを作成する事が前提となります。しかし全文検索をこのように利用することで自社の抱える問題が解決し,増え続けるデータに担当者がつぶれてしまったり,新しいプロダクトやソリューションに手を出す必要が無い可能性もあるという点では,面白いアプローチかと思います。

他にもいろいろとお話しいただいたのですが,詳細は以下で公開されています。ぜひご覧ください。

Ichii gree-crooz-20120126
URL:http://www.slideshare.net/ichii386/ichii-greecrooz20120126

著者プロフィール

高岡将(たかおかすすむ)

大手金融,独立系SIerにて気がつけば計18年以上のキャリアを重ねる。バランス感覚に長け,インフラ/アプリ,プレイヤ/マネージャなど関係なくこなし,「いそうだけどいないタイプ」と評価される。

仕事以外では,自転車,ジョギング,サックス等を趣味にし,密かに「エンジニアと健康」についてダイエット成功論の連載を企む。