分散データベースJungleに関する研究
琉球大学 大城信康
14 Jan 2013
研究の背景と目的
- スマートフォンやタブレット端末の普及により、大量のデータを扱うウェブサービスが現れてきている。
- しかしそれに伴い、サーバサイド側への負荷も増大しウェブサービスがダウンする事態が出てきている。
- そのため、スケーラビリティはウェブサービスにおいて重要な性質の1つとなっている。
- スケーラビリティとは、ある複数のノードから構成される分散ソフトウェアがあるとき、その分散ソフトウェアに対して単純にノード を追加するだけで性能を線形に上昇させることができる性質である
- スケーラビリティのあるプログラムについてアーキテクチャの設計から行った
研究の背景と目的
- 当研究室では非破壊的木構造を用いたデータベースである Jungle を開発している
- 非破壊的木構造とは、データの編集の際に一度木構造として保存したデータには触れず、新しく木構造を作成してデータの編集を行うこと
- Jungle は分散データベースとして設計・実装されているが、分断耐性や永続性といった部分の実装がまだ 行われていない
- 本研究では、Jungle を用いてスケーラビリティをもつアーキテクチャの追求を行う
今週の作業
- 論文の執筆
- ベンチマーク測定環境の構築
ベンチマーク測定環境の構築
- csクラスタ(VM)上で掲示板プログラムを走らせ、ベンチマークをとる
- Jungle と Cassandra 両方を走らせる環境の構築を行った
- Cassandra でConsistencyLevelをいじってもデータを伝搬してくれない
- Jungle の分散結果が良くならない。圧倒的に遅い。Cassandra の結果の2倍3倍遅くなる
問題が発生
問題解決
- Cassandra はConsistencyLevelとは別にReplication factorというレプリケーション(複製)をとるノードの数を指定する項目がある
- Cassandra のConsistencyLevelはこのReplication factorの数に対して行われる
- Replication factorをNとした場合、ConsistencyLevelをALLにするとこのNの数だけノードに書き込まれるのをまつ
- Replication factorをノードの全体の数に合わせてあげるとよい
- Replication factorの設定はv1.1くらいまでは設定ファイルでできるが、v1.2からはキースペース生成時に設定するか ./bin/cassandra-cli を使ってCassandraのデータにアクセスして変更する必要がある
- Jungle の結果が悪い原因
- Javaのメモリの量を増やす設定をいれることで解決
単体・複数ノードへの負荷
- クライアント数最大12台。各クライアント5000回のリクエストを出す
ベンチマーク改良
- Jungleの結果をbldsvで起動した時に近い結果になることが確認できた
- Cassandra も Jungle のグラフも横ばいになっている。クライアント側からの負荷が足りない。
- Cassandra の ConsystencyLevel をいじっても結果が変わらないのも負荷が足りないから？
- クライアント側はKVMで動かしていて現在12台しか無い
- 負荷をかけるプログラムをforkすることでプロセスを増やして負荷を増やすよう改良する必要がある
- 論文書こう
次の課題
今後の作業
- 修論作成
- ベンチマークプログラム作成