--- a/paper/chapter1.tex	Tue Mar 04 00:25:04 2014 +0900
+++ b/paper/chapter1.tex	Wed Mar 05 19:54:34 2014 +0900
@@ -36,11 +36,11 @@
 \section{CAP 定理}
 分散データシステムにおいては, 次の3つを同時に保証することはできない.
 \begin{itemize}
-\item 一貫性(Consistency)
+\item{一貫性(Consistency)}\\
 全てのノードはクエリが同じならば同じデータを返す.
-\item 可用性(Availability)
+\item{可用性(Availability)}\\
 あるノードに障害が発生しても, 機能しているノードにより常にデータの読み書きが行える. 
-\item 分断耐性(Partition-tolerance)
+\item{分断耐性(Partition-tolerance)}\\
 ネットワーク障害によりノードの接続が切れてもデータベースは機能し続けることができる.
 \end{itemize}
 　これは CAP 定理\cite{cap}と呼ばれる.
@@ -117,7 +117,7 @@
 グラフはノードとRelationshipにより表され, それぞれがプロパティを持つことができる.
 Relationshipはグラフでいうところのエッジにあたる.
 ノードからRelationshipを辿り, 各プロパティをみることでデータの取得を行うことができる.
-通常データベースでは, データの取り出しに価の結合や条件の判定を行う.
+通常データベースでは, データの取り出しに値の結合や条件の判定を行う.
 しかし, グラフデータベースグラフはどれだけデータが大きくなろうがノードからノードへの移動は1ステップですむ.
 そのため, どれだけデータが大きくなろうと, データが小さい時と同じ計算量でデータの取得が行える.
 
@@ -169,14 +169,14 @@
 そうでないときで読み込みと書き込みの速度をあげることができる.
 一貫性が重要なデータに関してはQUORUMにより書き込み読み込みを行うことで常に最新のデータを取得することができる.
 多少データが古くてもよい場合はONEなどを使用することでレスポンスを早くすることができる.
-ConsisutencyLevel QUORUMの時のデータ書き込みと読み込みについて図\ref{fig:quorum_write}と図\ref{fig:quorum_read}に示す.
-Consistencyハッシング, Replication factorとConsistencyレベルの設定により Cassandra は
+Consistency Level QUORUMの時のデータ書き込みと読み込みについて図\ref{fig:quorum_write}と図\ref{fig:quorum_read}に示す.
+Consistencyハッシング, Replication factorとConsistency Levelの設定により Cassandra は
 高い可用性と分断耐性を持つ.
 
 \begin{figure}[htpb]
   \begin{center}
     \includegraphics[scale=0.6]{figures/cassandra_quorum_write.pdf}
-    \caption{ConsisteyncyLevel QUORUMによる書き込み}
+    \caption{Consisteyncy Level QUORUMによる書き込み}
     \label{fig:quorum_write}
   \end{center}
 \end{figure}
@@ -184,7 +184,7 @@
 \begin{figure}[htpb]
   \begin{center}
     \includegraphics[scale=0.6]{figures/cassandra_quorum_read.pdf}
-    \caption{ConsisteyncyLevel QUORUMによる読み込み}
+    \caption{Consisteyncy Level QUORUMによる読み込み}
     \label{fig:quorum_read}
   \end{center}
 \end{figure}

--- a/paper/chapter2.tex	Tue Mar 04 00:25:04 2014 +0900
+++ b/paper/chapter2.tex	Wed Mar 05 19:54:34 2014 +0900
@@ -79,7 +79,7 @@
 
 \newpage
 
-非破壊的木構造においてデータのロックが必要となる部分は, 木のコピーを作終りえた後に
+非破壊的木構造においてデータのロックが必要となる部分は, 木のコピーを作り終えた後に
 ルートノードを更新するときだけである.
 データ編集を行っている間ロックが必要な破壊的木構造に比べ, 編集中においてもデータの読み込みが
 可能である(図\ref{fig:nondestractive_merit}).
@@ -98,7 +98,7 @@
 \section{Jungle におけるデータへのアクセス}
 Jungleにおいてのデータアクセス手段について述べる.
 JungleではそれぞれのNodeがattributeを保持する.
