20120913 nosql@hikarie(okuyama fuse)

27
Kobe Digital Labo, Inc. 岩瀬 高博 Twitter: @okuyamaoo Mail: [email protected] https://github.com/okuyamaoo NOSQLで構築した分散MemoryFS上で MySQLを動かすとどうなるか?

description

2012/09/13にレバレジーズ様主催で開催されたNOSQLセミナーのLT資料です。 分散KVS okuyamaを利用したファイルシステム okuyamaFuseの紹介と性能評価です。

Transcript of 20120913 nosql@hikarie(okuyama fuse)

Page 1: 20120913 nosql@hikarie(okuyama fuse)

Kobe Digital Labo, Inc.

岩瀬 高博

Twitter: @okuyamaoo

Mail: [email protected]

https://github.com/okuyamaoo

NOSQLで構築した分散MemoryFS上でMySQLを動かすとどうなるか?

Page 2: 20120913 nosql@hikarie(okuyama fuse)

自己紹介 ・岩瀬 高博(@okuyamaoo)

> 株式会社 神戸デジタル・ラボ所属

業務及び活動

>大規模e-コマースサイトのチューニング、運用

>分散処理、データベースの研究及び適応

>(独)情報通信研究機構 特別研究員

研究領域:大規模Webアーカイブ

>分散KVS okuyama、CEP Setsuna の開発

>OSS、Java、DB、車が好き

Page 3: 20120913 nosql@hikarie(okuyama fuse)

1.NOSQLでファイルシステム?

ファイルシステムまわりを整理

2.NOSQLのファイルシステムの紹介

仕組みから、性能評価まで

3.まとめ

今日のお話し

Page 4: 20120913 nosql@hikarie(okuyama fuse)

NOSQLでファイルシステム? ・そもそもファイルシステムとは?

・内臓のHDDやSSD、外付けディスク、ネットワーク上の

ストレージ(NFS等)などの記憶デバイスを等価的に扱う仕組み。

色々あります。

Wikipediaより

Page 5: 20120913 nosql@hikarie(okuyama fuse)

NOSQLでファイルシステム? ・ファイルシステムが利用しているハードは?

・HDD 最も主流な記憶装置。

内臓する円盤に磁気を散布してそこにデータを記憶。

それを磁気ヘッドと言われる目のようなもので読み込む。

・SSD 徐々に浸透してきている記憶装置

HDDの様に円盤やヘッドなどの稼働部を持たず、

フラッシュメモリにデータを記憶。

・ioDrive 最近特に注目度の高い超高速デバイス。

NANDフラッシュメモリを記憶部に持ち、接続方式を

PCIeとすることでSSDを超える速度を発揮する。

Page 6: 20120913 nosql@hikarie(okuyama fuse)

NOSQLでファイルシステム? ・どのようにデータを格納しているか?

・ではアプリケーションから書き出されたデータは

どのように格納されているか?

Page 7: 20120913 nosql@hikarie(okuyama fuse)

NOSQLでファイルシステム? ・どのようにデータを保存しているか?

・すごくおおざっぱに表現すると巨大な配列として

保存されている。

全てバイトデータとして扱い、先頭からあらかじめ決められた

サイズ分だけ塊として分割しつつ、配列のように保存していく。

このサイズは最近では4096byteが主流

Page 8: 20120913 nosql@hikarie(okuyama fuse)

NOSQLでファイルシステム? ・どのようにデータを取り出すか?

・先ほどの配列に対して位置を指定して取り出す。

ここのデータを取り出す

例えば先ほどのファイルの1バイトから2048バイトを取り出す場合

この2つを取り出す

5000バイトから12000バイトを取り出す場合は?

Page 9: 20120913 nosql@hikarie(okuyama fuse)

NOSQLでファイルシステム? ・よくHDDが遅いといわれる原因は?

このように円盤上にデータが

保存されている。

連続してデータを取り出す場合は、

先頭から順にデータを取り出せば

よいので、高速に取り出せる。

ではこのように離れた場所のデータを

読み込みたい場合はどうするか?

円盤とヘッドが動いてデータの場所まで

移動しないといけない。

この移動に時間がかかる

Page 10: 20120913 nosql@hikarie(okuyama fuse)

NOSQLでファイルシステム? ・SSDはなぜ速い?

SSDはHDDと違い円盤にデータを保存しない。

データを取り出す際に物理的な位置を意識した

移動などの時間をともなわず、データが保存さて

いる記憶素子上から即取り出せるため高速。

つまり1つのデータの塊に

アクセスするのが凄く速い

Page 11: 20120913 nosql@hikarie(okuyama fuse)

NOSQLファイルシステム

Page 12: 20120913 nosql@hikarie(okuyama fuse)

NOSQLの特性 ・NOSQL 特にKVSの特性は?

・KVSは1つのデータへのアクセスが速い。

Page 13: 20120913 nosql@hikarie(okuyama fuse)

NOSQLの特性 ・例えば分散KVSのokuyamaの性能 ・okuyamaは分散しスケールアウトが可能なKVS

ストレージにメモリ、圧縮メモリ、ディスクなどが選べる

okuyamaはメモリストレージを利用

メモリで合ってもWALログでデータは永続化される。

サーバ2台で

10万QPS

Page 14: 20120913 nosql@hikarie(okuyama fuse)

NOSQLの特性 ・NOSQL特にKVSの特性は?

・これって先ほどのSSDの良いところに似てませんか?

Page 15: 20120913 nosql@hikarie(okuyama fuse)

NOSQLの特性 ・KVSは1つのデータの取り出しが高速

