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

© Hitachi Solutions, Ltd. 2014. All rights reserved.
分散Key-Valueストア「okuyama」 & 「Riak」
書込み性能検証
株式会社日立ソリューションズ
オープンソース技術開発センタ
2014/6/19
倉又裕輔

自己紹介
1
 名前：
倉又裕輔（くらまたゆうすけ）
 所属：
（株）日立ソリューションズオープンソース技術開発センタ
 担当業務：
NoSQL技術の調査、検証
・エンタープライズ利用に向けた調査と検証
・技術情報の社内外への発信

１. 検証の背景
２. ベンチマーク方法
３. ベンチマーク結果
Contents
４. ベンチマークのまとめ

１. 検証の背景
なぜ「okuyama」と「Riak」を検証したのか
NoSQL、Key-Value ストアに着目した背景

１.１ IT技術動向
4
近年のビッグデータへの期待から、IoTへの関心が高まっている
2017年までに20%以上の企業が、
従来の情報機器とは異なるセンサや組み込み機器などを
利用し、ビジネスを取り巻く環境をデジタル化する。
多様な情報を収集、分析することで
製品やサービスをより効果的に提供するために、
モノのインターネットに関する新たな取り組みを行う。
☆引用： 2014年4月17日ガートナージャパン株式会社プレスリリース
【 http://www.gartner.co.jp/press/html/pr20140417-01.html 】

１.２. IoT（センサー）に適するデータストア要件
5
センサーデータの特徴
１）非構造データ
２）記録回数/時間：多
３）センサー数：大量
４）データ送信頻度：高
データストアの要件
A）非構造データの保存
B）大量データの保存
C）高速な書込み性能

しかし、性能に関する情報が不足している
特に書込み性能に注目し
知見を増やすために検証を実施した
１.３. NoSQL適合の課題
6
リレーショナルデータベース（RDB）以外のデータストアの総称
SQLを使用せずにデータを操作する
NoSQL（Not only SQL）
★苦手
・トランザクション処理
・複雑な検索、集計処理
☆得意
・非構造データの保存（スキーマレス）
・スケールアウト（大量データの保存）
・高速な書込み、参照処理
データストアの要件に適合

１.４. 検証対象NoSQLの検討（1/2）
7
NoSQLの分類（データモデル）
ドキュメント指向
・MongoDB
・CouchDB
・Couchbase Server など
Key-Value ストア
（KVS）
・okuyama
・Riak
・memcached
・Redis など
カラム指向
・Cassandra
・Hbase
・Hypertable など
Key Value
Key Value
データが
シンプル
KVSは小さい多数データの蓄積、高速なデータ読み書きが得意
センサーデータに適している

KVSの分類
１.５. 検証対象NoSQLの検討（2/2）
永続化機能の有無
永続化機能なし（インメモリ）永続化機能あり
デ
ー
タ
分
散
機
能
の
実
装
ク
ラ
イ
ア
ン
ト
側
K
V
S
側
8
okuyama
Riak
memcached Redis

KVSの分類
１.５. 検証対象NoSQLの検討（2/2）
永続化機能の有無
永続化機能なし（インメモリ）永続化機能あり
デ
ー
タ
分
散
機
能
の
実
装
ク
ラ
イ
ア
ン
ト
側
K
V
S
側
9
okuyama
Riak
memcached Redis
・ KVSのみで
データ蓄積可能
・データ分散や
スケールアウトが
容易
「okuyama」と「Riak」を検証対象として選択

