20121205 nosql(okuyama fs)セミナー資料
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

20121205 nosql(okuyama fs)セミナー資料

on

  • 1,066 views

 

Statistics

Views

Total Views
1,066
Views on SlideShare
1,066
Embed Views
0

Actions

Likes
3
Downloads
15
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

20121205 nosql(okuyama fs)セミナー資料 Presentation Transcript

  • 1. okuyamaで実現したこと、 これからしたいこと Kobe Digital Labo, Inc. 岩瀬 高博 Twitter: @okuyamaoo Mail: iwase@kdl.co.jp http://okuyama-project.com/
  • 2. 自己紹介・岩瀬 高博(@okuyamaoo) > (株) 神戸デジタル・ラボ所属 業務及び活動 >大規模e-コマースサイトのチューニング、運用 >分散処理、データベースの研究及び適応 >(独)情報通信研究機構 特別研究員 研究領域:大規模Webアーカイブ >分散KVS okuyama、CEP Setsuna の開発 >OSS、Java、DB、車が好き
  • 3. 今日のお話し1.okuyamaとは? 簡単にokuyamaをご紹介2.okuyamaで実現したこと これまでの導入事例をご紹介3.これからしたいこと 現在取り組んでいる次の何かをご紹介
  • 4. okuyamaとは?
  • 5. okuyamaとは?
  • 6. okuyamaとは?・okuyamaはJavaで実装されたNOSQLの一種
  • 7. okuyamaとは?・どのような機能をもっているか?
  • 8. okuyamaとは?・どのような機能をもっているか?分散KVS アクセス・OSS ・独自プロトコル(Ascii)・完全冗長化(SPOFなし) Java、PHP、Ruby用が存在・無停止でのスケールアウト ・memcached互換・100台以上のサーバ規模での ・CAS、加減算、Multi系も対応 稼働実績 ・バックアップ等のクライアントも有り ・Hadoop連携ストレージ特性 データ構造・非永続型 or 永続型(WALログ方式)・メモリ or ディスク or メモリ+ディスク ・Key-Value構造 特性別ストレージ ・Tagの付与・ストレージ間の互換性 ・有効期限付きデータ・仮想メモリ機能 ・全文検索用Index・独自圧縮機能・パーティション機能
  • 9. 性能(80台のサーバでのテスト)登録処理(情報通信研究機構での実験結果) 開始24時間 220億件に到達 開始2時間30分 50億件に到達
  • 10. okuyamaで実現したこと?
  • 11. okuyamaで実現したこと・どのような実績があるか
  • 12. okuyamaで実現したこと・どのような実績があるか 代表的な4つをご紹介
  • 13. okuyamaで実現したこと・どのような実績があるか
  • 14. okuyamaで実現したこと・株式会社リンク様 大量のトラフィックを生み出すソーシャル アプリに対応するために、ハイエンド サーバやioDrive搭載サーバなどを パッケージングしたサービス okuyamaの高速性と、ストレージの特性変更の 機能を使い用途別のストレージサービスを構築 利用したokuyamaの機能 ・冗長化機能 ・共有キャッシュサーバ ・動的ノード追加機能 memcached互換APIを備えたメモリ ・memcahced互換API キャッシュサーバを構築し、エンドユーザは ・永続化型メモリストレージ メンテナンスフリーで利用可能 ・半ディスクストレージ ・画像管理サーバ ・パーティション機能 RestfulAPIで操作可能なドキュメントの管理、配信が 可能なオートスケール型ストレージを構築
  • 15. okuyamaで実現したこと・どのような実績があるか
  • 16. okuyamaで実現したこと・日本ユニシス株式会社様 大規模化するECサイトや、人気の高い フリーワード検索 カテゴリ検索 キャンペーンサイトなどでは、高速な検索と 範囲検索 精度の高い結果がもとめられている。 カスタマイズソート検索機能に特化した検索エンジンを 利用したokuyamaの機能okuyamaの全文検索機能を使い構築 ・冗長化機能・アプリケーションとのI/FにはRestfulAPIを採用 ・動的ノード追加機能・RDBMSからデータコンバータにて自動的に ・Tag機能 インデックスを作成 ・永続化型メモリストレージ ・圧縮型メモリストレージ・検索内容、取得データ、ソート対象などはXMLにて ・パーティション機能 カスタマイズ可能 ・全部検索機能
  • 17. okuyamaで実現したこと・どのような実績があるか
  • 18. okuyamaで実現したこと・株式会社World様 急成長を続けるオンラインストア 頻繁にシステム改修を行うことで顧客数の 増加に成功。今後もスピード感ある改修と 効率化を続ける商品データや在庫データといったマスターデータを 利用したokuyamaの機能管理するデータベースを構築 ・冗長化機能 ・API層を設けることで複雑な ・動的ノード追加機能 問い合わせに対応(API層は別途構築) ・Tag機能 ・永続化型メモリストレージ ・RDBMSと併用することでそれぞれの ・半ディスクストレージ 良い部分を最大限に利用 ・パーティション機能 ・他システムとの連携にも対応 ・全部検索機能
  • 19. okuyamaで実現したこと・どのような実績があるか
  • 20. okuyamaで実現したこと・ (独)情報通信研究機構 okuyamaを利用した大規模Webアーカイブ 技術を共同研究 具体的にはWebクローラ用のデータベース としての有効利用を研究okuyamaのスケールアウト性能や、障害時の挙動の検証などを100台のクラスタ環境で実施 ・80台のサーバ上でokuyamaをオンメモリストレージで 稼働し性能を測定 ・障害復旧時の性能測定を行いより高速なリカバリ 処理を研究 ・研究成果は学会発表や論文投稿にて公開
  • 21. これから実現したいこと
  • 22. これから実現したいこと
  • 23. これから実現したいこと・okuyamaFuseとは? FUSEを利用して実装したファイシステム ※FUSEとはLinux系のファイルシステムをユーザプロセスで自由に作成できる仕組み。 okuyamaFs データは全てokuyamaに 格納されファイルのメタ情報 なども全て格納される
  • 24. これから実現したいこと・なぜ作ろうと思ったか?
  • 25. これから実現したいこと・なぜ作ろうと思ったか? ご説明する前にまず標準的なファイルシステムのお話しを
  • 26. これから実現したいこと・そもそもファイルシステムとは?・内臓のHDDやSSD、外付けディスク、ネットワーク上の ストレージ(NFS等)などの記憶デバイスを等価的に扱う仕組み。 色々あります。 Wikipediaより
  • 27. そもそもファイルシステムとは?・ファイルシステムが利用しているハードは? ・HDD 最も主流な記憶装置。 内臓する円盤に磁気を散布してそこにデータを記憶。 それを磁気ヘッドと言われる目のようなもので読み込む。 ・SSD 徐々に浸透してきている記憶装置 HDDの様に円盤やヘッドなどの稼働部を持たず、 フラッシュメモリにデータを記憶。 ・ioDrive 最近特に注目度の高い超高速デバイス。 NANDフラッシュメモリを記憶部に持ち、接続方式を PCIeとすることでSSDを超える速度を発揮する。
  • 28. そもそもファイルシステムとは?・どのようにデータを格納しているか?・ではアプリケーションから書き出されたデータは どのように格納されているか?
  • 29. そもそもファイルシステムとは?・どのようにデータを保存しているか?・すごくおおざっぱに表現すると巨大な配列として 保存されている。 全てバイトデータとして扱い、先頭からあらかじめ決められた サイズ分だけ塊として分割しつつ、配列のように保存していく。 このサイズは最近では4096byteが主流
  • 30. そもそもファイルシステムとは?・どのようにデータを取り出すか?・先ほどの配列に対して位置を指定して取り出す。 例えば先ほどのファイルの1バイトから2048バイトを取り出す場 ここのデータを取り出す 5000バイトから12000バイトを取り出す場合は? この2つを取り出す
  • 31. そもそもファイルシステムとは?・よくHDDが遅いといわれる原因は? このように円盤上にデータが 保存されている。 連続してデータを取り出す場合は、 先頭から順にデータを取り出せば よいので、高速に取り出せる。 ではこのように離れた場所のデータを 読み込みたい場合はどうするか? 円盤とヘッドが動いてデータの場所まで 移動しないといけない。 この移動に時間がかかる
  • 32. そもそもファイルシステムとは?・SSDはなぜ速い? SSDはHDDと違い円盤にデータを保存しない。 データを取り出す際に物理的な位置を意識した 移動などの時間をともなわず、データが保存さて いる記憶素子上から即取り出せるため高速。 つまり1つのデータの塊に アクセスするのが凄く速い
  • 33. okuyamaをファイルシステムに
  • 34. okuyamaの特性・okuyamaの特性は?・KVSのため1つのデータへのアクセスが速い。
  • 35. okuyamaの特性・okuyamaの性能は先ほどの通り・スケールアウトも可能でありストレージにメモリ、a圧縮メモリ、ディスクなどが選べる サーバ2台で 10万QPS ランダムな同時アクセスでも高い性能を出せる
  • 36. okuyamaの特性・okuyamaは1つのデータの取り出しが高速・これって先ほどのSSDの良いところに似てませんか?
  • 37. okuyamaの特性・okuyamaは1つのデータの取り出しが高速・これって先ほどのSSDの良いところに似てませんか? というわけで、okuyamaを記憶装置として利用できる ファイルシステムを作ってみました okuyamaFuse
  • 38. 動かしてみた結果・いくつかのパターンで検証を実施利用環境・テストサーバ(テストを流すサーバ) 7200rpmの500GBのHDDを搭載(SATA) Core i5、メモリ4GBのデスクトップPC(ドスパラ製)・okuyamaサーバ テストサーバと同型機を2台利用して分散化 圧縮メモリストレージを利用
  • 39. 動かしてみた結果・連続書き込み、読み込み・ddを利用 ddはブロックサイズを指定して読み出し、書き出しが 出来るソフトウェア。連続的なアクセスになる。テスト方法:4.8GBのファイルを利用 HDD HDDにコピー HDD okuyamaにコピー ブロックサイズは1000000byte
  • 40. 動かしてみた結果・連続書き込み、読み込み・テスト結果 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読み出せる お、おそいだと。。。
  • 41. 動かしてみた結果・ランダム書き込み、読み込み・fioを利用 fioはストレージベンチマーク用のソフトウェア。 ランダムなアクセスを発生させることが可能。 また、同時アクセス数を変更することも可能。テスト方法:4.8GBのファイルを利用 ブロックサイズは16Kbyte 同時アクセス数は20
  • 42. 動かしてみた結果・ランダム書き込み、読み込み・テスト結果 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読み出せる
  • 43. 動かしてみた結果・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
  • 44. 動かしてみた結果・MySQLでのベンチ・tpcc-mysql ・warehouseというベンチ用のデータ全体の大きさ ※warehouse=10のようなイメージ。1でデータサイズ90MB程度 ・同時アクセス数 この2つを決めてテストを行う。 あらかじめwarehouseでデータの大きさを固定して、 同時アクセス数を変化させて、HDDと性能比較
  • 45. 動かしてみた結果・MySQLでのベンチ(warehouse=50 InnoDBファイルサイズ:4.8GB)性能スコア 同時接続数
  • 46. まとめ・okuyamaをファイルシステムにしてみた結果・シーケンシャルな書き込み、読み込みはHDD・ランダムな書き込み、読み込みはokuyama・ランダムなアクセスが多いMySQLなどのRDBMSでは 性能が向上する可能性がある・色々とokuyama側のストレージを変えると用途が変わる HDD、SSD、ioDrive、大規模メモリなど・じつは既に別の方も検証してます・okuyamaのVersion-0.9.4に入ってます
  • 47. 最後に・Information Web http://okuyama-project.com/ Development http://sourceforge.jp/projects/okuyama/ Facebook http://www.facebook.com/okuyama.jp
  • 48. Thank you!