Mercurial > hg > Papers > 2017 > suruga-sigos
diff paper/sigos.tex @ 24:64a017ca89a4
done
author | Shinji KONO <kono@ie.u-ryukyu.ac.jp> |
---|---|
date | Mon, 23 Apr 2018 23:01:03 +0900 |
parents | b81702f6108a |
children | 8bad8d17b4c1 |
line wrap: on
line diff
--- a/paper/sigos.tex Mon Apr 23 21:47:58 2018 +0900 +++ b/paper/sigos.tex Mon Apr 23 23:01:03 2018 +0900 @@ -41,7 +41,7 @@ \etitle{} % 所属ラベルの定義 -\affilabel{2}{琉球大学工学部情報工学科\\Information Engineering, University of the Ryukyus.} +\affilabel{1}{琉球大学工学部情報工学科\\Information Engineering, University of the Ryukyus.} % 和文著者名 \author{ @@ -60,6 +60,8 @@ TEL: (098)895-2221\qquad FAX: (098)895-8727\\ email: kono@ie.u-ryukyu.ac.jp} + + % 和文概要 \begin{abstract} 現代のインターネットやアプリケーションで使われるデータは、複雑な構造を持っており、RDBの第一正規系には納まらないようになってきている。 @@ -77,7 +79,7 @@ 巨大な木が必要な場合は、木を特定のKeyを用いてbalanceさせることにより、変更をO(log n)にすることができる。 Jungleは分散構造を取ることもできる。 複数の木を複数の分散したJungleノード間で通信することにより、Jungleをスケールさせる。 -Jungleの木の変更Logを当研究室で開発した分散フレームワークAlice\cite{alice}を用いて通信する。 +Jungleの木の変更Logを当研究室で開発した分散フレームワークAlice\cite{kono16a}を用いて通信する。 それぞれの木は、ルートノードに集約され、集約の過程で、競合する変更のMergeを行う。 分散Jungleの性能を測定する手法について述べる。 \end{abstract} @@ -109,7 +111,7 @@ 安定したネットワークサービスを提供するためには、分散プログラムに信頼性とスケーラビリティが要求される。 ここでいう信頼性とは、定められた環境下で安定して仕様に従った動作を行うことを指す。 -分散プログラムには以下の3つの要素がある\cite{Framework}。 +分散プログラムには以下の3つの要素がある\cite{kono05f}。 \begin{itemize} \item {ノード内の計算} \item {ノード間通信} @@ -140,7 +142,7 @@ Jungle では、木のノードの位置を NodePath クラスを使って表す。 NodePath クラスはルートノードからスタートし、対象のノードまでの経路を数字を用いて指し示す。また、ルートノードは例外として-1と表記される。 NodePath クラスを用いて \textless -1,0,2,3 \textgreater を表している際の例を(図\ref{fig:nodepath})に示す。 \begin{figure}[htpb] \begin{center} - \includegraphics[width=60mm]{pic/nodepath.pdf} + \includegraphics[width=50mm]{pic/nodepath.pdf} \end{center} \caption{NodePath} \label{fig:nodepath} @@ -178,7 +180,7 @@ \begin{figure}[htbp] \centering - \includegraphics[width=100mm]{pic/tree.pdf} + \includegraphics[width=50mm]{pic/tree.pdf} \caption{ツリー型のトポロジー} \label{fig:tree} \end{figure} @@ -223,8 +225,8 @@ このCSをmainメソッド内でnewし、executeメソッドを呼ぶことで実行を開始させることができる。 -\lstinputlisting[label=src:StartCodeSegment, caption=StartCodeSegmentの例]{source/StartCodeSegment.java} -\lstinputlisting[label=src:CodeSegment, caption=CodeSegmentの例]{source/TestCodeSegment.java} +\lstinputlisting[label=src:StartCodeSegment, caption=StartCodeSegment]{source/StartCodeSegment.java} +\lstinputlisting[label=src:CodeSegment, caption=CodeSegment]{source/TestCodeSegment.java} \newpage @@ -288,8 +290,8 @@ さらに、setKeyは明確な記述場所が決まっていないため、そのDSを待ち合わせているCS以外からも呼び出せてしまう(ソースコード\ref{src:StartSetKey})。 - \lstinputlisting[label=src:StartSetKey, caption=setKeyを外部から呼び出す例]{source/StartSetKey.java} - \lstinputlisting[label=src:SetKey, caption=外部setKeyによりどのkeyを待っているかがわからないCSの例]{source/SetKey.java} + \lstinputlisting[label=src:StartSetKey, caption=setKey]{source/StartSetKey.java} + \lstinputlisting[label=src:SetKey, caption=Seprated setKey]{source/SetKey.java} このような書き方をされると、CSだけを見てどのkeyに対して待ち合わせを行っているのかわからないため、setKeyを呼び出しているコードを辿る必要がある。 これでは見通しが悪いため、どこでkeyを指定するのか明確にすべきである。 @@ -372,7 +374,7 @@ リモートノードに対してTake/Peekする際は、TakeFrom/PeekFromのアノテーションを用いる(ソースコード\ref{src:remotetake})。 -\lstinputlisting[label=src:remotetake, caption=TakeFromの例]{src/RemoteInputDG.java} +\lstinputlisting[label=src:remotetake, caption=TakeFrom]{src/RemoteInputDG.java} なお、圧縮のMeta ComputationはAliceと同様で、指定する際にDGM名の前にcompressedをつける(ソースコード\ref{src:compresslocal})。 @@ -383,7 +385,7 @@ 基本的なシンタックスはAliceと同様だが、Christieではput/flipのメソッドはCodeGear.classに用意されている。 そのためCodeGear.classを継承するCGで直接putメソッドを呼ぶことができる(ソースコード\ref{src:remoteput})。 -\lstinputlisting[label=src:remoteput, caption=putの例]{src/RemotePut.java} +\lstinputlisting[label=src:remoteput, caption=put]{src/RemotePut.java} そのため、ChristieにはAliceのODSにあたる部分がない。 ODSを経由するより直接DGMに書き込むような記述のほうが直感的であると考えたためである。 @@ -422,7 +424,30 @@ runでCGMを受け渡すのはこのためである。 なお、StartCGはインプットを持たないため、setupを行う必要がなく、newされた時点でrunが実行される。 -\subject{まとめ} +\section{Unixファイルシステムとの比較} + +Christie を分散ファイルシステムとして使うのと、Unixファイルシステム上の分散ファイルシステムとの違いについて考察する。 + +Christie に格納されるのはオブジェクトであり、型のないテキストファイルとは異なる。もちろん、文字列をそのまま格納することも +できるが、巨大な文字列にはなんらかの構造を与えてランダムアクセスなどができるようにする。その意味で、Unixファイルシステム +でもファイルには必ず構造が入っている。 + +Unixファイルにはディレクトリ構造があり、ディレクトリの構造にはトランザクションが導入されている。Christieの場合は、 +Christie の同期機構としてトランザクションが定義される。 + +Unixファイル全体はiノードを使ったB-Tree構造を持つ。これらはディレクトリ構造による木構造のパスでアクセスされる。 +Christie ではパスとディレクトリは木構造のデータベースとして定義される。 + +Unixファイルの持続性はディスク上のiノードの持続性によって実現される。Christieは持続性のあるノードに木構造を +複製することによって持続性を実現する。 + +Unixファイルはread/writeによりアクセスするが、Christieではメモリ上のオブジェクトであり、read/writeではなく +名前で指定された木に対する get/put で変更を行う。 + +持続性のあるノードに複製されたChristieのオブジェクトはメモリ上から削除しても良い。再度必要な場合は、パスを +用いて持続性のあるノードから複製する。 + +\section{まとめ} 分散木構造データベースJungleと、分散フレームワークAliceについて考察し、両者を統一する形で、分散フレームワークChristieを 提案した。 @@ -440,6 +465,6 @@ %参考文献 \bibliographystyle{ipsjunsrt} -\bibliography{sigos} +\bibliography{ref} \end{document}