# HG changeset patch # User Nobuyasu Oshiro # Date 1390829042 -32400 # Node ID 04af243ddd7c71cdce6d56f1ff941395fd256245 # Parent 9eb676914f1de11a142eac5d4aa6387fb48765e6 Modified routing diff -r 9eb676914f1d -r 04af243ddd7c paper/chapter2.tex --- a/paper/chapter2.tex Mon Jan 27 19:53:12 2014 +0900 +++ b/paper/chapter2.tex Mon Jan 27 22:24:02 2014 +0900 @@ -231,18 +231,30 @@ \newpage -\section{データ分散の設計} - +\section{ネットワークトポロジーの形成とデータ分散の設計} +分散管理システムを参考に Jungle でもそれぞれのデータベースが独立に +動くようにしたい. +そのために必要なことはトポロジーの形成と, サーバノード間でのデータアクセス機構である. +また, データ分散のために形成したトポロジー上で扱うデータを決めなければならない. -\subsection{} - +\subsection{ツリートポロジーの形成} +分散データーベス Jungle で形成されるネットワークトポロジーはツリー構造を想定している. +ツリー構造ならば, データの整合性をとる場合, 一度トップまでデータを伝搬させることで行える. +トップもしくはトップまででデータ編集の衝突が発生したらマージを行い, マージの結果を改めて伝搬すれば +よいからである. +また, リング型, スター型, メッシュ側ではデータ編集の結果を他サーバノードに流すとき +流したデータが自分自身にくることにより発生するループに気をつける必要がある. +ツリー構造の場合は, サーバノード同士の繋がりで閉路が無い. +そのため, 自分自身が行ったデータ編集の履歴を繋がっているノードに送信するだけですむ. +このルーティングの方式はスプリットホライズンと呼ばれる. \section{データの永続性} - - \section{CAP 定理と Jungle} +ここまでの Jungle の設計を踏まえて, CAP 定理における Jungle の立ち位置を考える. +Jungle は分散バージョン管理システムを参考にした分散設計を行っている. +全てのデータベース \begin{figure}[htpb] \begin{center} diff -r 9eb676914f1d -r 04af243ddd7c paper/chapter3.tex --- a/paper/chapter3.tex Mon Jan 27 19:53:12 2014 +0900 +++ b/paper/chapter3.tex Mon Jan 27 22:24:02 2014 +0900 @@ -1,6 +1,6 @@ \chapter{Jungleの分散実装} -\section{TreeOperationLogを用いての分散データベースの実装} +\section{TreeOperationLogを用いての分散実装} Jungle でデータ扱うと TreeOperationLog として残ることは述べた. この TreeOperationLog を他のサーバへと送り, Jungle の編集を行って 貰うことでデータの分散を行うことができる. diff -r 9eb676914f1d -r 04af243ddd7c paper/figures/read_bench.pdf Binary file paper/figures/read_bench.pdf has changed diff -r 9eb676914f1d -r 04af243ddd7c paper/figures/write_bench.pdf Binary file paper/figures/write_bench.pdf has changed diff -r 9eb676914f1d -r 04af243ddd7c paper/master_paper.pdf Binary file paper/master_paper.pdf has changed