cassandra調査レポート

分散 DB「Cassandra」に関する調査/検証

<日付 2010/03/23> 桑野　章弘

1

はじめに................................................................................................................................. 3
概要........................................................................................................................................4
特徴........................................................................................................................................5
ソフトウェアアーキテクチャ................................................................................................6
ハードウェア要件................................................................................................................11
検証......................................................................................................................................13
総評......................................................................................................................................28
疑問点..................................................................................................................................29
参考文献...............................................................................................................................30

2

 はじめに
現在 RDB が使われてきている部分に関して、 RDB 以外では出来ないのかを模索する
noSQL（NotOnlySQL）と言う流れが急速に加速している。
特に Web アプリケーションにおいては RDB は冗長である傾向があり、での sharding も
RDB
限界がある。
そこで Facebook 社が開発した分散 DB「cassandra」について、実際どの程度使えるのかを
調査/検証してみた。

3

 概要
Cassandra は Facebook で作られた分散型 DB サーバである。
Dynamo 的な大規模分散管理と、HyperTable の様なカラム型データ構造を持った DB となっ
ており、高可用性と冗長性を併せ持つ。
目標としては、これらを上手く利用することで今まで MySQL で行っているレプリケーショ
ンとテーブル分割でサーバをスケールアウトしていく方法を、サーバ追加のみを考えて運
用する形に変えていけるようになる事、となる。

機能に関しては次の項で説明する。

4

 特徴
Cassandra の特徴として、以下の物があげられる。

1. 大規模データ
元々大規模データを扱えるように設計しており、実際の事例としても 150 台のサーバ
で 100TB のデータを管理している物がある。

2. 分散処理
全ノードが同一のサーバとなっており、管理ノードなどは存在せず各サーバが相互に
通信しあって処理を行う。そのためネットワークボトルネックが無ければ SPOF も無い
ということになる。

3. 冗長性
データは各ノードに自動でレプリケーションが行われる。
レプリケーションをデータセンタ毎に分けて DR を行うことも可能。

4. 高可用性/柔軟性
性能はノードの数によってリニアに増えていくことができ、ノードの追加、削除もダ
ウンタイムなしで行うこともできる。
Consistency のレベルを決めることもできる、書き込みを保障しないレベルや強固な
整合性の確保まで。だが当然パフォーマンスにも影響する。

5. 一貫性
cassandra では可用性の確保のため結果整合性モデルで一貫性の確保を行っている。
　結果整合性とは DNS などに見られる、整合性に一部条件をつける1ような整合性である。
この場合成功した書き込みが必ず最新の状態で読み出せることを約束しない。
　
6. データ構造
Key、Value の組だけではなく、カラム型のデータ構造を持ち、ColumnFamily や、
SuperColumn を使用することで単純な KVS では出来ない複雑なデータの管理も行うこと
が出来る。

1
即時反映ではなく、反映までに時間がかかるなど

5

 ソフトウェアアーキテクチャ
　次にこれらの機能を実現するためのソフトウェアアーキテクチャを説明する。

1. replication
casandra はキーレンジごとにレプリカを持つ。（セカンダリ、ターティアリ・
・・。）
プライマリのレプリカは各ノードが所持しているメタデータ内の token ring により
決定される。
レプリカに関しては決定方法が多く存在しており、以下の様なアルゴリズムで決定さ
れる様である。
・ RackUnaware の場合 ring 内の N-1 ノードにレプリカを行う
・ RackAware の場合違うデータセンタに存在する ring 内のノードにレプリカを
行う
ラック、データセンタの判定に関しては、アドレスの第 3 オクテット、 2 オクテッ
IP 第
トまでが同一であることが条件。このため、VLAN などで NW 構築を行っている場合は判定
にムラが出る可能性はある。

2. Gossip
Gossip とは、ノード間の情報をやり取りすることによって最終的なノードの状態
（JOIN、DEAD、AVAIL など）をクラスタ内のすべてのノードが知ることが出来る様になる
アルゴリズムである。
Cassandra はこの仕組みで結果整合性の確保を行っている。
具体的には、Generation と、Version と呼ばれる単位でノードとデータの鮮度を判断
して、自分より新しい情報をどこに持っているかを近隣のノード経由で徐々に伝播して
いく。

