--- a/paper/chapter3.tex	Sat Feb 01 08:40:05 2014 +0900
+++ b/paper/chapter3.tex	Sat Feb 01 10:23:28 2014 +0900
@@ -1,11 +1,16 @@
 \chapter{分散データベースJungleの設計}
+前章では木構造データベースJungleの仕様について述べた.
+非破壊的木構造によりデータを破壊せずに保持するJungleは, 過去のデータ
+もみることができる.
+また, データ編集をした際には, TreeOperationLogとして履歴が残る.
+これらを踏まえ, 本章ではJungleの分散データベースとしての設計を行う.
 
 \section{分散バージョン管理システムによるデータの分散}
-Jungle は Git や Mercurial といった分散バージョン管理システムの機能を参考に作られている.
-分散バージョン管理システムとは, 多人数によるソフトウェア開発において変更履歴を管理するシステムである.
+Jungleの分散設計はGitやMercurial といった分散バージョン管理システム（以下, 分散管理システム）の機能を参考に作る.
+分散管理システムとは, 多人数によるソフトウェア開発において変更履歴を管理するシステムである.
 % 反対の意味の言葉として集中型バージョン管理システムがある.
 分散管理システムでは開発者それぞれがローカルにリポジトリのクローンを持ち, 開発はこのリポジトリを通すことで進められる(図\ref{fig:distributed_repo}).
-ローカルのリポジトリは独立に損刺し, サーバ上にあるリポジトリや他人のリポジトリで行われた変更履歴を取り込みアップデートにかけることができる.
+ローカルのリポジトリは独立に存在し, サーバ上にあるリポジトリや他人のリポジトリで行われた変更履歴を取り込みアップデートにかけることができる.
 また逆に, ローカルのリポジトリに開発者自身がかけたアップデートを他のリポジトリへと反映させることもできる.
 分散管理システムでは, どれかリポジトリが壊れたとしても, 別のリポジトリからクローンを行うことができる.
 ネットワークに障害が発生しても, ローカルにある編集履歴をネットワーク復旧後に伝えることができる.
@@ -14,14 +19,37 @@
 % 結果整合性の話を先にどっかでしたほうがいいかも
 \begin{figure}[htpb]
   \begin{center}
-    \includegraphics[scale=0.7]{figures/distributed_repository.pdf}
-    \caption{分散バージョン管理システム}
+    \includegraphics[scale=0.6]{figures/distributed_repository.pdf}
+    \caption{分散管理システム}
     \label{fig:distributed_repo}
   \end{center}
 \end{figure}
 
 
-\subsection{マージによるデータ変更衝突の解決}
+\subsection{分散管理システムのAPI}
+分散管理システムでは主に次の3つのAPIを使用することで, データの
+分散を行っている.
+\begin{itemize}
+\item commit\\
+前のバージョンのデータに変更を加えたことをリポジトリに登録する.
+\item push\\
+ローカルのリポジトリで行った変更履歴を別リポジトリへと伝える.
+\item pull\\
+他のリポジトリの変更履歴をローカルにリポジトリで受け取る.
+\end{itemize}
+commitによりローカルのリポジトリに変更履歴が積み重なり, pushをすることで
+他のリポジトリにローカルで行ったデータ変更を伝える.
+また, pullに好きなタイミングでデータの更新履歴を受け取ることができる.
+
+分散管理システムはデータ変更の履歴は自由に受け取ることが
+できるが, その変更履歴をそのまま適応できないときがある.
+それはお互いが同じデータに対して編集を行っている場合である.
+この状態を衝突という.
+この衝突を解決する方法としてMergeがある.
+Mergeは衝突を起こしたデータ両方の編集履歴を適応したデータを作ることである.
+分散管理システムではこの衝突を解決する方法が必要になる.
+
+\subsection{Mergeによるデータ変更衝突の解決}
 分散管理システムでは, データの更新時において衝突が発生する時がある.
 それは, 分散管理システムを参考にしている Jungle においても起こる問題である.
 データの変更を行うときには, 元のデータに編集が加えられている状態かもしれない.
@@ -31,11 +59,11 @@
 このように他のリポジトリにより先にデータ編集が行われており, データの伝搬が素直にできない状態を
 衝突という.
 この衝突を解決する手段が必要である.
