Unified Computing and Servers (UCS)
http://www.cisco.com/en/US/products/ps10265/index.html
Cisco UCS C210 M2 General-Purpose Rack-Mount Server
http://www.cisco.com/en/US/products/ps10889/index.html
Cisco UCS C200 M2 High-Density Rack-Mount Server
http://www.cisco.com/en/US/products/ps10891/index.html
C210には96GBのRAM、Xeon X5670 CPU (2.93 GHz)が2個、7200 rpm SASドライブが16個載っています。このHDDは8個ずつの2セットに分けられていて、各々がハードウェアコントローラでRAID-0構成になっており、それぞれをOS（Linux 2.6.32-130.el6.x86_64）で大きなRAID-0構成に束ねています。Cisco 10GigEスイッチを使って全てのマシン（Repノードと負荷マシン）をつなぎます。
今回は Yahoo! Cloud System Benchmark （以下、YCSB）をテストクライアントに使用しました。キーサイズは13バイト、データサイズは 1108 バイト (シリアライズ後1KByteになります）とし、2個の方法でテストしました。一つはデータロードのテスト、もう一つはRead/Updateの比率が50/50のテストです。YCSBがサポートするデータ件数は、JavaのInteger型の最大値（約21億件）しかサポートしないため、各NoSQL Database Repグループ毎に4億件のデータを作成しました。"KVS size"列にはKey-Valueストアにあるデータ件数が入っており、その後にRepグループの番号とReplication Factorが括弧内に入っています。例えば、400m(1x3)は、Key-Valueストアにある全4億件のデータは、Replication Factorが3（つまり3個のReplication Node）で出来ている1つのRep Groupからなっている、ということを意味します。
C200ノード（X5670 Xeon CPU×2個と96GBのRAM）でクライアントを実行しています。メモリ限界やI/Oの限界ではないので、CPUの速度だけが問題になります。通常は、YCSBのクライアントプロセスあたり90のクライアントスレッドで実行していました。以下の表では、クライアントプロセスの合計数を"Clients"列に示していますが、90スレッド/クライアント（通常の場合）では、合計クライアントスレッドは、"Total Client Threads"列に表示しています。
Oracle NoSQL DatabaseのRep Nodeのキャッシュサイズを設定して、B+ツリーの内部ノードがメモリに収まるようにしていましたが、リーフノード（データ）に対してはそういう設定をしていませんでした。具体的には、キャッシュを22GB、JVMのヒープに32GB設定しました。そのため、50/50 Read/Writeの結果は、YCSBのオペレーションあたりの単一のI/Oを示しています。Durability（永続性）はNoSQL Database推奨値（でありデフォルト）のno_sync、simple_majority、no_syncとしました。我々が読んで50/50 read/updateのテストで利用したConsistency（一貫性）はConsistency.NONEとしました。
Insertの結果
| KVS size | Clients | Total Client Threads | Time (sec) | Throughput (inserts/sec) | Insert Avg Latency (ms) | 95% Latency (ms) | 99% Latency (ms) |
| 400m(1x3) | 3 | 90 | 15,139 | 26,498 | 3.3 | 5 | 7 |
| 1200m(3x3) | 3 | 270 | 16,738 | 71,684 | 3.6 | 7 | 11 |
| 1600m(4x3) | 4 | 360 | 17,053 | 94,441 | 3.7 | 7 | 18 |
50/50 Read/Updateの結果
| KVS size (millions) | Clients (processes) | Total Client Threads | Total Throughput (ops/sec) | Avg Read Latency (ms) | 95% Read Latency (ms) | 99% Read Latency (ms) | Avg Update Latency (ms) | 95% Update Latency (ms) | 99% Update Latency (ms) |
| 400m(1x3) | 3 | 30 | 5,595 | 4.8 | 13 | 50 | 5.6 | 13 | 52 |
| 1200m(3x3) | 3 | 270 | 17,097 | 4.0 | 13 | 53 | 5.7 | 15 | 57 |
| 1600m(4x3) | 4 | 360 | 24,893 | 4.0 | 12 | 43 | 5.3 | 14 | 51 |
この結果から、Oracle NoSQL Databaseはスケーラビリティが高く、高スループット、低レイテンシであることがわかります。今回のテストに協力頂き、ハードウェア、検証環境、スタッフを提供頂いたCiscoの皆様には感謝申し上げます。
原文はこちら。
http://blogs.oracle.com/charlesLamb/entry/oracle_nosql_database_performance_tests
0 件のコメント:
コメントを投稿