分散Key-Valueストア okuyama Riak 書込み性能検証...1.5. 検証対象NoSQLの検討（2/2）永続化機能の有無永続化機能なし（インメモリ）永続化機能あり

© Hitachi Solutions, Ltd. 2014. All rights reserved.

分散Key-Valueストア「okuyama」 & 「Riak」書込み性能検証

株式会社日立ソリューションズオープンソース技術開発センタ

2014/7/5

倉又裕輔


自己紹介

1

名前：

倉又裕輔（くらまたゆうすけ）

所属：

（株）日立ソリューションズオープンソース技術開発センタ

担当業務：

OSSのNoSQL技術の調査、検証

・エンタープライズ利用に向けた調査と検証

・技術情報の社内外への発信


１. 検証の背景

２. ベンチマーク方法

３. ベンチマーク結果

発表の流れ

４. 考察


１. 検証の背景

なぜ「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）

永続化機能の有無

永続化機能なし（インメモリ）永続化機能あり

データ分散機能の実装

クライアント側

KVS側

8

okuyama

Riak

memcached Redis


KVSの分類

１.５. 検証対象NoSQLの検討（2/2）

永続化機能の有無

永続化機能なし（インメモリ）永続化機能あり

データ分散機能の実装

クライアント側

KVS側

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

「okuyama」と「Riak」の特性は構成によって異なる

Disk

Key Value

Disk

Value Key

パターン１【ディスク保存】

パターン２【メモリ・ディスク併用】

Key Value

パターン３【インメモリ】

KVS KVS KVS

大量データ保存が要件のため、パターン１と２を検証

データ保存容量大小

書込み速度遅速


２.３. 検証の観点

15

観点１：同時書込み性能

観点２：各検証パターンごとの懸念点を検証

Disk

Value Key

【メモリ・ディスク併用】

メモリが無くなるまで書込み、性能変化を検証

大量データ保存によるメモリ消費時の性能？

Disk

Key Value

【ディスク保存】

書込み速度が遅い？

スケールアウトによる性能向上を検証

クライアント

KVS

同時アクセス数を増やして、性能変化を検証


okuyama v0.9.5 （1ノード/台）

２.４. 検証環境

16

１台

１～４台

マスタ

スレーブ

Riak v1.4.6 （1ノード/台）

１～４台

ノード

クライアント

１台クライアント

１台

CPU Intel(R) Core(TM) i5 CPU 520

メモリ 4GB

HDD（SATA） 750GB, 5400RPM

OS CentOS 6.5 64bit

※データの複製・レプリケーション無し


２.５. ベンチマークツール

17

参考： 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の動き

18

START

①同時アクセス数（スレッド数）、書込むデータ件数を指定し実行 ①

②スレッドごとにNoSQLへ接続 ②

③書込み処理開始全件を処理するまで繰り返し１件単位のスループットとレイテンシを計測

Key Value ③

YCSB NoSQL

④ ④全件の処理を終えたら終了スループット・レイテンシの計測結果を集計し出力

END 書込むデータは、 KeyとValue共に

約25バイト


３. ベンチマーク結果


３.１. 検証パターンと観点の確認

20

Disk

Key Value

Disk

Value Key

【ディスク保存】【メモリ・ディスク併用】

KVS KVS

観点１：同時書込み性能観点１：同時書込み性能

okuyama Riak okuyama Riak

観点２：スケールアウト性能観点２：メモリ消費時の性能

４つの検証ごとにそれぞれ説明

検証① 検証② 検証③ 検証④


３.２. 検証① okuyama - 【ディスク保存】

21

Disk

Key Value

１ノード

１台

１～４ノード

マスタ

スレーブ

クライアント


同時アクセス数を増加

マスタ-スレーブ

観点２：スケールアウト性能

ノード数を増加



22

0

20

40

60

80

0 50 100 150 200 250 300

スループット[ o

ps/

sec ]

同時アクセス数

同一条件で大量件数書込み、平均値をプロット

４ノード

３ノード

２ノード

１ノード