-attributeはKey-Valueによりデータを保持される.
+attributeはKey-Valueによりデータを保持する.
 KeyはString型でValueはByteBufferを使用している.
 Jungleでデータへのアクセスは, このNodeへのアクセスをさす.
 Node へのアクセスは, 木の名前と Node を指すパスにより行える.
@@ -163,7 +163,7 @@
 [PUT_ATTRIBUTE:<-1,0>:key:mes,value:hello]
 [PUT_ATTRIBUTE:<-1,0>:key:timestamp,value:0]
 \end{lstlisting}
-　このログはルートノードに対し子ノードを追加し, 追加した子ノードに attribute を3つ追加する際に図れるログである(図\ref{fig:treeoperationlog}).
+　このログはルートノードに対し子ノードを追加し, 追加した子ノードに attribute を3つ追加する際に出力されるログである(図\ref{fig:treeoperationlog}).
 
 大文字の英字は実行した NodeOperation の種類を表す.
 \verb|<>| により囲まれている数字は NodePath を示す.

--- a/paper/chapter3.tex	Tue Mar 04 00:25:04 2014 +0900
+++ b/paper/chapter3.tex	Wed Mar 05 19:54:34 2014 +0900
@@ -45,7 +45,7 @@
 また, pullに好きなタイミングでデータの更新履歴を受け取ることができる.
 
 分散管理システムはデータ変更の履歴を自由に受け取ることが
-できるが, その変更履歴をそのまま適応できないときがある.
+できるが, その変更履歴をそのまま適用できないときがある.
 それはお互いが同じデータに対して編集を行っている場合である.
 この状態を衝突という.
 この衝突を解決する方法としてMergeがある.
@@ -200,7 +200,7 @@
 ディスクからデータを読み込むことでデータの復旧を行えるようにしたい.
 そこで, ログによるデータの永続性の実装を行う.
 
-Jungleの永続性実装の余地としてJournalという機能が元々用意されている.
+Jungleの永続性実装の余地としてJournalという機能が用意されている.
 このJournalにはディスクへ書き出すためのクラスとしてWriterが用意されている.
 Jungleはデータの編集が完了した際にこのWriterクラスのwrite関数を呼び出すようになっている.
 
@@ -208,7 +208,7 @@
 このとき, ログをどのようなデータ表現でハードディスクへと書きだすかという問題が発生するが, これは Alice を使うことで
 解決している.
 Aliceを用いるためMessagePackによりシリアライズ可能な TreeOperationLog ができる.
-このシリアライズ可能な TreeOperationLog をそのままハードディスクへ書き込むこととでログの永続性ができる.
+このシリアライズ可能な TreeOperationLog をそのままハードディスクへ書き込むこととで永続性を持たせることができる.
 
 
 
@@ -222,5 +222,3 @@
 
 
 
-
-

--- a/paper/chapter4.tex	Tue Mar 04 00:25:04 2014 +0900
+++ b/paper/chapter4.tex	Wed Mar 05 19:54:34 2014 +0900
@@ -54,7 +54,7 @@
 に記述している通りにサーバノード同士が接続を行うよう指示をだす.
 
 トポロジーマネージャーは接続要求先を聞いてくるサーバノードに対して名前を割り振り, 接続相手を伝える.
-dot ファイル\ref{src:alice_dot}により形成されるトポロジーを図\ref{fig:tree_topology}に示す.
+ソースコード\ref{src:alice_dot}のdotファイルにより形成されるトポロジーを図\ref{fig:tree_topology}に示す.
 
 
 \begin{figure}[htpb]
@@ -96,12 +96,12 @@
 \section{Alice を用いての分散実装}
 Aliceのポロジー形成と他のサーバのデータへのアクセスする機構を用いるためには, Aliceが
 提供するプログラミングスタイルに沿わなければならない.
-それはDataSegment(データ)とCodeSegment(タスク)によるプログラムである.
+それはDataSegmentとCodeSegmentによるプログラムである.
 ここではまず, DataSegmentとCodeSegmentによるプログラムの方法について説明し, 他サーバとの
 通信部分の実装について述べる.
 
 \subsection{Alice によるプログラミング}