6

概要図

図１：Gossip の概要図

3. Column
・ Column 構造
Cassandra のデータ構造の基本はカラム型になっており、JSON 図示にすると以下の様
に表される。この Column 構造を組み合わせて複雑なデータ構造を持つことも出来る。
（後述）
{
"name": "FirstName",
"value": "Akihiro",
"timestamp": 123456789
}

図 2：Column の JSON 構造

・ SuperColumn　
SuperColumn はソートされた Colume のリストを Value としてもつ特別な Column 構
造である。

7

{
"Key1": { //Key
"CFamily1": { //column family
"SColumn1": { //SuperColumn
//Column list
"data1": {"data1": "Value1", "timestamp":"1234567890"},
"data2": {"data2": "Value2", "timestamp":"1234567890"},
"data3": {"data3": "Value3", "timestamp":"1234567890"}
.
.
(snip)
.
}
}
}
}

図 3：SuperColumn の JSON 構造

・ ColumnFamily
ColumnFamily とは複数の row からなる Column の集合であり、Cassandra でデータを管
理する際には ColumnFamily の作成が必要となる。そして同一の ColumnFamily に属する
データは同一の SSTable（後述）にソートされた状態でおかれることとなる。
ColumnFamily は作成時にデータ型を決定する必要があり、現在は ASCII 、
UTF-8、Long、 UUID (lexical or time)の４種類が用意されている。

8

{
"Key2":{ //Key
"CFamily2":{ //Column Familiy
//Column
"emailAddress":{"name":"emailAddress", "value":"hoge@example.com",
"timestamp":"1234567890"},
"webSite":{"name":"webSite", "value":"http://hoge.example.com",
"timestamp":"1234567890"}
}
}
"Key3":{ //Key
"CFamily2":{ //Column Familiy
//Column
"emailAddress":{"name":"emailAddress", "value":"fuga@example.com",
"timestamp":"1234567890"},
"webSite":{"name":"webSite", "value":"http://fuga.example.com",
"timestamp":"1234567890"}
}
}
}

図 4：ColumnFamily の JSON 構造

4. CommitLog
Cassandra にデータが書き込まれた時は、Commitlog へ書き込みされる。
Commitlog に書かれた物から後述する memtable へとデータが書き込まれていく。
このデータはもし不慮のサーバダウンやネットワークダウンなどで memtable にしか
ないデータが失われないよう、サーバ再起動時などはこのファイルからデータの復旧を
行う。

5. Memtable
Memtable は、CommitLog から書き込まれた Key と Value のペアをメモリに保存してい
る領域。直近で使われている大多数のデータは Memtable に存在することになるが、一定
時間使われていない（ LRU Like？）データに関しては SSTable へと書き出される
（Compaction 処理）。

9

6. SSTable
SSTable（Sorted Strings Table）は Key と Value のペアを Key でソートして格納し
ているファイル。
ファイルの種類は、　　
・ DATA ファイル（Key、Valuue が含まれるファイル：Key でソートされている）
・ INDEX ファイル（Key、と Offset の値が入っているファイル）
・ FILTER ファイル（BloomFilter2のデータが入っているファイル）
の３種類で構成されている。

7. Thrift
Facebook 社でつくられた RPC 通信用のフレームワーク、Cassandra ではクライアン
トからの通信や、ノード間の通信に Thrift を使用している。
今回の検証でも、テスト用のスクリプトは Thrift を使用した python スクリプトで
行っている。

2
bloomfilter はノード間のキーの検索に使用しており、必要以上のトラフィックを流さない実装にするた
めに必要な物である。

10

 ハードウェア要件
　続いて、Cassandra を動かすのに必要なハードウェア要件について説明しておく。
その際の想定 OS に関しては Linux で想定している。
　なお、この条件は構築するシステムによって必要な条件は異なるのであくまで目安とな
る。