１.６. okuyama の特徴
10
okuyama
開発元株式会社神戸デジタル・ラボ
ライセンス GPL v3 （商用ライセンス・サポートあり）
開発言語 Java
分散アーキテクチャマスタ-スレーブ型
ユースケース ECサイト、検索エンジン、キャッシュサーバ、ログ管理、など
開発元：神戸デジタル・ラボ ( http://okuyama-project.com/ja/index.html )
スレーブ
マスタ
データ操作データ振分けデータ保存
クライ
アント
・マスタ-スレーブ型
・データの永続化が可能
・冗長化により
単一障害点の無い
クラスタを構築可能
・無停止でスケールアウト可能
・データ保存先を選択可能
（ディスク・メモリ・併用）
スレーブ

１.７. Riak の特徴
11
Riak
開発元 Basho Technologies, Inc.
ライセンス Apache License, Version 2.0 （商用ライセンス・サポートあり）
開発言語 Erlang/C
分散アーキテクチャ P2P型
ユースケース ECサイト、キャッシュサーバ、オブジェクトストレージ、など
開発元： Basho Technologies ( http://basho.co.jp/riak/ )
・P2P型
・データの永続化が可能
・単一障害点なし
・無停止でスケールアウト可能
・データ保存先を選択可能
（ディスク・メモリ・併用）
データ操作データ振分け・保存
クライ
アントノード
ノード
ノード

２. ベンチマーク方法
検証環境、ベンチマークツール
ベンチマークの内容
検証の目的、観点

２.１. 検証の目的
13
同時書込み性能が重要
実際どのくらい速いのか？ベンチマーク実施
KVS
多数のセンサーが
高頻度に大量件数のデータを同時送信
センサー

２.２. 検証の観点
14
スループット（書込み数/秒）とレイテンシ（書込み時間）を計測
クライ
アント KVS
増加させてベンチマーク
Key Value
Insert
☆観点：同時書込み性能
センサー何台まで性能低下せず
同時書き込みできるか？

２.３. 検証パターン
15
「okuyama」と「Riak」の特性は構成によって異なる
Disk
Key Value
Disk
ValueKey
パターン１
【ディスク保存】
パターン２
【メモリ・ディスク併用】
Key Value
パターン３
【インメモリ】
KVS KVS KVS
大量データ保存が要件のため、パターン１と２を検証
データ保存容量大小
書込み速度遅速

２.４. 検証パターンごとの観点
16
各検証パターンごとの懸念点についても検証
Disk
Key Value
Disk
ValueKey
パターン１
パターン２
KVS KVS
メモリが無くなるまで書込み、
性能変化を検証
書込み速度が遅い？
大量データ保存による
メモリ消費時の性能？
スケールアウトによる
性能向上を検証

okuyama v0.9.5 （1ノード/台）
２.５. 検証環境
17
１台
１～４台
マスタ
スレーブ
Riak v1.4.6 （1ノード/台）
１～４台
ノード
クライ
アント
１台クライ
アント
１台
CPU Intel(R) Core(TM) i5 CPU 520
メモリ 4GB
HDD（SATA） 750GB, 5400RPM
OS CentOS 6.5 64bit
※データの複製・レプリケーション無し

２.６. ベンチマークツール
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）」を利用

２.７. YCSBの動き
19
START
①スレッド数（同時アクセス数）、
処理するデータ件数を指定し実行 ①
②スレッドごとにNoSQLへ接続 ②
③書込み処理開始
全件を処理するまで繰り返し
１件単位のスループットと
レイテンシを計測
Key Value③
YCSB NoSQL
④④全件の処理を終えたら終了
スループット・レイテンシの
計測結果を集計し出力
END
書込むデータは、
KeyとValue共に
約25バイト
okuyamaとRiak用の
クライアントを作成（約80行）

３. ベンチマーク結果
メモリ・ディスク併用パターンの検証結果
okuyama
Riak
ディスク保存パターンの検証結果
okuyama
Riak

okuyama構成図
３.１. 検証：【ディスク保存】 - okuyama
21
同時書込み性能・スケールアウト性能
Disk
Key Value
１ノード
１台
１～４
ノード
マスタ
スレーブ
クライ
アント
スケールアウト性能
ノード数を増加
同時書込み性能
同時アクセス数を増加マスタ-スレーブ

22
・okuyama - スループット
0
10
20
30
40
50
60
70
80
90
0 50 100 150 200 250 300
ス
ル
ー
プ
ッ
ト
[ops/sec]
同時アクセス数（スレッド数）
同一条件で大量件数書込み、
平均値をプロット
４ノード
性能が
スケール
３ノード
２ノード
１ノード
ピークを取り、その後はほぼ一定
約84ops/sec

23
・okuyama - レイテンシ
0
2000
4000
6000
8000
10000
12000
0 50 100 150 200 250 300
レ
イ
テ
ン
シ
[ms]
４ノード
３ノード
２ノード
１ノード
性能が
スケール
アクセス増に比例し
性能低下

Riak構成図
３.２. 検証：【ディスク保存】 - Riak
24
１台クライ
アント
Disk
Key Value
１～４
ノード
ノード
スケールアウト性能
ノード数を増加
同時アクセス数を増加P2P

25
・Riak - スループット
0
50
100
150
200
250
0 50 100 150 200 250 300 350 400
ス
ル
ー
プ
ッ
ト
[ops/sec]
４ノード
性能が
スケール
３ノード
２ノード
１ノード
ピークを取り、その後はほぼ一定
約220ops/sec

26
・Riak - レイテンシ
0
500
1000
1500
2000
2500
0 50 100 150 200 250 300 350 400
レ
イ
テ
ン
シ
[ms]
４ノード
３ノード
２ノード
性能が
スケール
１ノード
アクセス増に比例し
性能低下
他と違う
動き？

３.３. 検証：【ディスク保存】 - まとめ
27
わかったこと
１）同時アクセス特性
同時アクセス数が増加しても、急な性能低下はしない。
リソース使用状況から、ディスクI/Oがボトルネック。
２）スケールアウト特性
ノード追加に対して想定通り性能向上。
３）スループット
最大で約 100～200 ops/sec のオーダー
（okuyama： 84ops/sec 、Riak： 220 ops/sec）

okuyama構成図
３.４. 検証：【メモリ・ディスク併用】 - okuyama
28
同時書込み性能・メモリ消費時の性能
Disk
Value
４ノード
Key
スレーブ
１ノード
１台
マスタ
クライ
アント
同時アクセス数を増加
メモリが無くなるまで
長時間書込み
マスタ-スレーブ

29
0
5000
10000
15000
20000
25000
30000
0 100 200 300 400 500 600 700
ス
ル
ー
プ
ッ
ト
（
ops/sec
）
処理時間（sec）
時間と共に性能変化
⇒平均値ではなく
時間変化を計測
ピークを取り、その後急に性能低下
３００同時アクセス
１００同時アクセス
３０同時アクセス
１０同時アクセス
他と違う動き？
マスタノードの負荷が高い

30
0.1
1
10
100
0 100 200 300 400 500 600 700
レ
イ
テ
ン
シ
（
ms
）
３００同時アクセス
１０同時アクセス
アクセス増につれて性能低下

0
5000
10000
15000
20000
25000
0 2000 4000 6000 8000 10000 12000
ス
ル
ー
プ
ッ
ト
（
ops/sec
）
31
メモリ消費時の性能
メモリ枯渇のため
ディスク書込み
65～85ops/sec
急に性能低下
10,000～6,000ops/sec
やや安定
周期的に性能低下？

32
1
10
100
1000
10000
0 2000 4000 6000 8000 10000 12000
レ
イ
テ
ン
シ
（
ms
）
20ms 弱
ディスク書込み
1,000ms 強
スループットの裏返しの特性
時間と共に性能低下

Riak構成図
３.５. 検証：【メモリ・ディスク併用】 - Riak
33
Disk
Value
４ノード
Key
ノード
クライ
アント
１台
P2P
長時間書込み

34
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
0 50 100 150 200 250 300
ス
ル
ー
プ
ッ
ト
（
ops/sec
）
性能が伸びない
Riakノード間のデータ振分がボトルネック
構成を見直し、
クライアントから各ノードへ負荷分散

Riak構成図
（負荷分散）
35
負荷分散
25% 25% 25%
Disk
Value
４ノード
Key
ノード
クライ
アント
２台
25%
長時間書込み
P2P
全ノード間
で振分け

36
0
1000
2000
3000
4000
5000
6000
7000
8000
9000
10000
0 20 40 60 80 100 120 140
ス
ル
ー
プ
ッ
ト
（
ops/sec
）
３２０同時アクセス
（８０同時アクセス×４）
（２５同時アクセス×４）
４０同時アクセス
（１０同時アクセス×４）
２０スレッド
（５同時アクセス×４）
６４０同時アクセス
（１６０同時アクセス×４）
１００スレッド
（１００同時アクセス×１）
２５同時アクセス×４以上で
性能が頭打ち
負荷分散により
性能向上

37
1
10
100
10 30 50 70 90 110 130 150
レ
イ
テ
ン
シ
（
ms
）
３２０同時アクセス
４０同時アクセス
２０同時アクセス
６４０同時アクセス
アクセス増につれて性能低下

38
0
1000
2000
3000
4000
5000
6000
7000
8000
9000
10000
0 2000 4000 6000 8000 10000 12000 14000 16000
ス
ル
ー
プ
ッ
ト
（
ops/sec
）
メモリ枯渇のため
仮想メモリ書込み
2,200ops/sec前後
１００同時アクセス約 8,000ops/sec で安定
周期的に性能低下？

1
10
100
1000
10000
0 2000 4000 6000 8000 10000 12000 14000 16000
レ
イ
テ
ン
シ
（
ms
）
39
15ms弱
仮想メモリ書込み
50ms前後
スループットの裏返しの特性
終盤、メモリ枯渇につれて性能低下

３.６. 検証：【メモリ・ディスク併用】 - まとめ
40
わかったこと
同時アクセス数が増加すると、データ振分け処理が
ボトルネック。負荷分散が必要。
２）メモリ消費時の性能特性
メモリ消費にともなって、徐々に性能低下。
メモリを使い切ると大きく性能低下。
３）スループット（中盤の安定状態）
・okuyama：10,000 ops/sec ⇒ 6,000 ops/sec
・Riak：平均約 8,000 ops/sec

４. ベンチマークのまとめ

４.１. 検証パターンごとのまとめ（再掲）
42
同時アクセス数が増加すると、
データ振分け処理が
ボトルネック。負荷分散が必要。
２）メモリ消費時の性能特性
メモリ消費にともなって、徐々に性能
低下。
メモリを使い切ると大きく性能低下。
３）スループット（中盤の安定状態）
・okuyama：10,000～6,000 ops/sec
・Riak：約 8,000 ops/sec
同時アクセス数が増加しても、
急な性能低下はしない。
ディスクI/Oがボトルネック。
２）スケールアウト特性
ノード追加に対して性能向上。
３）スループット
最大で約 100～200 ops/sec
・okuyama： 84 ops/sec
・Riak： 220 ops/sec

４.２. センサーデータ蓄積で使う時のポイント
43
ディスク性能・クラスタ台数を要検討
ディスクI/Oがボトルネック。スケールアウトで性能向上するので、
性能要件に応じて検討すること。
1) 残メモリ量に要注意
2) クライアントからKVSへの書込み負荷分散が重要
1) メモリの監視、スケールアウトのタイミングなど、運用を検討すること。
2) KVSのデータ振分け処理がボトルネックになる。負荷分散すること。

