\chapter{結論} \label{chapter:conclusion}

\section{まとめ}
本研究では, まず初めにスケーラビリティがあると言われている分散データベースCassandraを利用して検証環境を構築するための検証を行った.
そして, その検証結果からどのような方法を用いればスケーラビリティを確保することが出来るか考え, 非破壊的木構造とpush/pull方式について考察した.
次に, 非破壊的木構造とpush/pull方式を用いた全体的な設計を行い. どのようにしてコンテンツを管理するか論じた.
そのなかで, サーバーサイドに非破壊的木構造を用いたデータベースを構築する必要が有ることが分かり, 実装では, まず, 非破壊的木構造を用いたデータベースJungleの実装を行った.
実装では, グラフデータベースのトラバースを検索に取り入れ, また, APIはユーザーにデータベースが非破壊的であることを意識させる設計と実装を行った.
検証では, 学科で用意されたVMWare仮想クラスタとは別にブレードサーバーを用意しそこにKVMクラスタを構築した. その構築した2つの環境と, コア数の多いサーバーと少ないサーバーの2種類用意し, それぞれでCassandraとJungleをバックエンドとした簡易掲示板システムを動作させたものに並列に負荷をかけてスケーラビリティ検証を行った.
結果, Cassandraより少し速い結果を得ることが出来たが, 台数効果を確認することが出来ず, さらなるチューニングの余地があることが分かった.

\section{今後の課題}
\subsection{Journalの実装}
Journalとは, Jungleに実装される予定である木構造を永続化する仕組みである.
現在のJungleには, 仕組みのみ取り入れられているが何もしないJournalで実装されており, 今後実装する必要があると考えられる.
その場合は, 更にどのようにしてJournalを実装すればいよいか考察する必要もある.

\subsection{Mergerの実装}
木構造データベースJungleにて,非破壊的木構造部分は実装することが出来たがMergerが未実装である.
Mergerはpush/pull方式を実現するために必要なものである. マージにはお互いの木の情報が必要になるが, その情報がどの程度必要か考える必要がある.
木構造を利用するユーザーは自身でどのようにしてコンテンツを木構造にするか知っているため, マージの方法をも知っていると考えられる.
そのため, Mergerでの過度な情報の提供は, その情報をデータベース側で用意しなければならず, 情報の確保がデータベースの負荷を上昇させてしまうおそれがある.

\subsection{メモリ使用量の問題}
現在のJungleの実装では, 木構造の履歴をすべて保存するために非常に多くのメモリを必要とする.
そのため, GCにより性能が低下したりメモリが足りなくなったりする可能性がある. 
検証では, サーバー側のメモリ使用量を確認すると高速にメモリ使用量が上昇しているのが確認できた.
そのため, どのようにしてメモリ使用量を減らしていくか考える必要があり, 例えば, 利用されていない古い木構造は二次記憶に対比させるなど工夫が必要であると考えられる.

\subsection{台数効果の問題}
本検証では, コア数の台数効果を検証で確認することが出来なかった.
どのコア数の多いサーバーとコア数の少ないサーバーで同一の結果が得られることがあったなど, 検証の仕方を工夫する必要がある.
その理由を考え, サーバーやクライアントをチューニングする必要があると考えられる.

\subsection{KVMを用いた仮想クラスタについて}
今回は試験的に, KVMを用いた仮想クラスタを利用して実験を行った. 
今回の仮想クラスタは1台のブレードサーバーに48台もの仮想クラスタを用意している.
検証結果では, VMWareクラスタより遅い結果が出ているが, KVMクラスタも3台のブレードサーバーに分配し, かつ, KVM特有のチューニングを行うことで性能を向上させることが出来るのではないかと考える.