-AliceはDataSegment（データ）とCodeSegment（タスク）単位でプログラミングを行うことを述べた.
+AliceはDataSegment（データ）とCodeSegment（タスク）単位でプログラミングを行う.
 CodeSegmentには計算に必要なDataSegmentが登録される.
 そしてDataSegmentが準備され次第CodeSegmentによる計算が実行される.
 DataSegmentの取得は文字列のキーを使うことで行える.
@@ -110,11 +110,11 @@
 \begin{lstlisting}[frame=lrbt,label=src:cs_sample,caption=CodeSegmentの実行,numbers=left]
 public class TestCodeSegment extends CodeSegment {
   public Receiver arg1 = ids.create(CommandType.TAKE);
-  
+ 
   public TestCodeSegment() { }
 
   public void run() {
-    int count = ds.asInteger();
+    int count = arg1.asInteger();
     count++;
     System.out.println("count = "+count);
     if(c > 10) { exit(0); }
@@ -130,7 +130,7 @@
   }
 }
 \end{lstlisting}
-コードの説明を行う.
+　ソースコード\ref{src:cs_sample}の説明を行う.
 このプログラムは, 数字を1から10まで出力を行い終了するプログラムである.
 17行目から19行目の処理が最初に行われる.
 まずTestCodeSegmentというCodeSegmentのインスタンスcsを生成する.
@@ -145,8 +145,8 @@
 上記のコード19行目ではputにより"count"をキーとして数値の0を登録している.
 putがされるとcsの計算が始まり別スレッドにより8行目からの処理が行われる.
 
-putによりキー"count"に登録された数値0はReceiverであるdsを使って取ることができる.
-7行目から13行目では\verb|ds.asInteger()|により, "count"に登録したデータの中身を受け取りインクリメントし出力する.
+putによりキー"count"に登録された数値0はReceiverであるarg1を使って取ることができる.
+7行目から13行目では\verb|arg1.asInteger()|により, "count"に登録したデータの中身を受け取りインクリメントし出力する.
 そして, 最後には\verb|ods.put|を行っている.
 新たなTestCodeSegmentも生成しており, これはインクリメントされた"count"がputされることで実行される.
 この一連の処理を"count"の数値が10以上になるまで行う.
@@ -215,7 +215,7 @@
 }
 \end{lstlisting}
 　上記のStudentクラスはプリミティブ型しか保持していない.
-そのためシリアライズが可能である
+そのためシリアライズが可能である.
 また, 次のようなクラスもシリアライズ可能な型となる(ソースコード\ref{src:msgpack2}).
 \begin{lstlisting}[frame=lrbt,label=src:msgpack2,caption=MessagePackによりシリアライズ可能なクラス2,numbers=left]
 import org.msgpack.annotation.Message
@@ -227,11 +227,11 @@
 \end{lstlisting}
 　この場合, フィールドはプリミティブな型でないStudentクラスのフィールドを保持している.
 しかし, Studentクラスはシリアライズ可能な形で作成しているため, クラスのフィールドとして
-保持しても問題はない.
+保持しても問題ない.
 
 これらの制約にそった形で作成しDataSegmentにネットワークを介してクラスのインスタンス
 をputすることができる.
-DataSegmentから受け取ったデータはそのままではシリアライズされたものため, 一度手元で
+DataSegmentから受け取ったデータはそのままではシリアライズされたものなため, 一度手元で
 元のクラスにコンバートすることで扱う.
 例として, AliceにおけるStudenクラスのコンバートを次に示す(ソースコード\ref{src:msgpack1}).
 \begin{lstlisting}[frame=lrbt,label=src:msgpack3,caption=DataSegment,numbers=left]
@@ -271,7 +271,7 @@
 % 木がなければそのばでつくるようにした
 
 \subsection{NetworkTreeOperationLogの実装}
-NetworkTreeOperationLogの実装の一部を以下（図\ref{src:netlog}）に示す.
+NetworkTreeOperationLogの実装の一部を以下（ソースコード\ref{src:netlog}）に示す.
 \begin{lstlisting}[frame=lrbt,label=src:netlog,caption=NetworkTreeOperationが持つフィールド,numbers=left]
 @Message
 public class NetworkTreeOperationLog implements TreeOperationLog
@@ -304,7 +304,7 @@
 \end{lstlisting}
 
 LogPutCodeSegmentの実装は次のようになっている(ソースコード\ref{src:logputcs}).