観点１：同時書込み性能 ⇒ピークを取り、その後はほぼ一定

約84ops/sec

観点２：スケールアウト性能 ⇒ノード追加で性能向上



23

0

2000

4000

6000

8000

10000

12000

0 50 100 150 200 250 300

レイテンシ[ m

s ]


４ノード

３ノード

２ノード

１ノード観点２：スケールアウト性能 ⇒ノード追加で性能向上

観点１：同時書込み性能 ⇒アクセス増に比例し性能低下



24

わかったこと

１）同時アクセス性能

同時アクセス数が増加しても、急な性能低下はしない。

リソース使用状況から、ディスクI/Oがボトルネック。

２）スケールアウト性能

ノード追加に対して想定通り性能向上。

３）スループット

最大で約 84 ops/sec （４ノードクラスタ）


３.３. 検証② Riak - 【ディスク保存】

25

Disk

Key Value １～４ノード

ノード

P2P




観点２：スケールアウト性能

ノード数を増加



26

0

50

100

150

200

250

0 50 100 150 200 250 300 350 400


ps/

sec ]


４ノード


３ノード

２ノード

１ノード

観点１：同時書込み性能 ⇒ピークを取り、その後はほぼ一定

約220ops/sec



27

0

500

1000

1500

2000

2500

0 50 100 150 200 250 300 350 400

レイテンシ[ m

s ]


４ノード

３ノード

２ノード


１ノード

観点１：同時書込み性能 ⇒アクセス増に比例し性能低下

他と違う動き？



28

わかったこと


同時アクセス数が増加しても、急な性能低下はしない。

リソース使用状況から、ディスクI/Oがボトルネック。

２）スケールアウト特性

ノード追加に対して想定通り性能向上。

３）スループット

最大で約 220 ops/sec （４ノードクラスタ）


３.４. 検証③ okuyama - 【メモリ・ディスク併用】

29

１ノード

１台

４ノード

マスタ

スレーブ

クライアント



マスタ-スレーブ

Disk

Value Key

観点２：メモリ消費時の性能

メモリが無くなるまで長時間書込み



30

0

5000

10000

15000

20000

25000

30000

0 100 200 300 400 500 600 700


ps/

sec ]

処理時間[ sec ]

時間と共に性能変化 ⇒平均値ではなく時間変化を計測

３００同時アクセス

１００同時アクセス

３０同時アクセス

１０同時アクセス

他と違う動き？マスタノードの負荷が高い

観点１：同時書込み性能：同時アクセス数を増加

アクセス増に対してピークを取り、その後急に性能低下



31

0.1

1

10

100

0 100 200 300 400 500 600 700

レイテンシ[ m

s ]

処理時間[ sec ]

３００同時アクセス



１０同時アクセス

アクセス増につれて性能低下



0

5000

10000

15000

20000

25000

0 2000 4000 6000 8000 10000 12000


ps/

sec ]

処理時間[ sec ]


32

JVMのメモリ枯渇のためディスク書込み 65～85ops/sec

急に性能低下

10,000～6,000ops/sec やや安定


観点２：メモリ消費時の性能：メモリが無くなるまで長時間書込み



33

1

10

100

1000

10000

0 2000 4000 6000 8000 10000 12000

レイテンシ[ m

s ]

処理時間[ sec ]

20ms 弱

ディスク書込み 1,000ms 強


スループットの裏返しの特性時間と共に性能低下




34

わかったこと


同時アクセス数が増加すると、データ振分け処理が

ボトルネック。マスタノード追加による負荷分散が必要。

２）メモリ消費時の性能

メモリ消費にともなって、徐々に性能低下。

JVMのメモリを使い切ると、ディスク書込みに切り替わり、

大きく性能低下。

３）スループット（中盤の安定状態）

10,000 ops/sec ⇒ 6,000 ops/sec （４ノードクラスタ）


３.５. 検証④ Riak - 【メモリ・ディスク併用】

35

４ノード

P2P




Disk

Value Key

ノード





36

0

1000

2000

3000

