--- a/abstract.tex	Fri Feb 10 10:25:21 2017 +0900
+++ b/abstract.tex	Fri Feb 10 13:21:04 2017 +0900
@@ -21,6 +21,6 @@
 また、PostgreSQL・MongoDBと読み込み速度の比較を行った。
 結果、これらのDB以上の性能を確認できた。
 
-残された課題として木の設計手法の確立、 メモリ内にある木構造の破棄、データの書き出しの高速化等についての課題が確認された.
+残された課題として木の設計手法の確立、 メモリ内にある木構造の破棄についての課題が確認された.
 
 \end{abstract}

--- a/abstract_eng.tex	Fri Feb 10 10:25:21 2017 +0900
+++ b/abstract_eng.tex	Fri Feb 10 13:21:04 2017 +0900
@@ -3,9 +3,9 @@
 Exist an OR Mapper that can use database records as objects in program.
 and DB has been expand such as table specialization KVS and Json correspondence.
 However program Construction complexity structure on memory.
-Database has gap.
+It has gap between the data in the program and the data in the database.
 
-Laboratory develops database Jungle that solves these problems.
+Laboratory develops database Jungle that resolves these problems.
 Jungle doesn't destroy the tree structure.
 Construction a new tree while saving trees.
 Jungle transaction by atomic exchange the root of the tree.
@@ -16,8 +16,8 @@
 
 Jungle can read fast.
 However writing speed depend on Structure of tree and tree size.
-worst case O(n).
-And create Index is slow
+worst case Order(n).
+And create Index is slow.
 This research will improve Jungle editing function.
 After, Develop and use applications using Jungle.
 

--- a/appendix.tex	Fri Feb 10 10:25:21 2017 +0900
+++ b/appendix.tex	Fri Feb 10 13:21:04 2017 +0900
@@ -2,6 +2,6 @@
 \addcontentsline{toc}{chapter}{発表文献}
 
 \begin{itemize}
-\item{非破壊的木構造データベースJungleとその評価,金川竜己 , 河野真治(琉球大学), オープンソースカンファレンス2015 Okinawa, May, 2015}
+\item{非破壊的木構造データベースJungleとその評価,金川竜己 , 河野真治(琉球大学), システムソフトウェアとオペレーティング・システム研究会 ,2015 Okinawa, May, 2015}
 \item{ソフトウェア内部で使用するのに適した木構造データベースJungle, \\ 金川竜己, 武田和馬(琉球大学), 河野真治(琉球大学), \\ 第58回プログラミング・シンポジウム, Jan, 2017}
 \end{itemize}

--- a/conclusion.tex	Fri Feb 10 10:25:21 2017 +0900
+++ b/conclusion.tex	Fri Feb 10 13:21:04 2017 +0900
@@ -1,12 +1,56 @@
 \chapter{結論} \label{chapter:conclusion}
 
 \section{まとめ}
-まとめを書く
+本研究では、初めに既存のデータベースについて説明を行い、
+次に木構造データベースJungleで使われている非破壊的木構造について述べ、
+破壊的木構造に比べロックが少ないというメリットがあることを論じた。
+Jungle の提供しているAPIについて記述を行った。
+
+JungleのIndexの性能を向上させるため、非破壊の Red Blck Tree の実装を行った。
+Index の Update を高速化させるために、前の版の Index と値を共有しながら Update を行う、差分 Update の実装を行った。
+結果、既存の Index より高速に読み込み、 Update ができるようになったことを確認できた。
+
+次に、線形の木を正順で構築する際、木の変更の手間がO(n)になる問題を解決するために、Differentail Jungle Tree の実装をした。
+Differential Jungle Tree は、自身の末尾のノードの情報を保持している。
+この末尾ノードを使用して、木の編集や検索を行う。
+
+また、Jungle の木の編集の手間は、木のサイズにも依存している。
+きちんとバランスの取れた木を構築できれば、O(LogN)で編集を行える。
+しかし、全ての木の形をユーザーが把握し、バランスを取るのは難しい。
+そこで、自動的に木のバランスを行い、最適な形の木構造を構築する Red Black Jungle Tree を実装した。
+Red Black Jungle Tree は、自身が Index と同じ働きをするため、別途 Index を構築する必要がない。
+よって、 Index を構築する Default Jungle Tree より、編集できる。
+また、ノードは、木のバランスによって Path が編集ごとに変わってしまうため、属性名と属性値のペアでノードを指定できる、 Red Black Jungle Tree Editor の実装を行った。
+
+次に、Jungle を使用した例題アプリケーションの実装を行った。
+1つ目は、Jungle Tree Browser という、ブラウザ上から Jungle の編集等を行うアプリケーションを開発した。
+2つ目は、 Html Rendering Engine の開発を行った。
+これらのアプリケーションを開発・運用した結果、Jungle は設計を行うことなく、どんな構造のデータでも格納できるが、きちんと設計を行うと、より高速で簡潔なコードが書けることがわかった。
+
+性能測定では、今回実装した機能の測定を行った。
+Index の Update・Differential Jungle Tree・Red Black Jungle Tree・全て予想通りの結果が確認できた。
+また、既存のDBである、MongoDB・PostgreSQL と Jungle の読み込み速度を測定した結果、Jungle の方が極めて高速に読み込みを行えることが確認できた。
+これは、MongoDB・PostgreSQLが、通信を介してデータにアクセスするのに対して、Jungle は直接メモリの中にあるデータを参照しているためである。
+
+
+
 
 \section{今後の課題}
 
+\subsection{過去のデータの掃除}
+Jungleは非破壊でデータを保持し続けるため、非常に多くのメモリを使用してしまう。
+ある程度の単位で過去のデータの掃除を行いたい。
+Jungle は、過去の木に対するアクセスをサポートしているため、データの掃除を行うタイミングが明確ではない。
+なので、メモリから追い出すタイミングを定義する必要がある。
 
-\subsection{今後の課題}
+
+\subsection{木の設計手法の確立}
+JungleはRDBと異なり格納するデータの自由度は大きい。
+どのようなデータ構造も、設計を行わず格納できる。
+しかし、十分なパフォーマンスを出すためには、データを最適化する必要がある。
+また、最適な木構造はアプリケーションによって違うため、Jungleの設計手法を確立させる必要がある。
+
+
 
 
 %\subsection{Treeのバランスの問題}

Binary file master_paper.pdf has changed