・これって先ほどのSSDの良いところに似てませんか?

というわけで、okuyamaを記憶装置として利用できる

ファイルシステムを作ってみました

okuyamaFuse

Page 16: 20120913 nosql@hikarie(okuyama fuse)

アーキテクチャ ・FUSEを利用してデータ格納先をokuyamaへ

FUSEとはLinux系のファイルシステムを

ユーザプロセスで自由に作成できる仕組み。

okuyamaFs

データは全てokuyamaに

格納され、ファイルのメタ情報なども全て格納され

る。

Page 17: 20120913 nosql@hikarie(okuyama fuse)

動かしてみた結果 ・いくつかのパターンで検証を実施

利用環境

・テストサーバ(テストを流すサーバ)

7200rpmの500GBのHDDを搭載(SATA)

Core i5、メモリ4GBのデスクトップPC(ドスパラ製)

・okuyamaサーバ

テストサーバと同型機を2台利用して分散化

圧縮メモリストレージを利用

Page 18: 20120913 nosql@hikarie(okuyama fuse)

動かしてみた結果 ・連続書き込み、読み込み

・ddを利用

ddはブロックサイズを指定して読み出し、書き出しが

出来るソフトウェア。連続的なアクセスになる。

テスト方法:4.8GBのファイルを利用

HDD HDDにコピー

HDD okuyamaにコピー

ブロックサイズは1000000byte

Page 19: 20120913 nosql@hikarie(okuyama fuse)

動かしてみた結果

・連続書き込み、読み込み

・テスト結果

Write:4817158144 bytes (4.8 GB) copied, 84.9928 seconds, 56.7 MB/s

Read:4817158144 bytes (4.8 GB) copied, 36.766 seconds, 131 MB/s

HDD

Write:4817158144 bytes (4.8 GB) copied, 149.642 seconds, 32.2 MB/s

Read:4817262144 bytes (4.8 GB) copied, 191.958 seconds, 25.1 MB/s

okuyamaFuse

・HDDは秒間56MB書き出せて、131MB読み出せる

・okuyamaFuseは32MB書き出せて、25MB読み出せる

いきなり負けてる。。。 どうすんだよ。。。。。

Page 20: 20120913 nosql@hikarie(okuyama fuse)

動かしてみた結果 ・ランダム書き込み、読み込み

・fioを利用

fioはストレージベンチマーク用のソフトウェア。

ランダムなアクセスを発生させることが可能。

また、同時アクセス数を変更することも可能。

テスト方法:4.8GBのファイルを利用

ブロックサイズは16Kbyte

同時アクセス数は20

Page 21: 20120913 nosql@hikarie(okuyama fuse)

動かしてみた結果 ・ランダム書き込み、読み込み

・テスト結果

Write:io=1232.0KB, bw=36151 B/s, iops=2 , runt= 34897msec

Read:io=58128KB, bw=1928.5KB/s, iops=120 , runt= 30142msec

HDD

Write:io=176832KB, bw=5886.1KB/s, iops=367 , runt= 30038msec

Read:io=1342.7MB, bw=45823KB/s, iops=2863 , runt= 30004msec

okuyamaFuse

・HDDは秒間36KB書き出せて、1.9MB読み出せる

・okuyamaFuseは5.8MB書き出せて、45MB読み出せる

Page 22: 20120913 nosql@hikarie(okuyama fuse)

動かしてみた結果 ・MySQLでのベンチ

・InnoDBのデータファイルを配置し、tpccにてベンチ

tpccとは?

TPC-Cとは卸売業における注文・支払いなどの処理を擬似的に再現した業務モデルで、TPCという業界団体によって策定されたものです。9種類のテーブルに対する5種類のトランザクションがミックスされており、そのうち注文処理のスループットを測定結果として利用します。

※sh2さんの「SH2の日記」より http://d.hatena.ne.jp/sh2/20090212

このtpccに準拠したベンチマークツールが

MySQL用に存在する。

これがtpcc-mysql https://code.launchpad.net/~percona-dev/perconatools/tpcc-mysql

Page 23: 20120913 nosql@hikarie(okuyama fuse)

動かしてみた結果 ・MySQLでのベンチ

・tpcc-mysql

・warehouseというベンチ用のデータ全体の大きさ ※warehouse=10のようなイメージ。1でデータサイズ90MB程度

・同時アクセス数

この2つを決めてテストを行う。

あらかじめwarehouseでデータの大きさを固定して、

同時アクセス数を変化させて、HDDと性能比較

Page 24: 20120913 nosql@hikarie(okuyama fuse)

動かしてみた結果 ・MySQLでのベンチ (warehouse=50 InnoDBファイルサイズ:4.8GB)

同時接続数

性能

スコア

Page 25: 20120913 nosql@hikarie(okuyama fuse)

まとめ ・KVSをファイルシステムにしてみた結果

・シーケンシャルな書き込み、読み込みはHDD

・ランダムな書き込み、読み込みはKVS

・ランダムなアクセスが多いMySQLなどのRDBMSでは

性能が向上する可能性がある。

・色々とokuyama側のストレージを変えると面白そう。

SSDやioDriveなど

・取り合えず次のokuyamaに含めてリリースします。

Page 26: 20120913 nosql@hikarie(okuyama fuse)

最後に

・Information

Web

http://okuyama-project.com/

Development

http://sourceforge.jp/projects/okuyama/

Facebook

http://www.facebook.com/okuyama.jp

Page 27: 20120913 nosql@hikarie(okuyama fuse)

Thank you!