発表時の資料はこちらになります。全文検索エンジンgroongaを囲む夕べ3が終了した後、発表者の磯部さんが発表内容のシステムで追試の実験を行い、結果をご送付いただきました。それをまとめたものを次のセクションに掲載しています。発表時の資料と合わせてご覧ください。発表で話した同じ型のキューブPC(HDDはSATA3)の別マシンにて、HDD上に単一テーブルとしてmroongaのDBを構成しました。そのDBに対してSQLを1つ実行したところ、19672件取得するのに6m41.472sかかりました。発表で紹介したシステム(テーブルを8分割した場合)だと、1秒ちょっとです。この時実行したSQLの概要は次のようになっています。英語、又は日本語の「単語又はフレーズ一致」でありその英語欄と日本語欄にはmroongaのインデックスが張ってあるその他のフィールドはselectの出力には含まれるが、where句では指定していない「blue」というありふれた単語で検索したので大量にヒットしたこのSQLの実行途中に、仮想メモリの状況を調べるために次のコマンドを実行しました。mこれは、5秒間隔でサンプリングし、単位はMBで表示することを示しています。このコマンドの結果は下記のようになりました。0「bi」(ディスクから読み込んだ量)の欄を見ると、物凄い勢いでDiskを読んでいることがわかります。今回のPCは8CPUですので、「wa」欄(I/O待ち)の12%は、1CPU分フルに発生している状況です。この時のメモリの状況です。1998Swapは全く発生していません。よって、Swapは関係なく、単純にディスクの読み込みで遅いことがわかります。BI的に、一括で大量のデータを取得する場合には、プレゼンのように、データをRAM-Disk上に置くのが有効である事が判ります。第1システムでのSWAPがある状況だと遅いと言う推測は外れでした。twitterでのつぶやきを見ると、5千万件以下の場合はテーブルのパーティショニングは必要ないかもしれない、ということなので、テーブルの分割は必要ないかもしれません。発表では8分割していたテーブルを1つに纏めたもので更に追試しました。※正確には、日本語部分と英語部分が標準化されたデータなので英語と日本語のフィールド名と検索結果の件数が若干異なります。下記が、今回の1つに纏まったテーブルに対する検証用スクリプトです。do_sql上記スクリプト内にある、"do_sql"は自作のSQLラッパーで、環境変数のHOSTで接続先IPを、DBでデータベース名を指定してSQLを実行します。TAIYAKU_DBはHDD上のDBで、TAIYAKU_DB_UnifiedはRAM-Disk上のDBです。両方のDBとも、件数は下記のように同一です。TAIYAKU_DATA35201206上記の"count"は、先ほどの"do_sql"の更なるラッパーで、件数を取得します。これらスクリプトの実行速度と、検索結果の行数は下記のとおりです。/tmp/bRAM-DiskへのDBの設置HDD上の、/var/lib/mysql/mroonga.data/に本来のmroongaファイルが格納されています。TAIYAKU_DB_Unified(中略)このTAIYAKU_DB_Unifiedが本来のmroongaファイルです。PCの再起動などを行った時は、下記のようにしてRAM-DiskにTAIYAKU_DB_Unifiedをコピーします。/dev/shm/mysql/また、最初にRAM-Disk上のDBからHDD上にシンボリックリンクを作成する時は、下記のようにしました。$F;done再起動後も、シンボリックリンクは残っているので次のコマンドを実行してから上記のコピーをするだけです。2.1の下でリリースされています。