[D25] 分散Key-Valueストア「okuyama」&「Riak」の同時書込み性能検証 by Yusuke Kuramata

1,616 views

Published on

Published in: Technology

[D25] 分散Key-Valueストア「okuyama」&「Riak」の同時書込み性能検証 by Yusuke Kuramata

  1. 1. © Hitachi Solutions, Ltd. 2014. All rights reserved. 分散Key-Valueストア 「okuyama」 & 「Riak」 書込み性能検証 株式会社 日立ソリューションズ オープンソース技術開発センタ 2014/6/19 倉又 裕輔
  2. 2. © Hitachi Solutions, Ltd. 2014. All rights reserved. 自己紹介 1  名前: 倉又 裕輔 (くらまた ゆうすけ)  所属: (株)日立ソリューションズ オープンソース技術開発センタ  担当業務: NoSQL技術の調査、検証 ・エンタープライズ利用に向けた調査と検証 ・技術情報の社内外への発信
  3. 3. © Hitachi Solutions, Ltd. 2014. All rights reserved. 1. 検証の背景 2. ベンチマーク方法 3. ベンチマーク結果 Contents 4. ベンチマークのまとめ
  4. 4. © Hitachi Solutions, Ltd. 2014. All rights reserved. 1. 検証の背景 なぜ「okuyama」と「Riak」を検証したのか NoSQL、Key-Value ストアに着目した背景
  5. 5. © Hitachi Solutions, Ltd. 2014. All rights reserved. 1.1 IT技術動向 4 近年のビッグデータへの期待から、IoTへの関心が高まっている 2017年までに20%以上の企業が、 従来の情報機器とは異なるセンサや組み込み機器などを 利用し、ビジネスを取り巻く環境をデジタル化する。 多様な情報を収集、分析することで 製品やサービスをより効果的に提供するために、 モノのインターネットに関する新たな取り組みを行う。 ☆引用 : 2014年4月17日 ガートナー ジャパン株式会社 プレスリリース 【 http://www.gartner.co.jp/press/html/pr20140417-01.html 】
  6. 6. © Hitachi Solutions, Ltd. 2014. All rights reserved. 1.2. IoT(センサー)に適するデータストア要件 5 センサーデータの特徴 1) 非構造データ 2) 記録回数/時間: 多 3) センサー数: 大量 4) データ送信頻度: 高 データストアの要件 A) 非構造データの保存 B) 大量データの保存 C) 高速な書込み性能
  7. 7. © Hitachi Solutions, Ltd. 2014. All rights reserved. しかし、性能に関する情報が不足している 特に書込み性能に注目し 知見を増やすために検証を実施した 1.3. NoSQL適合の課題 6 リレーショナルデータベース(RDB)以外のデータストアの総称 SQLを使用せずにデータを操作する NoSQL(Not only SQL) ★苦手 ・トランザクション処理 ・複雑な検索、集計処理 ☆得意 ・非構造データの保存(スキーマレス) ・スケールアウト(大量データの保存) ・高速な書込み、参照処理 データストアの要件に適合
  8. 8. © Hitachi Solutions, Ltd. 2014. All rights reserved. 1.4. 検証対象NoSQLの検討(1/2) 7 NoSQLの分類(データモデル) ドキュメント指向 ・MongoDB ・CouchDB ・Couchbase Server など Key-Value ストア (KVS) ・okuyama ・Riak ・memcached ・Redis など カラム指向 ・Cassandra ・Hbase ・Hypertable など Key Value Key Value データが シンプル KVSは小さい多数データの蓄積、高速なデータ読み書きが得意 センサーデータに適している
  9. 9. © Hitachi Solutions, Ltd. 2014. All rights reserved. KVSの分類 1.5. 検証対象NoSQLの検討(2/2) 永続化機能の有無 永続化機能なし(インメモリ) 永続化機能あり デ ー タ 分 散 機 能 の 実 装 ク ラ イ ア ン ト 側 K V S 側 8 okuyama Riak memcached Redis
  10. 10. © Hitachi Solutions, Ltd. 2014. All rights reserved. KVSの分類 1.5. 検証対象NoSQLの検討(2/2) 永続化機能の有無 永続化機能なし(インメモリ) 永続化機能あり デ ー タ 分 散 機 能 の 実 装 ク ラ イ ア ン ト 側 K V S 側 9 okuyama Riak memcached Redis ・ KVSのみで データ蓄積可能 ・ データ分散や スケールアウトが 容易 「okuyama」と「Riak」を検証対象として選択
  11. 11. © Hitachi Solutions, Ltd. 2014. All rights reserved. 1.6. okuyama の特徴 10 okuyama 開発元 株式会社 神戸デジタル・ラボ ライセンス GPL v3 (商用ライセンス・サポートあり) 開発言語 Java 分散アーキテクチャ マスタ-スレーブ型 ユースケース ECサイト、検索エンジン、キャッシュサーバ、ログ管理、など 開発元 : 神戸デジタル・ラボ ( http://okuyama-project.com/ja/index.html ) スレーブ マスタ データ操作 データ振分け データ保存 クライ アント ・マスタ-スレーブ型 ・データの永続化が可能 ・冗長化により 単一障害点の無い クラスタを構築可能 ・無停止でスケールアウト可能 ・データ保存先を選択可能 (ディスク・メモリ・併用) スレーブ
  12. 12. © Hitachi Solutions, Ltd. 2014. All rights reserved. 1.7. Riak の特徴 11 Riak 開発元 Basho Technologies, Inc. ライセンス Apache License, Version 2.0 (商用ライセンス・サポートあり) 開発言語 Erlang/C 分散アーキテクチャ P2P型 ユースケース ECサイト、キャッシュサーバ、オブジェクトストレージ、など 開発元 : Basho Technologies ( http://basho.co.jp/riak/ ) ・P2P型 ・データの永続化が可能 ・単一障害点なし ・無停止でスケールアウト可能 ・データ保存先を選択可能 (ディスク・メモリ・併用) データ操作 データ振分け・保存 クライ アント ノード ノード ノード
  13. 13. © Hitachi Solutions, Ltd. 2014. All rights reserved. 2. ベンチマーク方法 検証環境、ベンチマークツール ベンチマークの内容 検証の目的、観点
  14. 14. © Hitachi Solutions, Ltd. 2014. All rights reserved. 2.1. 検証の目的 13 同時書込み性能が重要 実際どのくらい速いのか?ベンチマーク実施 KVS 多数のセンサーが 高頻度に大量件数のデータを同時送信 センサー
  15. 15. © Hitachi Solutions, Ltd. 2014. All rights reserved. 2.2. 検証の観点 14 スループット (書込み数/秒)と レイテンシ (書込み時間)を計測 クライ アント KVS 増加させてベンチマーク Key Value Insert ☆観点:同時書込み性能 センサー何台まで性能低下せず 同時書き込みできるか?
  16. 16. © Hitachi Solutions, Ltd. 2014. All rights reserved. 2.3. 検証パターン 15 「okuyama」と「Riak」の特性は構成によって異なる Disk Key Value Disk ValueKey パターン1 【ディスク保存】 パターン2 【メモリ・ディスク併用】 Key Value パターン3 【インメモリ】 KVS KVS KVS 大量データ保存が要件のため、パターン1と2を検証 データ保存容量大 小 書込み速度遅 速
  17. 17. © Hitachi Solutions, Ltd. 2014. All rights reserved. 2.4. 検証パターンごとの観点 16 各検証パターンごとの懸念点についても検証 Disk Key Value Disk ValueKey パターン1 【ディスク保存】 パターン2 【メモリ・ディスク併用】 KVS KVS メモリが無くなるまで書込み、 性能変化を検証 書込み速度が遅い? 大量データ保存による メモリ消費時の性能? スケールアウトによる 性能向上を検証
  18. 18. © Hitachi Solutions, Ltd. 2014. All rights reserved. okuyama v0.9.5 (1ノード/台) 2.5. 検証環境 17 1台 1~4台 マスタ スレーブ Riak v1.4.6 (1ノード/台) 1~4台 ノード クライ アント 1台 クライ アント 1台 CPU Intel(R) Core(TM) i5 CPU 520 メモリ 4GB HDD(SATA) 750GB, 5400RPM OS CentOS 6.5 64bit ※データの複製・レプリケーション無し
  19. 19. © Hitachi Solutions, Ltd. 2014. All rights reserved. 2.6. ベンチマークツール 18参考: https://github.com/brianfrankcooper/YCSB/wiki Yahoo! Cloud Serving Benchmark (YCSB) 開発元 Yahoo! Inc. ライセンス Apache License, Version 2.0 開発言語 Java 使用バージョン 0.1.4 他ベンチマークと比較できるよう、 一般に利用実績のあるベンチマークツールを使いたい NoSQL用ベンチマークツール 「Yahoo! Cloud Serving Benchmark (YCSB)」 を利用
  20. 20. © Hitachi Solutions, Ltd. 2014. All rights reserved. 2.7. YCSBの動き 19 START ①スレッド数(同時アクセス数)、 処理するデータ件数を指定し実行 ① ②スレッドごとにNoSQLへ接続 ② ③書込み処理開始 全件を処理するまで繰り返し 1件単位のスループットと レイテンシを計測 Key Value③ YCSB NoSQL ④④全件の処理を終えたら終了 スループット・レイテンシの 計測結果を集計し出力 END 書込むデータは、 KeyとValue共に 約25バイト okuyamaとRiak用の クライアントを作成(約80行)
  21. 21. © Hitachi Solutions, Ltd. 2014. All rights reserved. 3. ベンチマーク結果 メモリ・ディスク併用パターンの検証結果 okuyama Riak ディスク保存パターンの検証結果 okuyama Riak
  22. 22. © Hitachi Solutions, Ltd. 2014. All rights reserved. okuyama構成図 3.1. 検証:【ディスク保存】 - okuyama 21 同時書込み性能・スケールアウト性能 Disk Key Value 1ノード 1台 1~4 ノード マスタ スレーブ クライ アント スケールアウト性能 ノード数を増加 同時書込み性能 同時アクセス数を増加マスタ-スレーブ
  23. 23. © Hitachi Solutions, Ltd. 2014. All rights reserved. 3.1. 検証:【ディスク保存】 - okuyama 22 同時書込み性能・スケールアウト性能 ・okuyama - スループット 0 10 20 30 40 50 60 70 80 90 0 50 100 150 200 250 300 ス ル ー プ ッ ト [ops/sec] 同時アクセス数(スレッド数) 同一条件で大量件数書込み、 平均値をプロット 4ノード 性能が スケール 3ノード 2ノード 1ノード ピークを取り、その後はほぼ一定 約84ops/sec
  24. 24. © Hitachi Solutions, Ltd. 2014. All rights reserved. 3.1. 検証:【ディスク保存】 - okuyama 23 同時書込み性能・スケールアウト性能 ・okuyama - レイテンシ 0 2000 4000 6000 8000 10000 12000 0 50 100 150 200 250 300 レ イ テ ン シ [ms] 同時アクセス数(スレッド数) 4ノード 3ノード 2ノード 1ノード 性能が スケール アクセス増に比例し 性能低下
  25. 25. © Hitachi Solutions, Ltd. 2014. All rights reserved. Riak構成図 3.2. 検証:【ディスク保存】 - Riak 24 同時書込み性能・スケールアウト性能 1台 クライ アント Disk Key Value 1~4 ノード ノード スケールアウト性能 ノード数を増加 同時書込み性能 同時アクセス数を増加P2P
  26. 26. © Hitachi Solutions, Ltd. 2014. All rights reserved. 3.2. 検証:【ディスク保存】 - Riak 25 同時書込み性能・スケールアウト性能 ・Riak - スループット 0 50 100 150 200 250 0 50 100 150 200 250 300 350 400 ス ル ー プ ッ ト [ops/sec] 同時アクセス数(スレッド数) 4ノード 性能が スケール 3ノード 2ノード 1ノード ピークを取り、その後はほぼ一定 約220ops/sec
  27. 27. © Hitachi Solutions, Ltd. 2014. All rights reserved. 3.2. 検証:【ディスク保存】 - Riak 26 同時書込み性能・スケールアウト性能 ・Riak - レイテンシ 0 500 1000 1500 2000 2500 0 50 100 150 200 250 300 350 400 レ イ テ ン シ [ms] 同時アクセス数(スレッド数) 4ノード 3ノード 2ノード 性能が スケール 1ノード アクセス増に比例し 性能低下 他と違う 動き?
  28. 28. © Hitachi Solutions, Ltd. 2014. All rights reserved. 3.3. 検証:【ディスク保存】 - まとめ 27 同時書込み性能・スケールアウト性能 わかったこと 1) 同時アクセス特性 同時アクセス数が増加しても、急な性能低下はしない。 リソース使用状況から、ディスクI/Oがボトルネック。 2) スケールアウト特性 ノード追加に対して想定通り性能向上。 3) スループット 最大で約 100~200 ops/sec のオーダー (okuyama: 84ops/sec 、Riak: 220 ops/sec)
  29. 29. © Hitachi Solutions, Ltd. 2014. All rights reserved. okuyama構成図 3.4. 検証:【メモリ・ディスク併用】 - okuyama 28 同時書込み性能・メモリ消費時の性能 Disk Value 4ノード Key スレーブ 1ノード 1台 マスタ クライ アント 同時書込み性能 同時アクセス数を増加 メモリが無くなるまで 長時間書込み マスタ-スレーブ
  30. 30. © Hitachi Solutions, Ltd. 2014. All rights reserved. 3.4. 検証:【メモリ・ディスク併用】 - okuyama 29 同時書込み性能 ・okuyama - スループット 0 5000 10000 15000 20000 25000 30000 0 100 200 300 400 500 600 700 ス ル ー プ ッ ト ( ops/sec ) 処理時間(sec) 時間と共に性能変化 ⇒平均値ではなく 時間変化を計測 ピークを取り、その後急に性能低下 300同時アクセス 100同時アクセス 30同時アクセス 10同時アクセス 他と違う動き? マスタノードの負荷が高い
  31. 31. © Hitachi Solutions, Ltd. 2014. All rights reserved. 3.4. 検証:【メモリ・ディスク併用】 - okuyama 30 同時書込み性能 ・okuyama - レイテンシ 0.1 1 10 100 0 100 200 300 400 500 600 700 レ イ テ ン シ ( ms ) 処理時間(sec) 300同時アクセス 100同時アクセス 30同時アクセス 10同時アクセス アクセス増につれて性能低下
  32. 32. © Hitachi Solutions, Ltd. 2014. All rights reserved. 0 5000 10000 15000 20000 25000 0 2000 4000 6000 8000 10000 12000 ス ル ー プ ッ ト ( ops/sec ) 処理時間(sec) 3.4. 検証:【メモリ・ディスク併用】 - okuyama 31 メモリ消費時の性能 ・okuyama - スループット メモリ枯渇のため ディスク書込み 65~85ops/sec 急に性能低下 10,000~6,000ops/sec やや安定 周期的に性能低下? 100同時アクセス
  33. 33. © Hitachi Solutions, Ltd. 2014. All rights reserved. 3.4. 検証:【メモリ・ディスク併用】 - okuyama 32 メモリ消費時の性能 ・okuyama - レイテンシ 1 10 100 1000 10000 0 2000 4000 6000 8000 10000 12000 レ イ テ ン シ ( ms ) 処理時間(sec) 20ms 弱 ディスク書込み 1,000ms 強 100同時アクセス スループットの裏返しの特性 時間と共に性能低下
  34. 34. © Hitachi Solutions, Ltd. 2014. All rights reserved. Riak構成図 3.5. 検証:【メモリ・ディスク併用】 - Riak 33 同時書込み性能・メモリ消費時の性能 Disk Value 4ノード Key ノード クライ アント 1台 P2P メモリが無くなるまで 長時間書込み 同時書込み性能 同時アクセス数を増加
  35. 35. © Hitachi Solutions, Ltd. 2014. All rights reserved. 3.5. 検証:【メモリ・ディスク併用】 - Riak 34 同時書込み性能 ・Riak - スループット 0 500 1000 1500 2000 2500 3000 3500 4000 4500 5000 0 50 100 150 200 250 300 ス ル ー プ ッ ト ( ops/sec ) 処理時間(sec) 100同時アクセス 30同時アクセス 性能が伸びない Riakノード間のデータ振分がボトルネック 構成を見直し、 クライアントから各ノードへ負荷分散
  36. 36. © Hitachi Solutions, Ltd. 2014. All rights reserved. Riak構成図 (負荷分散) 3.5. 検証:【メモリ・ディスク併用】 - Riak 35 同時書込み性能・メモリ消費時の性能 負荷分散 25% 25% 25% Disk Value 4ノード Key ノード クライ アント 2台 25% メモリが無くなるまで 長時間書込み 同時書込み性能 同時アクセス数を増加 P2P 全ノード間 で振分け
  37. 37. © Hitachi Solutions, Ltd. 2014. All rights reserved. 3.5. 検証:【メモリ・ディスク併用】 - Riak 36 同時書込み性能 ・Riak - スループット 0 1000 2000 3000 4000 5000 6000 7000 8000 9000 10000 0 20 40 60 80 100 120 140 ス ル ー プ ッ ト ( ops/sec ) 処理時間(sec) 320同時アクセス (80同時アクセス×4) 100同時アクセス (25同時アクセス×4) 40同時アクセス (10同時アクセス×4) 20スレッド (5同時アクセス×4) 640同時アクセス (160同時アクセス×4) 100スレッド (100同時アクセス×1) 25同時アクセス×4以上で 性能が頭打ち 負荷分散により 性能向上
  38. 38. © Hitachi Solutions, Ltd. 2014. All rights reserved. 3.5. 検証:【メモリ・ディスク併用】 - Riak 37 同時書込み性能 ・Riak - レイテンシ 1 10 100 10 30 50 70 90 110 130 150 レ イ テ ン シ ( ms ) 処理時間(sec) 320同時アクセス 100同時アクセス 40同時アクセス 20同時アクセス 640同時アクセス アクセス増につれて性能低下
  39. 39. © Hitachi Solutions, Ltd. 2014. All rights reserved. 3.5. 検証:【メモリ・ディスク併用】 - Riak 38 メモリ消費時の性能 ・Riak - スループット 0 1000 2000 3000 4000 5000 6000 7000 8000 9000 10000 0 2000 4000 6000 8000 10000 12000 14000 16000 ス ル ー プ ッ ト ( ops/sec ) 処理時間(sec) メモリ枯渇のため 仮想メモリ書込み 2,200ops/sec前後 100同時アクセス 約 8,000ops/sec で安定 周期的に性能低下?
  40. 40. © Hitachi Solutions, Ltd. 2014. All rights reserved. 1 10 100 1000 10000 0 2000 4000 6000 8000 10000 12000 14000 16000 レ イ テ ン シ ( ms ) 処理時間(sec) 3.5. 検証:【メモリ・ディスク併用】 - Riak 39 メモリ消費時の性能 ・Riak - レイテンシ 15ms弱 仮想メモリ書込み 50ms前後 スループットの裏返しの特性 終盤、メモリ枯渇につれて性能低下 100同時アクセス
  41. 41. © Hitachi Solutions, Ltd. 2014. All rights reserved. 3.6. 検証:【メモリ・ディスク併用】 - まとめ 40 同時書込み性能・メモリ消費時の性能 わかったこと 1) 同時アクセス特性 同時アクセス数が増加すると、データ振分け処理が ボトルネック。負荷分散が必要。 2) メモリ消費時の性能特性 メモリ消費にともなって、徐々に性能低下。 メモリを使い切ると大きく性能低下。 3) スループット(中盤の安定状態) ・okuyama:10,000 ops/sec ⇒ 6,000 ops/sec ・Riak:平均約 8,000 ops/sec
  42. 42. © Hitachi Solutions, Ltd. 2014. All rights reserved. 4. ベンチマークのまとめ
  43. 43. © Hitachi Solutions, Ltd. 2014. All rights reserved. 4.1. 検証パターンごとのまとめ(再掲) 42 【メモリ・ディスク併用】 1) 同時アクセス特性 同時アクセス数が増加すると、 データ振分け処理が ボトルネック。負荷分散が必要。 2) メモリ消費時の性能特性 メモリ消費にともなって、徐々に性能 低下。 メモリを使い切ると大きく性能低下。 3) スループット(中盤の安定状態) ・okuyama:10,000~6,000 ops/sec ・Riak:約 8,000 ops/sec 【ディスク保存】 1) 同時アクセス特性 同時アクセス数が増加しても、 急な性能低下はしない。 ディスクI/Oがボトルネック。 2) スケールアウト特性 ノード追加に対して性能向上。 3) スループット 最大で約 100~200 ops/sec ・okuyama: 84 ops/sec ・Riak: 220 ops/sec
  44. 44. © Hitachi Solutions, Ltd. 2014. All rights reserved. 4.2. センサーデータ蓄積で使う時のポイント 43 【ディスク保存】 ディスク性能・クラスタ台数を要検討 ディスクI/Oがボトルネック。スケールアウトで性能向上するので、 性能要件に応じて検討すること。 【メモリ・ディスク併用】 1) 残メモリ量に要注意 2) クライアントからKVSへの書込み負荷分散が重要 1) メモリの監視、スケールアウトのタイミングなど、運用を検討すること。 2) KVSのデータ振分け処理がボトルネックになる。負荷分散すること。
  45. 45. 本資料に掲載されている会社名、製品名、サービス名は各社の登録商標、又は商標です。 ・okuyama は、株式会社神戸デジタル・ラボの登録商標です。 ・Riak は、 Basho Technologies, Inc. の登録商標です。 ・Cassandra は、 Apache Software Foundation の商標です。 ・HBase は、 Apache Software Foundation の商標です。 ・MongoDB は、 MongoDB, Inc. の登録商標です。 ・CouchDB は、 Apache Software Foundation の商標です。 ・Intel、Intel Core は、 Intel Corporation の登録商標です。 ・OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における 登録商標です。文中の社名、商品名等は各社の商標または登録商標である場合があります。 ・Yahoo! は、 Yahoo! Inc. の登録商標です。 ・その他記載の会社名、製品名は、それぞれの会社の商標もしくは登録商標です。
  46. 46. © Hitachi Solutions, Ltd. 2014. All rights reserved. 【補足】 永続化について 45 ※データの保存先にかかわらず、永続化は可能 データ操作の履歴ログ(ジャーナル)を作成し永続化 Disk Disk Value Key ・パターン1 KeyとValueをディスク保存 ・パターン2 Keyをメモリ、 Valueをディスク保存 Key Value ・パターン3 KeyとValueをメモリ保存 KVS KVS KVS Disk ジャーナル ジャーナル ジャーナル Key Value サーバ再起動時はジャーナルから復旧
  47. 47. © Hitachi Solutions, Ltd. 2014. All rights reserved. 【補足】 YCSBの構成 46参考:http://labs.yahoo.com/files/ycsb-v4.pdf YCSB NoSQL ワ ー ク ロ ー ド 実 行 処 理 スループット レイテンシの 統計処理 ワークロード設定ファイル ・CRUD処理の配分 ・全データ件数 など コマンドラインパラメータ ・接続先(IP、ポートなど) ・スレッド数(同時アクセス数) など NoSQLクライアント ・NoSQLへの接続 ・CRUD処理 MongoDB HBase ・ ・ ・ okuyama Riak クライアント スレッド生成 「okuyama」と「Riak」用のクライアントを作成
  48. 48. © Hitachi Solutions, Ltd. 2014. All rights reserved. KVSのJavaライブラリを利用し、クライアントを作成 【補足】 okuyama, Riak クライアント 47 public int insert(String table, String key, HashMap<String, ByteIterator> values) { com.mongodb.DB db = null; try { db = mongo.getDB(database); db.requestStart(); DBCollection collection = db.getCollection(table); DBObject r = new BasicDBObject().append("_id", key); for(String k: values.keySet()) { r.put(k, values.get(k).toArray()); } WriteResult res = collection.insert(r,writeConcern); return res.getError() == null ? 0 : 1; } catch (Exception e) { System.err.println(e.toString()); return 1; } finally { if (db!=null) { db.requestDone(); } } } public int insert(String table, String key, HashMap<String, ByteIterator> values) { try { boolean setResult = okuyamaClient.setValue(key, key); if (setResult) { System.out.println("setKey = "+key); } else { System.out.println("setValue Result = [Server Error]"); System.exit(1); } } catch(OkuyamaClientException oc) { oc.printStackTrace(); } return 0; } 他NoSQL用のクライアントを流用 okuyamaとRiak用に メソッドを書き換え 書込みベンチマーク用のため、KVS接続処理とInsert処理のみ作成 ・okuyama、Riakクライアント共に80行程度 ・書込むデータは、KeyとValue共に約25バイト ・okuyama : okuyama本体に同梱のライブラリ ・Riak : 公式サポートのJavaライブラリ ※入手先:【https://github.com/basho/riak-java-client/tree/1.4.2】
  49. 49. © Hitachi Solutions, Ltd. 2014. All rights reserved. 【補足】 その他 注意点 48 ・ベンチマークの間、リソース監視データを出力 リソース状況の確認のため、 YCSBおよびKVSサーバ上でsarコマンドを実行し、 ベンチマーク中のリソースのデータを出力した。 ・KVSはテスト毎に再インストール KVS内のテストデータ削除のため、 1テストケース実施ごとに、 KVSのアンインストールと再インストールを実施した。

×