Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

20120913 nosql@hikarie(okuyama fuse)

2,637 views

Published on

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

Published in: Technology
  • Be the first to comment

20120913 nosql@hikarie(okuyama fuse)

  1. 1. NOSQLで構築した分散MemoryFS上でMySQLを動かすとどうなるか? Kobe Digital Labo, Inc. 岩瀬 高博 Twitter: @okuyamaoo Mail: iwase@kdl.co.jp https://github.com/okuyamaoo
  2. 2. 自己紹介・岩瀬 高博(@okuyamaoo) > 株式会社 神戸デジタル・ラボ所属 業務及び活動 >大規模e-コマースサイトのチューニング、運用 >分散処理、データベースの研究及び適応 >(独)情報通信研究機構 特別研究員 研究領域:大規模Webアーカイブ >分散KVS okuyama、CEP Setsuna の開発 >OSS、Java、DB、車が好き
  3. 3. 今日のお話し1.NOSQLでファイルシステム? ファイルシステムまわりを整理2.NOSQLのファイルシステムの紹介 仕組みから、性能評価まで3.まとめ
  4. 4. NOSQLでファイルシステム?・そもそもファイルシステムとは?・内臓のHDDやSSD、外付けディスク、ネットワーク上の ストレージ(NFS等)などの記憶デバイスを等価的に扱う仕組み。 色々あります。 Wikipediaより
  5. 5. NOSQLでファイルシステム?・ファイルシステムが利用しているハードは? ・HDD 最も主流な記憶装置。 内臓する円盤に磁気を散布してそこにデータを記憶。 それを磁気ヘッドと言われる目のようなもので読み込む。 ・SSD 徐々に浸透してきている記憶装置 HDDの様に円盤やヘッドなどの稼働部を持たず、 フラッシュメモリにデータを記憶。 ・ioDrive 最近特に注目度の高い超高速デバイス。 NANDフラッシュメモリを記憶部に持ち、接続方式を PCIeとすることでSSDを超える速度を発揮する。
  6. 6. NOSQLでファイルシステム?・どのようにデータを格納しているか?・ではアプリケーションから書き出されたデータは どのように格納されているか?
  7. 7. NOSQLでファイルシステム?・どのようにデータを保存しているか?・すごくおおざっぱに表現すると巨大な配列として 保存されている。 全てバイトデータとして扱い、先頭からあらかじめ決められた サイズ分だけ塊として分割しつつ、配列のように保存していく。 このサイズは最近では4096byteが主流
  8. 8. NOSQLでファイルシステム?・どのようにデータを取り出すか?・先ほどの配列に対して位置を指定して取り出す。 例えば先ほどのファイルの1バイトから2048バイトを取り出す場 合 ここのデータを取り出す 5000バイトから12000バイトを取り出す場合は? この2つを取り出す
  9. 9. NOSQLでファイルシステム?・よくHDDが遅いといわれる原因は? このように円盤上にデータが 保存されている。 連続してデータを取り出す場合は、 先頭から順にデータを取り出せば よいので、高速に取り出せる。 ではこのように離れた場所のデータを 読み込みたい場合はどうするか? 円盤とヘッドが動いてデータの場所まで 移動しないといけない。 この移動に時間がかかる
  10. 10. NOSQLでファイルシステム?・SSDはなぜ速い? SSDはHDDと違い円盤にデータを保存しない。 データを取り出す際に物理的な位置を意識した 移動などの時間をともなわず、データが保存さて いる記憶素子上から即取り出せるため高速。 つまり1つのデータの塊に アクセスするのが凄く速い
  11. 11. NOSQLファイルシステム
  12. 12. NOSQLの特性・NOSQL 特にKVSの特性は?・KVSは1つのデータへのアクセスが速い。
  13. 13. NOSQLの特性・例えば分散KVSのokuyamaの性能・okuyamaは分散しスケールアウトが可能なKVS ストレージにメモリ、圧縮メモリ、ディスクなどが選べる サーバ2台で 10万QPS okuyamaはメモリストレージを利用 メモリで合ってもWALログでデータは永続化される。
  14. 14. NOSQLの特性・NOSQL特にKVSの特性は?・これって先ほどのSSDの良いところに似てませんか?
  15. 15. NOSQLの特性・KVSは1つのデータの取り出しが高速・これって先ほどのSSDの良いところに似てませんか? というわけで、okuyamaを記憶装置として利用できる ファイルシステムを作ってみました okuyamaFuse
  16. 16. アーキテクチャ・FUSEを利用してデータ格納先をokuyamaへ FUSEとはLinux系のファイルシステムを ユーザプロセスで自由に作成できる仕組み。 okuyamaFs データは全てokuyamaに 格納され、ファイルのメタ 情報なども全て格納され る。
  17. 17. 動かしてみた結果・いくつかのパターンで検証を実施利用環境・テストサーバ(テストを流すサーバ) 7200rpmの500GBのHDDを搭載(SATA) Core i5、メモリ4GBのデスクトップPC(ドスパラ製)・okuyamaサーバ テストサーバと同型機を2台利用して分散化 圧縮メモリストレージを利用
  18. 18. 動かしてみた結果・連続書き込み、読み込み・ddを利用 ddはブロックサイズを指定して読み出し、書き出しが 出来るソフトウェア。連続的なアクセスになる。テスト方法:4.8GBのファイルを利用 HDD HDDにコピー HDD okuyamaにコピー ブロックサイズは1000000byte
  19. 19. 動かしてみた結果・連続書き込み、読み込み・テスト結果 HDD 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 okuyamaFuse 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 ・HDDは秒間56MB書き出せて、131MB読み出せる ・okuyamaFuseは32MB書き出せて、25MB読み出せる いきなり負けてる。。。 どうすんだよ。。。。。
  20. 20. 動かしてみた結果・ランダム書き込み、読み込み・fioを利用 fioはストレージベンチマーク用のソフトウェア。 ランダムなアクセスを発生させることが可能。 また、同時アクセス数を変更することも可能。テスト方法:4.8GBのファイルを利用 ブロックサイズは16Kbyte 同時アクセス数は20
  21. 21. 動かしてみた結果・ランダム書き込み、読み込み・テスト結果 HDD Write:io=1232.0KB, bw=36151 B/s, iops=2 , runt= 34897msec Read:io=58128KB, bw=1928.5KB/s, iops=120 , runt= 30142msec okuyamaFuse Write:io=176832KB, bw=5886.1KB/s, iops=367 , runt= 30038msec Read:io=1342.7MB, bw=45823KB/s, iops=2863 , runt= 30004msec ・HDDは秒間36KB書き出せて、1.9MB読み出せる ・okuyamaFuseは5.8MB書き出せて、45MB読み出せる
  22. 22. 動かしてみた結果・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
  23. 23. 動かしてみた結果・MySQLでのベンチ・tpcc-mysql ・warehouseというベンチ用のデータ全体の大きさ ※warehouse=10のようなイメージ。1でデータサイズ90MB程度 ・同時アクセス数 この2つを決めてテストを行う。 あらかじめwarehouseでデータの大きさを固定して、 同時アクセス数を変化させて、HDDと性能比較
  24. 24. 動かしてみた結果・MySQLでのベンチ(warehouse=50 InnoDBファイルサイズ:4.8GB)性能スコア 同時接続数
  25. 25. まとめ・KVSをファイルシステムにしてみた結果・シーケンシャルな書き込み、読み込みはHDD・ランダムな書き込み、読み込みはKVS・ランダムなアクセスが多いMySQLなどのRDBMSでは 性能が向上する可能性がある。・色々とokuyama側のストレージを変えると面白そう。 SSDやioDriveなど・取り合えず次のokuyamaに含めてリリースします。
  26. 26. 最後に・Information Web http://okuyama-project.com/ Development http://sourceforge.jp/projects/okuyama/ Facebook http://www.facebook.com/okuyama.jp
  27. 27. Thank you!

×