\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{木の設計手法の確立}
JungleはRDBと異なり格納するデータの自由度は大きい。
どのようなデータ構造も、設計を行わず格納できる。
しかし、十分なパフォーマンスを出すためには、データを最適化する必要がある。
また、最適な木構造はアプリケーションによって違うため、Jungleの設計手法を確立させる必要がある。




%\subsection{Treeのバランスの問題}