1. サーバ数
すべてのノードは同一キャパシティで構築しないとパフォーマンスに影響がでる。
おそらく基本の通信がノード間通信になるので、スペックのギャップが他のノードに
与える負荷が高いことによるボトルネックが発生するのだと想像できる。
スペックアップするのであれば台数を足した方がよい。

2. メモリ
ほとんどのデータは memtable と呼ばれている領域（＝メモリ）に存在している。が、
古いデータに関しては定期的に Compaction 処理でディスク（SSTable）に書き出され
る。それらのデータは OS のバッファキャッシュに保存されている。
ただし、メモリが多いに越したことはないが、理由がない限りは 4GB 以上のメモリは
必要ない。
0.5 で実装された KeyCache や、今回は検証していないが 0.6 で実装されている
ROWCache を使用することでさらにパフォーマンス的に有利となる。

3. CPU
大量のワークロードの場合メモリバウンドの前に CPU バウンドになる。そのため 4 or
8 core 以上の早い CPU が必要。
クラウド等や、仮想サーバだと CPU バウンドが発生する。

4. HDD
基本的には CommitLogDirectory と DataFileDirectories があればいい。
ディスクの使い方は以下の 2 種類。
・コミットログ
・ SSTable(ディスクへの保存)
コミットログは MySQL ならバイナリログと似たような物。書き込みデータの保護、ク
ラッシュ時などの復旧に使用される。コミットログが書き出されるディスクでは容量は
いらないが、書き出し、読み出しは十分に早いディスクで行う。
SSTable は前述したが古いデータなどを保存していくファイルである。定期的な
Compaction 処理で Memtable から SSTable へデータを書き出していき、SSTable への書き

11

出しまで終わった物が CommitLog から削除される。
ディスクスペック的には容量もデータが入る分はもちつつ、早さも Compaction 処理
に影響を及ぼさないレベルで早い物がもとめられる。

メモリへの書き込み
クライアントアクセス
CommitLog
データの書き込み Compact
ion

Memtable SSTable

図 5：データの書き込みの流れ

5. ファイルシステム
ファイルシステムは、SSTable やコミットログなどの単一の大きなファイルが作成さ
れる関係上パフォーマンス的には ext3 などよりも xfs の方がよい。

12

 検証
　ここまでで Cassandra に関しての基本的な説明を終わり、実際の検証で現状の確認を試み
る。

1. 実施環境
実施環境は以下の通り。
機種名自作
台数最大 4 台
CPU Atom D510
Memory 4GB
HDD 250GB 2.5Inch HDD * 1
ディストリビューシ CentOS 5.4
ョン
Partition 構成 /boot – 512MB ext3

swap - 2048MB
/ - 残り ext3
ソフトウェアバージ Cassandra 0.51
ョン
Thrift 0.2.0
JVM jdk1.6.0_18

既に考慮される問題点として、
・ CPU の性能
・ HDD の性能
・ファイルシステムの選択3
が考えられるが、環境が用意できていないためこの辺りを加味した上で検証を行う。

2. インストール
インストールの手順。今回は時間の関係上と、安定版4の最新ということで、Cassandra は
0.5.1 のバイナリを使用している。

3
前述した xfs の方がパフォーマンスがよいと言う話。
4
0.XX で安定版も何もないですが

13

○ソースディレクトリ作成
# mkdir /usr/local/src/cassandra
# cd /usr/local/src/cassandra

○JDK インストール
[JDK の入手方法は割愛]
# ./jdk-6u18-linux-x64.bin
(snip)
Do you agree to the above license terms? [yes or no]
yes
# mv jdk1.6.0_18 /usr/local/jdk1.6.0_18
# ln -s /usr/local/jdk1.6.0_18 /usr/local/java

○Java の環境変数設定
# useradd -m cassandra
# su - cassandra
$ vi /home/cassandra/.bash_profile
(環境変数追加)
# User specific environment and startup programs
JAVA_HOME=/usr/local/java
PATH=$PATH:$HOME/bin:$JAVA_HOME/bin