-\begin{lstlisting}[frame=lrbt,label=src:logputcs,caption=putを行うためだけのCodeSegmentの用意,numbers=left]
+\begin{lstlisting}[frame=lrbt,label=src:logputcs,caption=putを行うためのCodeSegmentの用意,numbers=left]
 public class LogPutCodeSegment extends CodeSegment{
   NetworkTreeOperationLog log;
   public LogPutCodeSegment(NetworkTreeOperationLog _log) {
@@ -316,7 +316,7 @@
   }
 }
 \end{lstlisting}
-　上で述べた問題は, ベンチマークテストなど, 大量の負荷をかけたさいに発生する.
+　上で述べた問題は, ベンチマークテストなど, 大量の負荷をかけた際に発生する.
 負荷とはJungleのデータに変更が加わることである.
 多数のデータの変更により大量のログが生成される.
 そのため, \verb|ods.put|によりDataSegmentの"log"にアクセスが集中してしまい, レスポンスが
@@ -349,7 +349,7 @@
   }
   :
 \end{lstlisting}
- 12行目の\verb|ods.put(node, log.key, log.getVal())|が他サーバノードへデータを送る部分になる.
+　12行目の\verb|ods.put(node, log.key, log.getVal())|が他サーバノードへデータを送る部分になる.
 変数logにはNetworTreeOperationLogが入っている.
 変数listには"\_CLIST"により得られたデータが入っている.
 それは文字列のListとなっている.
@@ -362,12 +362,13 @@
 
 \subsection{ログの受信とデータ反映}
 次は受け取ったログからデータの編集を行う部分の実装を行う.
-Jungleはのデータを変更する手段として木構造データ毎にTreeEditorクラスが提供される.
+Jungleはデータを変更する手段として木構造データ毎にTreeEditorクラスを提供している.
 このTreeEditorを使用し, ログに入っているTreeOperationを1つ1つ取り出し同じ編集を行わせる.
 例えば次のようになる(ソースコード\ref{src:data_edit}).
 \begin{lstlisting}[frame=lrbt,label=src:data_edit,caption=ログを受け取ってのデータの反映,numbers=left]
 // Receiver log <- "log"キーから取得できるデータが入っている
 // Jungle jugnle
+// Either<Error,JungleTreeEditor> either
 NetworkTreeOperationLog netLog = log.asClass(NetworkTreeOperationLog.class);
 String treeName = netLog.getTreeName();
 JungleTree tree = jungle.getTreeByName(treeName);
@@ -382,7 +383,7 @@
   editor = either.b();
 }
 \end{lstlisting}
-　7行目で取り出されたTreeOperationからさらにNodePathとNodeOperationを取り出しているのが8行目と9行目になる.
+　8行目で取り出されたTreeOperationからさらにNodePathとNodeOperationを取り出しているのが9行目と10行目になる.
 最後にedit関数にTreeEditorとNodePath, それとNodeOpeartionを引き渡している.
 edit関数は次のようになる(ソースコード\ref{src:data_edit2}).
 \begin{lstlisting}[frame=lrbt,label=src:data_edit2,caption=edit関数の実装,numbers=left]
@@ -454,8 +455,8 @@
 
 ログの書き出しを行いたいときはこのPersistentChangeListWriterを設定することで行えるようになった.
 これにより木の編集が行われるたびにNetworkTreeOperationLogが書き込まれていく.
-読み込みたいときはMessagePackを使ってディスクから読み込み, データ分散実装と同じの方法で木の編集を行っていく
-ことができる(ソースコード\ref{src:data_edit}, \ref{src:data_edit2}).
+読み込みたいときはMessagePackを使ってディスクから読み込み, データ分散実装と同じ方法で木の編集を行っていく
+ことができる.
 
 
 \newpage
@@ -506,7 +507,7 @@
 \subsection{掲示板プログラムにおけるMerge}
 
 図\ref{fig:merge_imp2}の server node0 の木の状態にするのが理想である.
-掲示板のへの書き込みの表示は, 書き込みされた時間が早い順に表示されるようにしたい.
+掲示板への書き込みの表示は, 書き込みされた時間が早い順に表示されるようにしたい.
 これを timestamp を利用することで行う.
 他サーバノードから来たデータに関しては, timestamp を参照し, 次に自分の保持している
 木の子ノードの timestamp と比べていくことでデータの追加する場所を決める.

