--- a/paper/conclusion.tex	Sat Feb 01 21:06:49 2014 +0900
+++ b/paper/conclusion.tex	Sat Feb 01 22:41:24 2014 +0900
@@ -5,14 +5,14 @@
 スケーラビリティをどのように確保しているかを述べた.
 次に木構造データベースJungleで使われている非破壊的木構造について述べ, 破壊的
 木構造に比べロックが少ないというメリットがあることを論じた.
-Jungleは非破壊的木構造により過去のデータを保持することでMergeを行うことができる.
-そのため, 分散バージョン管理システムを参考に分散設計を行った.
-Jungleの分散設計では当研究室で開発している並列分散フレームワークAliceを用いた.
-Aliceにより自由にトポロジーを組め, 他サーバノードへのデータアクセス機構を手に入れることができた.
+Jungleは非破壊的木構造により過去のデータを保持することでMergeを行うことができる等, 分散管理システム
+と似た分散設計が行えることを述べた.
+また, Jungleの分散設計では当研究室で開発している並列分散フレームワークAliceを用いた.
+Aliceにより自由にトポロジーを組むことができ, 他サーバノードへのデータアクセス機構を手に入れることができた.
 Jungleの分散実装ではデータの編集履歴であるTreeOperationLogをAliceが使用できるようにし, 木の名前と
 いった必要な情報を追加することでデータの分散を行った.
 また, Jungleに元々設計されていたJournalを使ってログをディスクへ書き出すことで永続性の実装を行った
-最後に簡易掲示板を作成, Cassandraとの性能比較を行った.
+最後に簡易掲示板を作成し, Cassandraとの性能比較を行った.
 読み込み, 書き込みの負荷をかける実験を2つ行った.
 1つの実験ではサーバノード1台に対し複数のクライアントから負荷をかけた.
 2つめの実験では複数のクライアントに対し同じ数のサーバノードを用意し数を増やしていき負荷を高めた.
@@ -21,8 +21,8 @@
 
 \section{今後の課題}
 \subsection{データ分割の実装}
-現在Jungleの分散実装は全てのデータを全てのノードで保持している.
-この方法ではメモリの使用量が高いこととネットワーク帯域に対しての
+現在Jungleの分散実装は全てのデータを全てのノードで保持させる実装である.
+だが, この方法ではメモリの使用量が高いこととネットワーク帯域に対しての
 負荷が懸念される.
 そのため, ノード単位で保持するデータを分ける実装が必要になる.
 ノード毎に木構造単位で別々のデータを保持し, 持っていない木のデータ
@@ -37,12 +37,12 @@
 また, アプリケーション毎でデータの保存の仕方といったものも違ってくる.
 そのため, アプリケーションに合ったMergeアルゴリズムを設計しなければならない.
 
-\subsection{分断耐性の実装}
-現在の実装のJungleは, プログラムの起動時にノードと接続を行う.
+\subsection{pull/push機能の実装}
+現在の実装のJungleは, プログラムの起動時に複数ノードが接続をしトポロジーを形成する.
 プログラムの途中で接続がきれるとトポロジーがくずれたままになる.
-接続がきれたJungleは単独では稼働し続けるが, 復帰を行えるようにしたい.
+接続がきれたJungleは単独では稼働し続けるが, トポロジーへの復帰を行えるようにしたい.
 そのためにはトポロジーに割り当てられた際に他ノードから自分の持っているデータとの
-差分のデータを流してもらうといった機能が必要になってくる.
+差分のデータを流してもらうといった分散管理システムにおけるpull/push APIの機能が必要になってくる.
 
 \subsection{過去のデータの掃除について}
 Jungleは非破壊でデータを保持し続けるため, メモリの使用量が大きい.