export PATH JAVA_HOME

$ source /home/cassandra/.bash_profile

14

○Cassandra インストール
# cd /usr/local/src/cassandra
# wget http://ftp.riken.jp/net/apache/incubator/cassandra/0.5.1/apache-cassandra-0.5.1-bin.tar.gz
# tar zxvf apache-cassandra-0.5.1-bin.tar.gz
# mv apache-cassandra-0.5.1 /usr/local/
# ln -s /usr/local/apache-cassandra-0.5.1 /usr/local/apache-cassandra

○DATA ディレクトリ、LOG ディレクトリの作成
# mkdir -p /var/log/cassandra
# mkdir -p /var/lib/cassandra
# chown -R cassandra. cassandra /var/log/cassandra
# chown -R cassandra.cassandra /var/log/cassandra
# chown -R cassandra.cassandra /usr/local/apache-cassandra

○hosts ファイル変更
# vim /etc/hosts
192.168.0.91 cass-test01
192.168.0.99 cass-test02
192.168.0.97 cass-test03
192.168.0.94 cass-test04

○Cassandra 起動テスト
# su - cassandra
$ cd /usr/local/apache-cassandra/bin
$ ./cassandra -f
Listening for transport dt_socket at address: 8888
INFO - Saved Token not found. Using 65403833352419508191139141305783892154
INFO - Starting up server gossip
INFO - Cassandra starting up...
Ctrl+C で停止

15

以上で、起動までの確認がとれた。

3. 設定
設定項目の説明。
一般的に触ると思われる設定を抜粋して説明する。

○クラスタ、データ構造関連の設定

<ClusterName>ClusterName</ClusterName>


<Keyspaces>
<Keyspace Name="KsName1">
<KeysCachedFraction>0.05</KeysCachedFraction>
<ColumnFamily CompareWith="BytesType" Name="CfByte1"/>
<ColumnFamily CompareWith="UTF8Type" Name="CfUTF82"/>
</Keyspace>
</Keyspaces>


<Seeds>
<Seed>cass-test01</Seed>

</Seeds>

○IP,ポート関連の設定

16

<ListenAddress>test-01</ListenAddress>
<StoragePort>7000</StoragePort>
<ControlPort>7001</ControlPort>


<ThriftAddress>0.0.0.0</ThriftAddress>
<ThriftPort>9160</ThriftPort>

○バッファ関連の設定

17

<SlicedBufferSizeInKB>64</SlicedBufferSizeInKB>


<FlushDataBufferSizeInMB>32</FlushDataBufferSizeInMB>
<FlushIndexBufferSizeInMB>8</FlushIndexBufferSizeInMB>


<ColumnIndexSizeInKB>64</ColumnIndexSizeInKB>


<MemtableSizeInMB>64</MemtableSizeInMB>

<MemtableObjectCountInMillions>0.1</MemtableObjectCountInMillions>

<MemtableFlushAfterMinutes>60</MemtableFlushAfterMinutes>


<ConcurrentReads>8</ConcurrentReads>
<ConcurrentWrites>32</ConcurrentWrites>


<CommitLogSync>periodic</CommitLogSync>

<CommitLogSyncPeriodInMS>10000</CommitLogSyncPeriodInMS>

<GCGraceSeconds>864000</GCGraceSeconds>


<BinaryMemtableSizeInMB>256</BinaryMemtableSizeInMB>

18

○今回の設定
<storage-conf.xml.txt> を参照。
基本的には、どれがどのように働くか見るためと、機能検証を行うためまずデフォルト
値メインで設定している。

4. 機能検証
以下の項目について、機能検証を行う。
・クラスタ導入
・データ操作（投入、更新、削除）
・ノード追加（とその後のデータの配置され方について）
・バックアップ/リストア
・監視関連

