Download as PDF, PPTX
![[db tech showcase Tokyo 2015] A33:Amazon Aurora Deep Dive by アマゾン データ サービス ジャ...](https://cdn.slidesharecdn.com/ss_thumbnails/dbts-tokyo-2015a34amazon-auroraamazondataservicejapan-150623010528-lva1-app6892-thumbnail.jpg?width=640&height=640&fit=bounds)
![[D25] 分散Key-Valueストア「okuyama」&「Riak」の同時書込み性能検証 by Yusuke Kuramata](https://cdn.slidesharecdn.com/ss_thumbnails/d25-140623203309-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
20121205 nosql(okuyama fs)セミナー資料
- 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.
- 4.
- 5.
- 6.
- 7.
- 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.
- 11.
- 12.
- 13.
- 14. okuyamaで実現したこと ・株式会社リンク様 大量のトラフィックを生み出すソーシャル アプリに対応するために、ハイエンド サーバやioDrive搭載サーバなどを パッケージングしたサービス okuyamaの高速性と、ストレージの特性変更の 機能を使い用途別のストレージサービスを構築 利用したokuyamaの機能 ・冗長化機能 ・共有キャッシュサーバ ・動的ノード追加機能 memcached互換APIを備えたメモリ ・memcahced互換ＡＰＩ キャッシュサーバを構築し、エンドユーザは ・永続化型メモリストレージ メンテナンスフリーで利用可能 ・半ディスクストレージ ・画像管理サーバ ・パーティション機能 RestfulAPIで操作可能なドキュメントの管理、配信が 可能なオートスケール型ストレージを構築
- 15.
- 16. okuyamaで実現したこと ・日本ユニシス株式会社様 大規模化するＥＣサイトや、人気の高い フリーワード検索 カテゴリ検索 キャンペーンサイトなどでは、高速な検索と 範囲検索 精度の高い結果がもとめられている。 カスタマイズソート 検索機能に特化した検索エンジンを 利用したokuyamaの機能 okuyamaの全文検索機能を使い構築 ・冗長化機能 ・アプリケーションとのI/FにはRestfulAPIを採用 ・動的ノード追加機能 ・RDBMSからデータコンバータにて自動的に ・Tag機能 インデックスを作成 ・永続化型メモリストレージ ・圧縮型メモリストレージ ・検索内容、取得データ、ソート対象などはXMLにて ・パーティション機能 カスタマイズ可能 ・全部検索機能
- 17.
- 18. okuyamaで実現したこと ・株式会社World様 急成長を続けるオンラインストア 頻繁にシステム改修を行うことで顧客数の 増加に成功。今後もスピード感ある改修と 効率化を続ける 商品データや在庫データといったマスターデータを 利用したokuyamaの機能 管理するデータベースを構築 ・冗長化機能 ・ＡＰＩ層を設けることで複雑な ・動的ノード追加機能 問い合わせに対応(API層は別途構築) ・Tag機能 ・永続化型メモリストレージ ・RDBMSと併用することでそれぞれの ・半ディスクストレージ 良い部分を最大限に利用 ・パーティション機能 ・他システムとの連携にも対応 ・全部検索機能
- 19.
- 20. okuyamaで実現したこと ・ (独)情報通信研究機構 okuyamaを利用した大規模Webアーカイブ 技術を共同研究 具体的にはWebクローラ用のデータベース としての有効利用を研究 okuyamaのスケールアウト性能や、障害時の 挙動の検証などを100台のクラスタ環境で実施 ・80台のサーバ上でokuyamaをオンメモリストレージで 稼働し性能を測定 ・障害復旧時の性能測定を行いより高速なリカバリ 処理を研究 ・研究成果は学会発表や論文投稿にて公開
- 21.
- 22.
- 23. これから実現したいこと ・okuyamaFuseとは？ FUSEを利用して実装したファイシステム ※FUSEとはLinux系のファイルシステムをユーザプロセスで自由に作成できる仕組み。 okuyamaFs データは全てokuyamaに 格納されファイルのメタ情報 なども全て格納される
- 24.
- 25.
- 26.
- 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.
- 34.
- 35. okuyamaの特性 ・okuyamaの性能は先ほどの通り ・スケールアウトも可能でありストレージにメモリ、 a圧縮メモリ、ディスクなどが選べる サーバ2台で 10万QPS ランダムな同時アクセスでも高い性能を出せる
- 36.
- 37. okuyamaの特性 ・okuyamaは1つのデータの取り出しが高速 ・これって先ほどのSSDの良いところに似てませんか？ というわけで、okuyamaを記憶装置として利用できる ファイルシステムを作ってみました okuyamaFuse
- 38. 動かしてみた結果 ・いくつかのパターンで検証を実施 利用環境 ・テストサーバ(テストを流すサーバ) 7200rpmの500GBのHDDを搭載（SATA) Corei5、メモリ4GBのデスクトップPC(ドスパラ製) ・okuyamaサーバ テストサーバと同型機を2台利用して分散化 圧縮メモリストレージを利用
- 39. 動かしてみた結果 ・連続書き込み、読み込み ・ddを利用 ddはブロックサイズを指定して読み出し、書き出しが 出来るソフトウェア。連続的なアクセスになる。 テスト方法:4.8GBのファイルを利用 HDD HDDにコピー HDD okuyamaにコピー ブロックサイズは1000000byte
- 40. 動かしてみた結果 ・連続書き込み、読み込み ・テスト結果 HDD Write：4817158144bytes (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.
- 46.
- 47. 最後に ・Information Weｂ http://okuyama-project.com/ Development http://sourceforge.jp/projects/okuyama/ Facebook http://www.facebook.com/okuyama.jp
- 48.