\chapter{結論} \label{chapter:conclusion}

\section{まとめ}
本研究では, まず初めにRDBとNoSQLの説明を行い, 既存のNoSQLであるCassandra, MongoDB, Neo4jが
スケーラビリティをどのように確保しているかを述べた.
次に木構造データベースJungleで使われている非破壊的木構造について述べ, 破壊的
木構造に比べロックが少ないというメリットがあることを論じた.
Jungleは非破壊的木構造により過去のデータを保持することでMergeを行うことができる等, 分散管理システム
と似た分散設計が行えることを述べた.
また, Jungleの分散設計では当研究室で開発している並列分散フレームワークAliceを用いた.
Aliceにより自由にトポロジーを組むことができ, 他サーバノードへのデータアクセス機構を手に入れることができた.
Jungleの分散実装ではデータの編集履歴であるTreeOperationLogをAliceが使用できるようにし, 木の名前と
いった必要な情報を追加することでデータの分散を行った.
また, Jungleに元々設計されていたJournalを使ってログをディスクへ書き出すことで永続性の実装を行った
最後に簡易掲示板を作成し, Cassandraとの性能比較を行った.
読み込み, 書き込みの負荷をかける実験を2つ行った.
1つの実験ではサーバノード1台に対し複数のクライアントから負荷をかけた.
2つめの実験では複数のクライアントに対し同じ数のサーバノードを用意し数を増やしていき負荷を高めた.
どちらの実験もJungleがCassandraよりも良い結果を示すことを確認した.


\section{今後の課題}


\subsection{pull/push方式による分断耐性の実装}
現在の実装のJungleは, プログラムの起動時に複数ノードが接続をしトポロジーを形成する.
プログラムの途中で接続がきれるとトポロジーがくずれたままになる.
接続がきれたJungleは単独では稼働し続けるが, トポロジーへの復帰を行えるようにしたい.
そのためには、今の実装で行っている非同期でログを送信する方法とは別に同期をとり差分のデータを伝搬する方法を
実装する必要がある。
これは, 分散管理システムにおけるpull/push APIの機能にあたる.


\if0 % push/pullの話と内容がかぶる？
\subsection{データ分割の実装}
現在Jungleの分散実装は全てのデータを全てのノードで保持させる実装である.
だが, この方法ではメモリの使用量が高いこととネットワーク帯域に対しての
負荷が懸念される.
そのため, ノード単位で保持するデータを分ける実装が必要になる.
ノード毎に木構造単位で別々のデータを保持し, 持っていない木のデータ
に対して要求がくると他からとってきて返すといった機能が必要になる.
\fi


\subsection{Mergerアルゴリズムの設計}
JungleはMergeを使うことでデータ衝突の問題を解決をはかるが, この
Mergeはアプリケーション毎に考えなければならない.
今回, JungleにおけるMergeの例として掲示板プログラムにおけるMergeについて述べた.
だが掲示板のような単純なMergeですむアプリケーションは少ない.
また, アプリケーション毎でデータの保存の仕方といったものも違ってくる.
そのため, アプリケーションに合ったMergeアルゴリズムを設計しなければならない.



\subsection{過去のデータの掃除について}
Jungleは非破壊でデータを保持し続けるため, メモリの使用量が大きい.
ある程度の単位で過去のデータの掃除を行いたい.
今回分散実装を行ったことで, 多数のノードでデータが保持され, その内の数台が
ディスクへ書き出すといったことも可能になった.
だが, Mergeの問題含め, どのタイミングで過去のデータを掃除すべきかは自明ではない.
分断耐性の実装の問題とも関わってくるが, どのデータがどれだけ複製して持っているといった
情報も扱う必要がでてくるかもしれない.



%\subsection{Treeのバランスの問題}