・クラスタ導入
まず、本番サーバとして起動を行う。
○Cassandra 起動（Daemon 起動）
# su - cassandra
$ vim /usr/local/apache-cassandra/bin/cassandra.in.sh
# ヒープ領域を 3GB へとあげる
$ diff /usr/local/apache-cassandra/bin/cassandra.in.sh.org /usr/local/apache-
cassandra/bin/cassandra.in.sh
45c45
< -Xmx1G
---
> -Xmx3G
$ ./cassandra -p ./cassandra.pid

まず、３台起動したらクラスタが組めているのかを確認。

19

$ ./nodeprobe -host localhost ring
Address Status Load Range Ring
124039723817946554142311632841015584374
192.168.0.97 Up 0 bytes 54726667172133563740938363913892816149 |<--|
192.168.0.99 Up 0 bytes 85116141055809869248935675462381407463 | |
192.168.0.91 Up 0 bytes 124039723817946554142311632841015584374 |-->|

このようにクラスタが組めていることがわかる。

バックアップだが、SSTable のバックアップを JSON 形式で IMPORT/EXPORT するツール
が用意されている。
。

データ操作用に cassandra-cli というコマンドラインツールが存在している。

20

$ $ ./cassandra-cli
Welcome to cassandra CLI.

Type 'help' or '?' for help. Type 'quit' or 'exit' to quit.
cassandra>

cassandra> get KsName1.CfByte1['test807837']
=> (column=testdata1, value=807837, timestamp=1269433560)
Returned 1 results.

# データ取得
cassandra> get KsName1.CfByte1['test807837']
=> (column=testdata1, value=807837, timestamp=1269433560)
Returned 1 results.

# データ書き込み
.cassandra> set KsName1.CfByte1['testtest']['CfByte1'] = '123456'
Value inserted.
cassandra> get KsName1.CfByte1['testtest']
=> (column=CfByte1, value=123456, timestamp=1269587633646)
Returned 1 results.

# データ上書
cassandra> set KsName1.CfByte1['testtest']['CfByte1'] = '1234567'
Value inserted.
cassandra> get KsName1.CfByte1['testtest']
=> (column=CfByte1, value=1234567, timestamp=1269587649878)
Returned 1 results.

・ノード追加（とその後のデータの配置され方について）
クラスタに存在しているサーバの追加も行ってみた。
まず、新しいサーバ 4 台目の storage-conf.xml を以下のように seed の設定に 4 台目
を追加してクラスタに参加させてみた。

21

$ vi ../conf/storage-conf.xml
<Seeds>
</Seeds>

$ ./cassandra -p ./cassandra.pid
INFO - Replaying /var/lib/cassandra/commitlog/CommitLog-1269269853066.log
INFO - Log replay complete
INFO - Saved Token not found. Using 97147856872319332778007596849029295064
INFO - Starting up server gossip

この状態で、クラスタの状態を確認してみると以下のようになっている。
$ ./nodeprobe -host cass-test01 ring
124039723817946554142311632841015584374
192.168.0.97 Down 1.5 GB 54726667172133563740938363913892816149 |<--|
192.168.0.99 Up 767 MB 85116141055809869248935675462381407463 | |
192.168.0.94 Up 1.47 KB 97147856872319332778007596849029295064 | |
192.168.0.91 Up 643.61 MB 124039723817946554142311632841015584374 |-->|

　この結果から、すべてのサーバに対して seed の設定を行わなくとも Gossip 経由での
情報伝達が行われることがわかった。
　追加検証としてその後に 100 万件のデータ追加をしてみてどのような動きをするか
を確認してみた。

22

$ ./nodeprobe -host cass-test01 ring
124039723817946554142311632841015584374
192.168.0.97 Up 1.9 GB 54726667172133563740938363913892816149 |<--|
192.168.0.99 Up 1.02 GB 85116141055809869248935675462381407463 | |
192.168.0.94 Up 120.55 MB 97147856872319332778007596849029295064 | |
192.168.0.91 Up 768.39 MB 124039723817946554142311632841015584374 |-->|

　この結果を受けると、特にサーバを追加したことによりそのサーバに負荷が集中する
ことはないが、今までのデータの再配置の様な物も行われないため、先に追加したサー
バのキャパが先に枯渇する様なことがありうる。