4000

5000

0 50 100 150 200 250 300


ps/

sec ]

処理時間[ sec ]



性能が伸びない

データ振分けするノードが高負荷

↓

負荷分散が必要




37

４ノード


Disk

Value Key

ノード

構成見直し前 P2P



38

４ノード

P2P

２台

Disk

Value Key

ノード

クライアント

均等に負荷分散





構成見直し後



39

0

2000

4000

6000

8000

10000

0 20 40 60 80 100 120 140


ps/

sec ]

処理時間[ sec ]

１００同時アクセス（負荷分散後）

１００同時アクセス（負荷分散前）

１００同時アクセス以上で性能が頭打ち

２０同時アクセス

４０同時アクセス

３２０同時アクセス

６４０同時アクセス

負荷分散により性能向上




40

1

10

100

10 40 70 100 130

レイテンシ[ m

s ]

処理時間[ sec ]

３２０同時アクセス


４０同時アクセス

２０同時アクセス

６４０同時アクセス

アクセス増につれて性能低下




41

0

2000

4000

6000

8000

10000

0 2000 4000 6000 8000 10000 12000 14000 16000


ps/

sec ]

処理時間[ sec ]

物理メモリを使い切ったため Swapへ書込み

2,200ops/sec前後

１００同時アクセス約 8,000ops/sec で安定



1

10

100

1000

10000

0 2000 4000 6000 8000 10000 12000 14000 16000

レイテンシ[ m

s ]

処理時間[ sec ]


42

15ms弱

Swap書込み 50ms前後

スループットの裏返しの特性終盤、物理メモリ枯渇につれて性能低下





43

わかったこと


同時アクセス数が増加すると、データ振分け処理が

ボトルネック。クライアントアクセスの負荷分散が必要。

２）メモリ消費時の性能

物理メモリを使い切るまでは安定した性能。

物理メモリを使い切るとSwap書込みとなり、

大きく性能低下。

３）スループット（中盤の安定状態）

平均約 8,000 ops/sec （４ノードクラスタ）


４. 考察


４.1. センサーデータ蓄積で使う時のポイント

45

【ディスク保存】

ディスク性能・クラスタ台数を要検討

ディスクI/Oがボトルネック。スケールアウトで性能向上するので、

性能要件に応じて検討すること。

【メモリ・ディスク併用】

1) クライアントからKVSへの書込み負荷分散が重要

2) 残メモリ量に要注意

1) KVSのデータ振分け処理がボトルネックになりやすいので、

負荷分散すること。

2) メモリがなくなると性能が大幅ダウン。

メモリの監視、スケールアウトのタイミングなど、運用を検討すること。

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


【補足】永続化について

47

※データの保存先にかかわらず、永続化は可能

データ操作の履歴ログ（ジャーナル）を作成し永続化

Disk Disk

Value

Key

・パターン１ KeyとValueをディスク保存

・パターン２ Keyをメモリ、 Valueをディスク保存

Key Value

・パターン３ KeyとValueをメモリ保存

KVS KVS KVS

Disk

ジャーナル

ジャーナルジャーナル

Key Value

サーバ再起動時はジャーナルから復旧


【補足】 YCSBの構成

48

参考：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 クライアント

49

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】


【補足】その他注意点

50

・ベンチマークの間、リソース監視データを出力リソース状況の確認のため、

YCSBおよびKVSサーバ上でsarコマンドを実行し、

ベンチマーク中のリソースのデータを出力した。

・KVSはテスト毎に再インストール KVS内のテストデータ削除のため、

１テストケース実施ごとに、

KVSのアンインストールと再インストールを実施した。

Documents

分散Key-Valueストア okuyama Riak 書込み性能検証...1.5. 検証対象NoSQLの検討（2/2） 永続化機能の有無 永続化機能なし（インメモリ） 永続化機能あり

分散Key-Valueストア okuyama Riak 書込み性能検証...1.5. 検証対象NoSQLの検討（2/2）永続化機能の有無永続化機能なし（インメモリ）永続化機能あり