Haruka Yoshihara
null+****@clear*****
Fri Dec 7 13:19:07 JST 2012
Haruka Yoshihara 2012-12-07 13:19:07 +0900 (Fri, 07 Dec 2012) New Revision: 945b5e7d7e54e68423d653ceb2ddcb0166b66726 https://github.com/groonga/groonga.github.com/commit/945b5e7d7e54e68423d653ceb2ddcb0166b66726 Log: Add more info my Mr. isobe in groonga-night-3 refs #1508 Modified files: ja/publication/groonga-night-3-isobe.html Modified: ja/publication/groonga-night-3-isobe.html (+96 -17) =================================================================== --- ja/publication/groonga-night-3-isobe.html 2012-12-06 19:00:37 +0900 (72f85cb) +++ ja/publication/groonga-night-3-isobe.html 2012-12-07 13:19:07 +0900 (60480d3) @@ -6,10 +6,12 @@ title: mroongaを使った、高速な対訳検索＆ダウンロードシステ <h2>発表の資料</h2> <p>発表時の資料はこちらになります。</p> <p><a href="presentation/groonga-night-3-isobe.pdf">mroongaを使った、高速な対訳検索＆ダウンロードシステムについて</a></p> - <p>また、全文検索エンジンgroongaを囲む夕べ3が終了した後、発表者の磯部さんが発表内容のシステムで追試の実験を行い、結果をご送付いただきました。それをまとめたものを次のセクションに掲載しています。</p> - <p>発表時の資料と合わせてご覧ください。</p> <h2>追試の情報</h2> + <p>全文検索エンジンgroongaを囲む夕べ3が終了した後、発表者の磯部さんが発表内容のシステムで追試の実験を行い、結果をご送付いただきました。それをまとめたものを次のセクションに掲載しています。</p> + <p>発表時の資料と合わせてご覧ください。</p> + + <h3>Swapによって検索速度が変化するかどうかの検証</h3> <p>発表で話した同じ型のキューブPC（HDDはSATA3）の別マシンにて、HDD上に単一テーブルとしてmroongaのDBを構成しました。そのDBに対してSQLを1つ実行したところ、19672件取得するのに6m41.472sかかりました。発表で紹介したシステム（テーブルを8分割した場合）だと、１秒ちょっとです。 </p> <p>この時実行したSQLの概要は次のようになっています。</p> <ul> @@ -23,21 +25,15 @@ title: mroongaを使った、高速な対訳検索＆ダウンロードシステ <p>これは、5秒間隔でサンプリングし、単位はMBで表示することを示しています。このコマンドの結果は下記のようになりました。<p> <pre> -procs -----------memory---------- ---swap-- -----io---- --system-- ------cpu----- -r b swpd free buff cache si so bi bo in cs us sy id wa st -0 1 0 234 4 29272 0 0 6 39 0 1 2 1 97 0 0 -0 1 0 238 2 29263 0 0 16930 0 260 583 0 0 87 12 0 -0 1 0 237 2 29263 0 0 15630 0 218 521 0 0 87 12 0 -0 1 0 227 2 29274 0 0 14932 0 199 488 0 0 87 12 0 -0 1 0 230 2 29272 0 0 15733 0 223 526 0 0 87 12 0 -0 1 0 230 2 29273 0 0 16881 0 224 547 0 0 88 12 0 -1 0 0 229 2 29274 0 0 17005 1 244 541 0 0 88 12 0 -0 1 0 223 2 29286 0 0 15174 0 215 507 0 0 88 12 0 -0 1 0 225 2 29284 0 0 14918 0 201 490 0 0 87 12 0 -0 1 0 236 2 29274 0 0 14257 0 208 485 0 0 87 12 0 -0 1 0 239 2 29272 0 0 16314 2 228 529 0 0 88 12 0 -p0 1 0 235 2 29277 0 0 17025 0 232 567 0 0 88 12 0 +procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu----- + r b swpd free buff cache si so bi bo in cs us sy id wa st + 0 1 0 17638 3 15021 0 0 2603 2 65 57 0 3 94 3 0 + 0 1 0 17470 3 15188 0 0 32540 0 368 997 0 0 88 12 0 + 0 1 0 17338 3 15320 0 0 25758 0 284 768 0 0 88 12 0 + 0 1 0 17214 3 15443 0 0 24138 0 265 740 0 0 88 12 0 + 0 1 0 17087 3 15569 0 0 24658 0 269 752 0 0 88 12 0 + 0 1 0 16940 3 15716 0 0 28556 0 308 853 0 0 88 12 0 + 0 1 0 16800 3 15856 0 0 27324 0 312 850 0 0 88 12 0 </pre> <p>「bi」（ディスクから読み込んだ量）の欄を見ると、物凄い勢いでDiskを読んでいることがわかります。今回のPCは8CPUですので、「wa」欄（I/O待ち）の12%は、１CPU分フルに発生している状況です。</p> <p>この時のメモリの状況です。</p> @@ -52,4 +48,87 @@ Swap: 1998 0 1998 <p>Swapは全く発生していません。よって、Swapは関係なく、単純にディスクの読み込みで遅いことがわかります。</p> <p>つまり、BI的に、一括で大量のデータを取得する場合には、プレゼンのように、データをRAM-Disk上に置くのが有効である事が判ります。第1システムでのSWAPがある状況だと遅いと言う推測は外れでした。</p> <p>また、twitterでのつぶやきを見ると、5千万件以下の場合はテーブルのパーティショニングは必要ないかもしれない、ということなので、テーブルの分割は必要ないかもしれません。</p> + + <h3>テーブルを分割しない場合の速度</h3> + <p>発表では8分割していたテーブルを1つに纏めたもので更に追試しました。</p> + <p>※正確には、日本語部分と英語部分が標準化されたデータなので英語と日本語のフィールド名と検索結果の件数が若干異なります。</p> + <p>下記が、今回の1つに纏まったテーブルに対する検証用スクリプトです。</p> + <p>HDD上のDBに対するスクリプト：</p> + <pre> +$ cat test.sh +export DB=TAIYAKU_DB +echo 'select * from TAIYAKU_DATA where match(EN_TEXT) against +('\''blue'\'' in boolean mode)' | do_sql + </pre> + + <p>RAM-Disk上のDBに対するスクリプト：</p> + <pre> +$ cat test_u.sh +export DB=TAIYAKU_DB_Unified +echo 'select * from TAIYAKU_DATA where match(EN_TEXT_JUNKANZEN_ICCHI) +against ('\''blue'\'' in boolean mode)' | do_sql + </pre> + + <p>上記スクリプト内にある、"do_sql"は自作のSQLラッパーで、環境変数のHOSTで接続先IPを、DBでデータベース名を指定してSQLを実行します。また、TAIYAKU_DBはHDD上のDBで、TAIYAKU_DB_UnifiedはRAM-Disk上のDBです。両方のDBとも、件数は下記のように同一です。</p> + <pre> +$ env DB=TAIYAKU_DB count TAIYAKU_DATA +35201206 +$ env DB=TAIYAKU_DB_Unified count TAIYAKU_DATA +35201206 + </pre> + + <p>上記の"count"は、先ほどの"do_sql"の更なるラッパーで、件数を取得します。これらスクリプトの実行速度と、検索結果の行数は下記のとおりです。</p> + <p>HDD上のDBに対する実行：</p> + <pre> +$ time bash test_u.sh > /tmp/a +real 0m0.662s +user 0m0.147s +sys 0m0.017s + </pre> + <p>検索結果：</p> + <pre> +$ wc -l /tmp/a +19996 /tmp/a + </pre> + + <p>RAM-Disk上のDBに対する実行：</p> + <pre> +$ time bash test.sh > /tmp/b +real 4m44.247s +user 0m0.169s +sys 0m0.026s + </pre> + <p>検索結果：</p> + <pre> +$ wc -l /tmp/b +19672 /tmp/b + </pre> + + <h3>RAM-DiskへのDBの設置</h3> + <p>HDD上の、/var/lib/mysql/mroonga.data/に本来のmroongaファイルが格納されています。</p> + <pre> +$ cd /var/lib/mysql/mroonga.data/ +$ ls -l +（中略） +drwx------ 2 mysql mysql 4096 12月 6 12:52 2012 TAIYAKU_DB_Unified +（中略） + </pre> + + <p>このTAIYAKU_DB_Unifiedが本来のmroongaファイルです。PCの再起動などを行った時は、下記のようにしてRAM-DiskにTAIYAKU_DB_Unifiedをコピーします。</p> + <pre> +cd /var/lib/mysql/mroonga.data/ +cp -rp TAIYAKU_DB_Unified /dev/shm/mysql/ + </pre> + + <p>また、最初にRAM-Disk上のDBからHDD上にシンボリックリンクを作成する時は、下記のようにしました。</p> + <pre> +$ cd /var/lib/mysql/mroonga.data/ +$ for F in $(ls /dev/shm/mysql/TAIYAKU_DB_Unified/TAIYAKU_DB_Unified.mrn*); do ln -s $F; +done + </pre> + + <p>再起動後も、シンボリックリンクは残っているので次のコマンドを実行してから上記のコピーをするだけです。</p> + <pre> +$service mysqld stop + </pre> </section> -------------- next part -------------- HTML����������������������������...Download