・バックアップ/リストア
SSTable を JSON 形式で IMPORT/EXPORT するツールが用意されている。
。
○バックアップ
# su - cassandra
$ ./sstable2json -f CfByte1-36-Data.json /var/lib/cassandra/data/KsName1/CfByte1-36-Data.db
INFO - Sampling index for /var/lib/cassandra/data/KsName1/CfByte1-36-Data.db
$ cat CfByte1-36-Data.json
{
"test843352": [["746573746461746131", "383433333532", 1269433709, false]],
"test768227": [["746573746461746131", "373638323237", 1269433388, false]],
"test784089": [["746573746461746131", "373834303839", 1269433462, false]],
(snip)
"test851643": [["746573746461746131", "383531363433", 1269433743, false]]
}
$

23

○リストア
$ ./json2sstable -K KsName1 -c CfByte1 CfByte1-36-Data.json
/var/lib/cassandra/data/KsName1/CfByte1-36-Data.db
$

スクリプトなどは書く必要はあるだろうが、定期的にとる事は可能である。
考えうる問題は memtable 上にあるデータについての問題だろうが、noteprobe コマン
ドで明示的に compaction の実行が行えるため、[アクセスの停止(方法は問わない)]-
>[compaction 実行]->[SSTble のバックアップ]-> [アクセス再開]で実行可能である。

・監視関連
現状の状態監視なども nodeprobe コマンドで行える。
リアルタイムの KeyName 事のクエリ数などの情報は、cfstat を使用、各スレッドの状
態遷移の統計を見たい場合は tpstat を使用する。
これらのツールを使用することで監視設定などに利用できると思われる。

24

○cfstat
# su - cassandra
$ ./nodeprobe -host localhost cfstats
Keyspace: system（これは cassandra のシステム領域用の KeySpace）
(snip)
----------------
Keyspace: KsName1
Read Count: 0
Read Latency: NaN ms.
Write Count: 559
Write Latency: 0.038 ms.
Pending Tasks: 0
Column Family: CfByte1
Memtable Columns Count: 307
Memtable Data Size: 12894
Memtable Switch Count: 8
Read Count: 0
Write Count: 307
Pending Tasks: 0

Column Family: CfUTF82
Memtable Columns Count: 308
Memtable Data Size: 21252
Memtable Switch Count: 8
Read Count: 0
Write Count: 309
Pending Tasks: 0

----------------

25

○tpstat
# su - cassandra
$ ./nodeprobe -host localhost tpstats
Pool Name Active Pending Completed
FILEUTILS-DELETE-POOL 0 0 1
MESSAGING-SERVICE-POOL 1 0 4395686
STREAM-STAGE 0 0 0
RESPONSE-STAGE 1 0 4114000
ROW-READ-STAGE 0 0 158
LB-OPERATIONS 0 0 0
COMMITLOG 1 0 1266183
GMFD 0 0 985576
MESSAGE-DESERIALIZER-POOL 0 0 4421666
LB-TARGET 0 0 0
CONSISTENCY-MANAGER 0 0 63
ROW-MUTATION-STAGE 0 0 1245215
MESSAGE-STREAMING-POOL 0 0 0
LOAD-BALANCER-STAGE 0 0 0
FLUSH-SORTER-POOL 0 0 22
MEMTABLE-POST-FLUSHER 0 0 22
COMPACTION-POOL 0 0 33
FLUSH-WRITER-POOL 0 0 22
AE-SERVICE-STAGE 0 0 0
HINTED-HANDOFF-POOL 0 0 80

5. 障害検証
・サーバダウン時のデータロスト
ReplicationFactor が１の場合は、台のサーバがダウンした時点で、
1 データのロスト
がみとめられた。これはレプリケーションの設定が ReplicationFactor/2 + 1 = 1.5 の
データを持つと言うことから、レプリケーションとしてもつデータの個数の整数値部
分がデータの個数であると考えられる。
そこで ReplicationFactor を 2(2/2 + 1 = 2)にあげて再度テストしてみた結果、台
1