--- a/paper/chapter5.tex	Tue Mar 04 00:25:04 2014 +0900
+++ b/paper/chapter5.tex	Wed Mar 05 19:54:34 2014 +0900
@@ -2,10 +2,10 @@
 　前章ではJungleにおける分散データベースの詳細な実装について述べた.
 本章では実装を行ったJungleに対してCassandraとの性能比較を行い評価をする.
 性能比較の為に簡易な掲示板プログラムをJungleとCassandra それぞれに作成した.
-複数のノードに繋がっている状態においても性能を測りたいため, 学科が提供する
+サーバ単体での起動複数のノードに繋がっている状態においても性能を測りたいため, 学科が提供する
 VMWareの並列環境を利用する. また, 我々の研究室が利用しているブレードサーバ
 上で動いているKVMもクライアントとして利用する\cite{shoshi:2011b}.
-Jungleは永続性はなく分散だけ実装で測定を行っている.
+Jungleは永続性はなく分散だけの実装で測定を行っている.
 
 \section{実験方法}
 実験は同じ機能を提供している簡易掲示板プログラムをJungleとCassandraそれぞれで
@@ -74,9 +74,7 @@
 \subsection{実験環境}
 
 \subsubsection{サーバノードとクライアントを実行させるサーバの仕様}
-使用するVMWareとKVMのクラスタの使用を以下に示す.
-クラスタは仕様を表\ref{tab:cluster_spec_vmware}と表\ref{tab:cluster_spec_kvm}に示す.
-
+使用するVMWareとKVMのクラスタの仕様を表\ref{tab:cluster_spec_vmware}, 表\ref{tab:cluster_spec_kvm}に示す.
 \begin{table}[!htbp]
 \caption{掲示板プログラムを実行させるVMWareクラスタの仕様（クライアントにも利用）}
 \label{tab:cluster_spec_vmware}
@@ -187,8 +185,8 @@
 
 \subsection{実験結果1の考察}
 読み込み, 書き込みともにJungleのほうが良い結果となっている.
-書き込みの差が大きく開いていることに関しては, Cassandraはディスクへと書きだすとき
-もあるのも原因の1つと考えられる.
+書き込みの差が大きく開いていることに関しては, Cassandraはディスクへと書きだしを行う
+ことも原因の1つと考えられる.
 Jungleはオンメモリであることから, やはり差はでてしまう.
 しかしディスクに書き出していないこととは別の要因も考えられる.
 Jungleは非破壊的木構造なため, ロックをほとんど必要としない.

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

--- a/paper/introduciton.tex	Tue Mar 04 00:25:04 2014 +0900
+++ b/paper/introduciton.tex	Wed Mar 05 19:54:34 2014 +0900
@@ -1,6 +1,39 @@
 \chapter{序論}
 \pagenumbering{arabic}