-分散管理システムでは衝突に対してマージと呼ばれる作業で解決をはかる.
-マージは, 相手のリポジトリのデータ編集履歴を受け取り, ローカルにあるリポジトリの編集と合わせる作業である.
-データ衝突に対して Jungle はアプリケーションレベルでのマージを実装して貰うことで解決をはかる.
+分散管理システムでは衝突に対してMergeと呼ばれる作業で解決をはかる.
+Mergeは, 相手のリポジトリのデータ編集履歴を受け取り, ローカルにあるリポジトリの編集と合わせる作業である.
+データ衝突に対して Jungle はアプリケーションレベルでのMergeを実装して貰うことで解決をはかる.
 
-以下にマージが必要な場合とそうでない場合のデータ編集についての図を示す(図\ref{fig:tree_conflict1},\ref{fig:tree_conflict2},\ref{fig:tree_conflict3}).
+以下にMergeが必要な場合とそうでない場合のデータ編集についての図を示す(図\ref{fig:tree_conflict1},\ref{fig:tree_conflict2},\ref{fig:tree_conflict3}).
 
 \begin{figure}[htpb]
   \begin{center}
@@ -62,7 +90,8 @@
 \end{figure}
 
 
-\section{ネットワークトポロジーの形成}
+\newpage
+\section{Jungleのネットワークトポロジーの形成}
 分散管理システムを参考に Jungle でもそれぞれのデータベースが独立に
 動くようにしたい.
 そのために必要なことはトポロジーの形成と, サーバノード間でのデータアクセス機構である.
@@ -72,7 +101,7 @@
 \subsection{ツリートポロジーの形成}
 分散データーベス Jungle で形成されるネットワークトポロジーはツリー構造を想定している.
 ツリー構造ならば, データの整合性をとる場合, 一度トップまでデータを伝搬させることで行える.
-トップもしくはトップまでの間にあるサーバノードでデータ伝搬中に衝突が発生したらマージを行い, マージの結果を改めて伝搬すれば
+トップもしくはトップまでの間にあるサーバノードでデータ伝搬中に衝突が発生したらMergeを行い, Mergeの結果を改めて伝搬すれば
 よいからである.
 また, リング型, スター型, メッシュ側ではデータ編集の結果を他サーバノードに流すとき
 流したデータが自分自身にくることにより発生するループに気をつける必要がある.
@@ -158,33 +187,17 @@
 必要である.
 
 
-\subsection{CAP 定理と Jungle}
-ここまでの Jungle の設計を踏まえて, CAP 定理における Jungle の立ち位置を考える.
-分散管理バージョンのように独立したリポジトリもち, それぞれが独自の変更を加えることが
-行えることで一貫性はゆるい.
-だが, ネットワークから切断されてもローカルで行ったデータの変更をネットワーク復旧後で伝搬できる
-ことと, リクエストに対し持っているデータをすぐに返すことができる.
-つまり Jungle は可用性と分断耐性に優れたデータベースを目指している.
-第2章で紹介した既存のデータベースと Jungle との CAP 定理の関係を図\ref{fig:cap_theorem}に示す.
-
-\begin{figure}[htpb]
-  \begin{center}
-    \includegraphics[scale=0.7]{figures/cap_theorem.pdf}
-    \caption{CAP 定理における各データベースの立ち位置}
-    \label{fig:cap_theorem}
-  \end{center}
-\end{figure}
-
-
 
 
 \section{ログによるデータの永続性}
 % TreeOperationLog(ログ)をシリアライズ可能な形にしてデータをおくること
 % シリアライズできる形にしたものをそのままHDに書き出すだけでログの永続性は行える
 Jungle は非破壊でさらにオンメモリにデータを保持するため, 使用するメモリの容量が大きくなる.
-そのため, ハードディスクに書き出し, 一定の区切りで保持している過去のデータをメモリ上から掃除しなければならない.
+だが, オンメモリのままでは電源が落ちた際にデータが失われてしまう.
+ディスクからデータを読み込むことでデータの復旧を行えるようにしたい.
 そこで, ログによるデータの永続性の実装を行う.
-ここでログをどのようなデータ表現でハードディスクへと書きだすかという問題が発生するが, これは Alice を使うことで
+
+ログをどのようなデータ表現でハードディスクへと書きだすかという問題が発生するが, これは Alice を使うことで
 解決している.
 Alice を用いるため MessagePack によりシリアライズ可能な TreeOperationLog ができる.
 このシリアライズ可能な TreeOperationLog をそのままハードディスクへ書き込むこととでログの永続性ができる.