26

のサーバダウンでもデータのロストは無くなった。
なお、ReplicationFactor が１の場合でもサーバの再起動により、クラスタに復帰し
た後は正常に読み込むことが出来ていた。

6. 性能検証
　簡易的な性能検証のとして、スクリプトを自作したもので、100 万件のデータの書き
込みを
・単一サーバ
・複数サーバ（２台）
・複数サーバ（３台）
で行うものを作成して、台数でまともなスケールするのかどうかについてまとめてみ
た。

並列数読み込み(min) 書き込み(min)
1 97 m 127 min
2 52 m 28 min
3 17 m 22 min

図 8：実行時間

サーバ負荷に関しても CPU 負荷、IOWAIT も問題になる程度ではなかった。

項目 CPU USER CPU I/O SYS CPU I/O WAIT
値 10 % 10 % 5～10 %

図 9：CPU 負荷平均

27

並列 1

並列 2

並列 3

図 10：CPU 負荷グラフ

が、今回に関してはハードウェア等が実際に使用する物とはかけ離れているため、スケ
ールするという部分の確認にとどめている。

 総評
　まずは Cassandra のサーバのアーキテクチャについての調査から入り、アーキテクチャ
が想定どおり動くのであれば可用性も耐障害性もある。強固なリアルタイム性が求めら
れない一般的な Web アプリケーションであればどこでも使用できる柔軟性もあると言う
印象を再認識した。
パフォーマンステストとしては、十分な物ではなかったが、台数でスケールするという
所と、耐障害性は確保されているのは確認できている。
今回はひとまずと言った形のテストに終始してしまったが、これから調査を進めてい
き使用できそうなところには積極的に使用していきたい。

28

 疑問点
　最後に今回の調査であがった疑問点に関してあげていく。
　これらは今後調査していきたい。

1. 重複した ring
Gossip を使用した情報伝達で下図にしめした構成はどの程度成り立つのか。
もしくはこのような構成をとる必要性があるか、ないか。
　

この場合ringAとringBの情報はやりとりされるのか？
ringA
ringB

図 11：重複した ring の構成
->これはノード追加テスト時に ring の情報が伝達していることは確認できたので構成
自体はおそらく組める。有用かどうか（トラフィック分散などに役立つのか）は要追検
証。

2. Gossip
CL が０の時などの、Network 遅延などの理由で同一 Version が出来た時の状況。
->そもそもできるのか。

3. SSD の使用
読み込みはほぼメモリで、書き込み時の問題だけなのであれば SLC の SSD などを使用し
た構成であればもう少しパフォーマンスが期待できるかもしれない。

4. FS 検討

29

xfs の方がよいと言う結果は出ている様だが、を実装している ZFS、
CoW btrfs5、それ以外
でも ext4、などの FS を使用することでの変化6の検討。

5. HW 検討
今回調査した結果を元に、最適な構成7の HW で大規模な検証（負荷試験、大規模を想定し
た構成検討）を行ってみたい。

6. クライアント側の分散実装
各サーバに同じように負荷がくる状態が理想的な状態なのは間違いない。
しかし見た限り kumofs で言う所の kumo-gateway 的な物はないため、分散実装をクラ
イアント、サーバのレベルで行う必要がある。
他の事例などでどのような実装を行うべきか確認したい。

7. サーバ追加時のデータの再配置
今回の検証ではノード追加時にデータの再配置などは行われていなかった。これだと
ノード追加に対してスケールしなくなるタイミングがでてしまう。
均一にデータを再配置する方法に関して調査する必要がある。

 参考文献
・ The Apache Cassandra Project　内のドキュメント
・ Apache-Cassanra-0.5.1 のソースコード

5
開発の今後が不安ではあるが
6
おそらく遅いと思われる
7
性能的にも、コストパフォーマンス的にも

30

cassandra調査レポート

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à cassandra調査レポート

Similaire à cassandra調査レポート (20)

Plus de Akihiro Kuwano

Plus de Akihiro Kuwano (20)

cassandra調査レポート