# HG changeset patch # User Nobuyasu Oshiro # Date 1392407248 -32400 # Node ID 1d5736ae832f1bd9e6299c1d0d6a837627b560fb # Parent ae161408bc1c80c1ffcaeb38889cacd907bdaf3a Fixed chapter4.tex diff -r ae161408bc1c -r 1d5736ae832f paper/chapter3.tex --- a/paper/chapter3.tex Sat Feb 15 04:37:14 2014 +0900 +++ b/paper/chapter3.tex Sat Feb 15 04:47:28 2014 +0900 @@ -1,11 +1,11 @@ \chapter{分散データベースJungleの設計} -前章では木構造データベースJungleの仕様について述べた. +　前章では木構造データベースJungleの仕様について述べた. 非破壊的木構造によりデータを破壊せずに保持するJungleは, 過去のデータ もみることができる. また, データ編集をした際には, TreeOperationLogとして履歴が残る. -Jungleが分散設計をするにあたり, 参考にしているシステムとして分散バージョン +Jungleで分散設計をするにあたり, 参考にしているシステムとして分散バージョン 管理システムがある. -本章では分散バージョン管理システムとは何かを説明し, Jungleの分散データベース +本章では, 分散バージョン管理システムとは何かを説明し, Jungleの分散データベース の設計について述べる. \section{分散バージョン管理システムによるデータの分散} @@ -14,7 +14,7 @@ % 反対の意味の言葉として集中型バージョン管理システムがある. 分散管理システムでは開発者それぞれがローカルにリポジトリのクローンを持ち, 開発はこのリポジトリを通すことで進められる(図\ref{fig:distributed_repo}). ローカルのリポジトリは独立に存在し, サーバ上にあるリポジトリや他人のリポジトリで行われた変更履歴を取り込みアップデートにかけることができる. -また逆に, ローカルのリポジトリに開発者自身がかけたアップデートを他のリポジトリへと反映させることもできる. +また, 逆にローカルのリポジトリに開発者自身がかけたアップデートを他のリポジトリへと反映させることもできる. 分散管理システムでは, どれかリポジトリが壊れたとしても, 別のリポジトリからクローンを行うことができる. ネットワークに障害が発生しても, ローカルにある編集履歴をネットワーク復旧後に伝えることができる. そのため, 可用性と分断耐性が高いと言える. @@ -30,7 +30,7 @@ \subsection{分散管理システムのAPI} -分散管理システムでは主に次の3つのAPIを使用することで, データの +分散管理システムでは, 主に次の3つのAPIを使用することで, データの 分散を行っている. \begin{itemize} \item commit\\ @@ -40,16 +40,16 @@ \item pull\\ 他のリポジトリの変更履歴をローカルのリポジトリに受け取る. \end{itemize} -commitによりローカルのリポジトリに変更履歴が積み重なり, pushをすることで +　commitによりローカルのリポジトリに変更履歴が積み重なり, pushをすることで 他のリポジトリにローカルで行ったデータ変更を伝える. また, pullに好きなタイミングでデータの更新履歴を受け取ることができる. -分散管理システムはデータ変更の履歴は自由に受け取ることが +分散管理システムはデータ変更の履歴を自由に受け取ることが できるが, その変更履歴をそのまま適応できないときがある. それはお互いが同じデータに対して編集を行っている場合である. この状態を衝突という. この衝突を解決する方法としてMergeがある. -Mergeは衝突を起こしたデータ両方の編集履歴を適応したデータを作ることである. +Mergeは衝突を起こしたデータ両方の編集履歴を適用したデータを作ることである. 分散管理システムではこの衝突を解決する方法が必要になる. \subsection{Mergeによるデータ変更衝突の解決} @@ -62,9 +62,9 @@ このように他のリポジトリにより先にデータ編集が行われており, データの伝搬が素直にできない状態を 衝突という. この衝突を解決する手段が必要である. -分散管理システムでは衝突に対してMergeと呼ばれる作業で解決をはかる. +分散管理システムでは, 衝突に対してMergeと呼ばれる作業で解決をはかる. Mergeは, 相手のリポジトリのデータ編集履歴を受け取り, ローカルにあるリポジトリの編集と合わせる作業である. -データ衝突に対して Jungle はアプリケーションレベルでのMergeを実装して貰うことで解決をはかる. +データ衝突に対して Jungle はアプリケーションレベルでのMergeを実装することで解決をはかる. 以下にMergeが必要な場合とそうでない場合のデータ編集についての図を示す(図\ref{fig:tree_conflict1},\ref{fig:tree_conflict2},\ref{fig:tree_conflict3}). @@ -105,8 +105,9 @@ 分散データーベス Jungle で形成されるネットワークトポロジーはツリー構造を想定している. ツリー構造ならば, データの整合性をとる場合, 一度トップまでデータを伝搬させることで行える. トップもしくはトップまでの間にあるサーバノードでデータ伝搬中に衝突が発生したらMergeを行い, Mergeの結果を改めて伝搬すれば -よいからである. -また, リング型, スター型, メッシュ側ではデータ編集の結果を他サーバノードに流すとき +よいからである(図\ref{fig:topology_tree}). +%また, リング型, スター型, メッシュ側ではデータ編集の結果を他サーバノードに流すとき +また, リング型(図\ref{fig:topology_ring}), メッシュ型(図\ref{fig:topology_mesh})ではデータ編集の結果を他サーバノードに流すとき 流したデータが自分自身にくることにより発生するループに気をつける必要がある. ツリー構造の場合は, サーバノード同士の繋がりで閉路が無い. そのため, 自分自身が行ったデータ編集の履歴を繋がっているノードに送信するだけですむ. diff -r ae161408bc1c -r 1d5736ae832f paper/master_paper.pdf Binary file paper/master_paper.pdf has changed