comparison paper/conclusion.tex @ 56:1d07365c60ff

Writed conclstion
author Nobuyasu Oshiro <dimolto@cr.ie.u-ryukyu.ac.jp>
date Fri, 31 Jan 2014 21:37:40 +0900
parents 67880a2ca650
children d770a2b534b3
comparison
equal deleted inserted replaced
55:cff4aee4fcf6 56:1d07365c60ff
1 \chapter{結論} \label{chapter:conclusion} 1 \chapter{結論} \label{chapter:conclusion}
2 2
3 \section{まとめ} 3 \section{まとめ}
4 本研究では, まず初めにRDBとNoSQLの説明を行い, 既存のNoSQLであるCassandra, MongoDB, Neo4jが
5 スケーラビリティをどのように確保しているかを述べた.
6 次に木構造データベースJungleで使われている非破壊的木構造について述べ, 破壊的
7 木構造に比べロックが少ないというメリットがあることを論じた.
8 Jungleは非破壊的木構造により過去のデータを保持することでMergeを行うことができる.
9 そのため, 分散バージョン管理システムを参考に分散設計を行った.
10 Jungleの分散設計では当研究室で開発している並列分散フレームワークAliceを用いた.
11 Aliceにより自由にトポロジーを組め, 他サーバノードへのデータアクセス機構を手に入れることができた.
12 Jungleの分散実装ではデータの編集履歴であるTreeOperationLogをAliceが使用できるようにし, 木の名前と
13 いった必要な情報を追加することでデータの分散を行った.
14 最後に簡易掲示板を作成, Cassandraとの性能比較を行った.
15 読み込み, 書き込みの負荷をかける実験を2つ行った.
16 1つの実験ではサーバノード1台に対し複数のクライアントから負荷をかけた.
17 2つめの実験では複数のクライアントに対し同じ数のサーバノードを用意し数を増やしていき負荷を高めた.
18 どちらの実験もJungleがCassandraよりも良い結果を示すことを確認した.
19
4 20
5 \section{今後の課題} 21 \section{今後の課題}
22 \subsection{データ分割の実装}
23 現在Jungleの分散実装は全てのデータを全てのノードで保持している.
24 この方法ではメモリの使用量が高いこととネットワーク帯域に対しての
25 負荷が懸念される.
26 そのため, ノード単位で保持するデータを分ける実装が必要になる.
27 ノード毎に木構造単位で別々のデータを保持し, 持っていない木のデータ
28 に対して要求がくると他からとってきて返すといった機能が必要になる.
6 29
7 \subsection{データ分割の実装}
8 \subsection{Mergerアルゴリズムの設計} 30 \subsection{Mergerアルゴリズムの設計}
9 \subsection{Compactionの実装・分断耐性の実装} 31 JungleはMergeを使うことでデータ衝突の問題を解決をはかるが, この
32 Mergeはアプリケーション毎に考えなければならない.
33 今回, JungleにおけるMergeの例として掲示板プログラムにおけるMergeについて述べた.
34 だが掲示板のような単純なMergeですむアプリケーションは少ない.
35 また, アプリケーション毎でデータの保存の仕方といったものも違ってくる.
36 そのため, アプリケーションに合ったMergeアルゴリズムを設計しなければならない.
37
38 \subsection{分断耐性の実装}
39 現在の実装のJungleは, プログラムの起動時にノードと接続を行う.
40 プログラムの途中で接続がきれるとトポロジーがくずれたままになる.
41 接続がきれたJungleは単独では稼働し続けるが, 復帰を行えるようにしたい.
42 そのためにはトポロジーに割り当てられた際に他ノードから自分の持っているデータとの
43 差分のデータを流してもらうといった機能が必要になってくる.
10 44
11 45
12 %\subsection{Treeのバランスの問題} 46 %\subsection{Treeのバランスの問題}