-　ITシステムが巨大化していくにつれ, 障害発生事例が社会に与える影響もより大きな物となる.
+　ウェブサービスにとってデータベースは必須であり, ウェブサービスの規模
+に比例してデータベースへの負荷も大きなものとなっている. 
+そのため, データベースの処理能力の高さはそのままウェブサービスの質にも繋がってくる重要な
+項目となっている.
+データベースの処理能力をスケールさせる方法としてスケールアップ（垂直スケール）と
+スケールアウト（水平スケール）の考えがある.
+スケールアップはハードウェア的に高価な単一のマシンを用意することで処理性能を上げることをさす.
+スケールアウトは汎用的なマシンをいくつも用意し, 処理を分散させることで処理性能を上げることをさす.
+単純に処理能力をあげたいのならば, スケールアップは有効である.
+しかし, 単一のマシンを高性能にしても限界がある. 
+いずれはそのマシン単体が処理できない程負荷が増えるかもしれないし, ネットワーク帯域といったマシン
+以外のハードウェアでボトルネックが発生するかもしれない. 
+なによりコストがかかってしまう.
+
+それに対しスケールアウトは, 処理が重くなるにつれて汎用的なマシンを順次追加していくことで
+性能をあげていく.
+1つのマシンに対して負荷が重くなるということを避けるため, ハードウェア的に高性能なマシンを要求
+せずにすみ, 柔軟な対応をとることができる.
+ウェブサービスに使用されるデータベースの性能をあげる方法としては, このスケールアウトが求められている.
+
+本研究で扱うスケーラビリティとはこのスケールアウトのことをさす.
+最も使われているデータベースであるRelational Databaseはマシンを追加して負荷を分散させることが容易ではない, そのためスケーラビリティを持つことが困難である.
+Relational Databaseにはないスケーラビリティを持つデータベースとしてNoSQLと呼ばれるデータベースがある.
+NoSQLデータベースはConsistency hashingやShardingといった方法を使いデータを分散させスケーラビリティを得ている.
+データベースにおいてスケールアウトによりスケーラビリティを上げることはもはや必須となっている.
+
+本研究では, スケーラビリティのあるデータベースを目指して木構造データベースJungleの提案する.
+すなわち, Jungleに分散と永続性の実装を行う.
+既存の分散データベースであるCassandraとの比較を行うため, 簡易掲示板を作成し並列環境から負荷をかけることで
+性能比較を行った.
+
+本研究は JST/CREST 「実用化を目指した組み込みシステム用ディペンダブル・オペレーティングシステム」研究領域 (DEOSプロジェクト) として実施した. 
+本研究ではDEOSプロジェクト内の D-ADD (DEOS Agreement Description Database) を, 信頼性を持って構築ができる非破壊的木構造データベースの実装を示した.
+ITシステムが巨大化していくにつれ, 障害発生事例が社会に与える影響もより大きな物となる.
 それに伴い, ITシステムにおけるディペンダビリティへの注目が増している.
 
 そこで, DEOSプロジェクトはITシステムにおけるディペンダビリティを担保する技術体系をまとめ, 制度化, さらには事業化を目指している.
@@ -32,36 +65,7 @@
 これらのデータベースは, ウェブからアクセスされることも想定される.
 そのため, DEOSはウェブサービスとして捉えることができる.
 
-ウェブサービスにとってデータベースは必須であり, ウェブサービスの規模
-に比例してデータベースへの負荷も大きなものとなっている. 
-そのため, データベースの処理能力の高さはそのままウェブサービスの質にも繋がってくる重要な
-項目となっている.
-データベースの処理能力をスケールさせる方法としてスケールアップ（垂直スケール）と
-スケールアウト（水平スケール）の考えがある.
-スケールアップはハードウェア的に高価な単一のマシンを用意することで処理性能を上げることをさす.
-スケールアウトは汎用的なマシンをいくつも用意し, 処理を分散させることで処理性能を上げることをさす.
-単純に処理能力をあげたいのならば, スケールアップは有効である.
-しかし, 単一のマシンを高性能にしても限界がある. 
-いずれはそのマシン単体が処理できない程負荷が増えるかもしれないし, ネットワーク帯域といったマシン
-以外のハードウェアでボトルネックが発生するかもしれない. 
-なによりコストがかかってしまう.
 
-それに対しスケールアウトは, 処理が重くなるにつれて汎用的なマシンを順次追加していくことで
-性能をあげていく.
-1つのマシンに対して負荷が重くなるということを避けるため, ハードウェア的に高性能なマシンを要求
-せずにすみ, 柔軟な対応をとることができる.
-ウェブサービスに使用されるデータベースの性能をあげる方法としては, このスケールアウトが求められている.
-
-本研究で扱うスケーラビリティとはこのスケールアウトのことをさす.
-最も使われているデータベースであるRelational Databaseはマシンを追加して負荷を分散させることが容易ではない, そのためスケーラビリティを持つことが困難である.
-Relational Databaseにはないスケーラビリティを持つデータベースとしてNoSQLと呼ばれるデータベースがある.
-NoSQLデータベースはConsistency hashingやShardingといった方法を使いデータを分散させスケーラビリティを得ている.
-データベースにおいてスケールアウトによりスケーラビリティを上げることはもはや必須となっている.
-
-本論文では, スケーラビリティのあるデータベースを目指して木構造データベースJungleの提案する.
-すなわち, Jungleに分散と永続性の実装を行う.
-既存の分散データベースであるCassandraとの比較を行うため, 簡易掲示板を作成し並列環境から負荷をかけることで
-性能比較を行った.
 
 \newpage
 

Binary file paper/master_paper.pdf has changed