Mercurial > hg > Papers > 2014 > nobuyasu-master
comparison paper/conclusion.tex @ 75:986f07c56c83
Fixed conclusion
author | Nobuyasu Oshiro <dimolto@cr.ie.u-ryukyu.ac.jp> |
---|---|
date | Sun, 02 Feb 2014 11:11:04 +0900 |
parents | 498679da05cf |
children | 5c5d71d36c14 |
comparison
equal
deleted
inserted
replaced
74:498679da05cf | 75:986f07c56c83 |
---|---|
18 2つめの実験では複数のクライアントに対し同じ数のサーバノードを用意し数を増やしていき負荷を高めた. | 18 2つめの実験では複数のクライアントに対し同じ数のサーバノードを用意し数を増やしていき負荷を高めた. |
19 どちらの実験もJungleがCassandraよりも良い結果を示すことを確認した. | 19 どちらの実験もJungleがCassandraよりも良い結果を示すことを確認した. |
20 | 20 |
21 | 21 |
22 \section{今後の課題} | 22 \section{今後の課題} |
23 | |
24 | |
25 \subsection{pull/push機能の実装} | |
26 現在の実装のJungleは, プログラムの起動時に複数ノードが接続をしトポロジーを形成する. | |
27 プログラムの途中で接続がきれるとトポロジーがくずれたままになる. | |
28 接続がきれたJungleは単独では稼働し続けるが, トポロジーへの復帰を行えるようにしたい. | |
29 そのためには、今の実装で行っている非同期でログを送信する方法とは別に同期をとり差分のデータを伝搬する方法を | |
30 実装する必要がある。 | |
31 これは, 分散管理システムにおけるpull/push APIの機能にあたる. | |
32 | |
33 | |
34 \if0 % push/pullの話と内容がかぶる? | |
23 \subsection{データ分割の実装} | 35 \subsection{データ分割の実装} |
24 現在Jungleの分散実装は全てのデータを全てのノードで保持させる実装である. | 36 現在Jungleの分散実装は全てのデータを全てのノードで保持させる実装である. |
25 だが, この方法ではメモリの使用量が高いこととネットワーク帯域に対しての | 37 だが, この方法ではメモリの使用量が高いこととネットワーク帯域に対しての |
26 負荷が懸念される. | 38 負荷が懸念される. |
27 そのため, ノード単位で保持するデータを分ける実装が必要になる. | 39 そのため, ノード単位で保持するデータを分ける実装が必要になる. |
28 ノード毎に木構造単位で別々のデータを保持し, 持っていない木のデータ | 40 ノード毎に木構造単位で別々のデータを保持し, 持っていない木のデータ |
29 に対して要求がくると他からとってきて返すといった機能が必要になる. | 41 に対して要求がくると他からとってきて返すといった機能が必要になる. |
42 \fi | |
30 | 43 |
31 | 44 |
32 \subsection{Mergerアルゴリズムの設計} | 45 \subsection{Mergerアルゴリズムの設計} |
33 JungleはMergeを使うことでデータ衝突の問題を解決をはかるが, この | 46 JungleはMergeを使うことでデータ衝突の問題を解決をはかるが, この |
34 Mergeはアプリケーション毎に考えなければならない. | 47 Mergeはアプリケーション毎に考えなければならない. |
35 今回, JungleにおけるMergeの例として掲示板プログラムにおけるMergeについて述べた. | 48 今回, JungleにおけるMergeの例として掲示板プログラムにおけるMergeについて述べた. |
36 だが掲示板のような単純なMergeですむアプリケーションは少ない. | 49 だが掲示板のような単純なMergeですむアプリケーションは少ない. |
37 また, アプリケーション毎でデータの保存の仕方といったものも違ってくる. | 50 また, アプリケーション毎でデータの保存の仕方といったものも違ってくる. |
38 そのため, アプリケーションに合ったMergeアルゴリズムを設計しなければならない. | 51 そのため, アプリケーションに合ったMergeアルゴリズムを設計しなければならない. |
52 | |
39 | 53 |
40 | 54 |
41 \subsection{過去のデータの掃除について} | 55 \subsection{過去のデータの掃除について} |
42 Jungleは非破壊でデータを保持し続けるため, メモリの使用量が大きい. | 56 Jungleは非破壊でデータを保持し続けるため, メモリの使用量が大きい. |
43 ある程度の単位で過去のデータの掃除を行いたい. | 57 ある程度の単位で過去のデータの掃除を行いたい. |
46 だが, Mergeの問題含め, どのタイミングで過去のデータを掃除すべきかは自明ではない. | 60 だが, Mergeの問題含め, どのタイミングで過去のデータを掃除すべきかは自明ではない. |
47 分断耐性の実装の問題とも関わってくるが, どのデータがどれだけ複製して持っているといった | 61 分断耐性の実装の問題とも関わってくるが, どのデータがどれだけ複製して持っているといった |
48 情報も扱う必要がでてくるかもしれない. | 62 情報も扱う必要がでてくるかもしれない. |
49 | 63 |
50 | 64 |
51 \if0 % データ分割の実装と内容がかぶる | |
52 \subsection{pull/push機能の実装} | |
53 現在の実装のJungleは, プログラムの起動時に複数ノードが接続をしトポロジーを形成する. | |
54 プログラムの途中で接続がきれるとトポロジーがくずれたままになる. | |
55 接続がきれたJungleは単独では稼働し続けるが, トポロジーへの復帰を行えるようにしたい. | |
56 そのためにはトポロジーに割り当てられた際に他ノードから自分の持っているデータとの | |
57 差分のデータを流してもらうといった分散管理システムにおけるpull/push APIの機能が必要になってくる. | |
58 \fi | |
59 | |
60 | 65 |
61 %\subsection{Treeのバランスの問題} | 66 %\subsection{Treeのバランスの問題} |