本資料に掲載されている会社名、製品名、サービス名は各社の登録商標、又は商標です。
・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. の登録商標です。
・その他記載の会社名、製品名は、それぞれの会社の商標もしくは登録商標です。

【補足】永続化について
45
※データの保存先にかかわらず、永続化は可能
データ操作の履歴ログ（ジャーナル）を作成し永続化
Disk Disk
Value
Key
・パターン１
KeyとValueをディスク保存
・パターン２
Keyをメモリ、
Valueをディスク保存
Key Value
・パターン３
KeyとValueをメモリ保存
KVS KVS KVS
Disk
ジャーナル
ジャーナルジャーナル
Key Value
サーバ再起動時はジャーナルから復旧

【補足】 YCSBの構成
46参考：http://labs.yahoo.com/files/ycsb-v4.pdf
YCSB
NoSQL
ワ
ー
ク
ロ
ー
ド
実
行
処
理スループット
レイテンシの
統計処理
ワークロード設定ファイル
・CRUD処理の配分
・全データ件数
など
コマンドラインパラメータ
・接続先(IP、ポートなど)
・スレッド数（同時アクセス数）
など
NoSQLクライアント
・NoSQLへの接続・CRUD処理
MongoDB
HBase
・
・
・
okuyama
Riak
クライアント
スレッド生成
「okuyama」と「Riak」用のクライアントを作成

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】

【補足】その他注意点
48
・ベンチマークの間、リソース監視データを出力
リソース状況の確認のため、
YCSBおよびKVSサーバ上でsarコマンドを実行し、
ベンチマーク中のリソースのデータを出力した。
・KVSはテスト毎に再インストール
KVS内のテストデータ削除のため、
１テストケース実施ごとに、
KVSのアンインストールと再インストールを実施した。

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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (10)

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

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

More from Insight Technology, Inc.

More from Insight Technology, Inc. (20)

Recently uploaded

Recently uploaded (9)

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