Mercurial > hg > Papers > 2014 > nobuyasu-master
view paper/conclusion.tex @ 63:d770a2b534b3
Writed description of persistent
author | Nobuyasu Oshiro <dimolto@cr.ie.u-ryukyu.ac.jp> |
---|---|
date | Sat, 01 Feb 2014 15:59:14 +0900 |
parents | 1d07365c60ff |
children | 4f31182c8244 |
line wrap: on
line source
\chapter{結論} \label{chapter:conclusion} \section{まとめ} 本研究では, まず初めにRDBとNoSQLの説明を行い, 既存のNoSQLであるCassandra, MongoDB, Neo4jが スケーラビリティをどのように確保しているかを述べた. 次に木構造データベースJungleで使われている非破壊的木構造について述べ, 破壊的 木構造に比べロックが少ないというメリットがあることを論じた. Jungleは非破壊的木構造により過去のデータを保持することでMergeを行うことができる. そのため, 分散バージョン管理システムを参考に分散設計を行った. Jungleの分散設計では当研究室で開発している並列分散フレームワークAliceを用いた. Aliceにより自由にトポロジーを組め, 他サーバノードへのデータアクセス機構を手に入れることができた. Jungleの分散実装ではデータの編集履歴であるTreeOperationLogをAliceが使用できるようにし, 木の名前と いった必要な情報を追加することでデータの分散を行った. また, Jungleに元々設計されていたJournalを使ってログをディスクへ書き出すことで永続性の実装を行った 最後に簡易掲示板を作成, Cassandraとの性能比較を行った. 読み込み, 書き込みの負荷をかける実験を2つ行った. 1つの実験ではサーバノード1台に対し複数のクライアントから負荷をかけた. 2つめの実験では複数のクライアントに対し同じ数のサーバノードを用意し数を増やしていき負荷を高めた. どちらの実験もJungleがCassandraよりも良い結果を示すことを確認した. \section{今後の課題} \subsection{データ分割の実装} 現在Jungleの分散実装は全てのデータを全てのノードで保持している. この方法ではメモリの使用量が高いこととネットワーク帯域に対しての 負荷が懸念される. そのため, ノード単位で保持するデータを分ける実装が必要になる. ノード毎に木構造単位で別々のデータを保持し, 持っていない木のデータ に対して要求がくると他からとってきて返すといった機能が必要になる. \subsection{Mergerアルゴリズムの設計} JungleはMergeを使うことでデータ衝突の問題を解決をはかるが, この Mergeはアプリケーション毎に考えなければならない. 今回, JungleにおけるMergeの例として掲示板プログラムにおけるMergeについて述べた. だが掲示板のような単純なMergeですむアプリケーションは少ない. また, アプリケーション毎でデータの保存の仕方といったものも違ってくる. そのため, アプリケーションに合ったMergeアルゴリズムを設計しなければならない. \subsection{分断耐性の実装} 現在の実装のJungleは, プログラムの起動時にノードと接続を行う. プログラムの途中で接続がきれるとトポロジーがくずれたままになる. 接続がきれたJungleは単独では稼働し続けるが, 復帰を行えるようにしたい. そのためにはトポロジーに割り当てられた際に他ノードから自分の持っているデータとの 差分のデータを流してもらうといった機能が必要になってくる. \subsection{過去のデータの掃除について} Jungleは非破壊でデータを保持し続けるため, メモリの使用量が大きい. ある程度の単位で過去のデータの掃除を行いたい. 今回分散実装を行ったことで, 多数のノードでデータが保持され, その内の数台が ディスクへ書き出すといったことも可能になった. だが, Mergeの問題含め, どのタイミングで過去のデータを掃除すべきかは自明ではない. 分断耐性の実装の問題とも関わってくるが, どのデータがどれだけ複製して持っているといった 情報も扱う必要がでてくるかもしれない. %\subsection{Treeのバランスの問題}