# HG changeset patch # User Shinji KONO # Date 1478776805 -32400 # Node ID e81a5eb2a60fe3a6bdf43b322c77d4e6a1bbe85a # Parent 5d68cbc1ad5e6ae3b2506b7ec1059184a64e0c96 fix diff -r 5d68cbc1ad5e -r e81a5eb2a60f maTrix.tex --- a/maTrix.tex Thu Nov 10 20:14:04 2016 +0900 +++ b/maTrix.tex Thu Nov 10 20:20:05 2016 +0900 @@ -1,5 +1,5 @@ \section{許認可管理アプリケーション\\maTrix} -BBSを実装した後、Jungle上に実際に企業で運用されている許認可管理アプリケーションmaTrixを実装し、データベースとしての表現力、機能の十分性、実用的な性能があるか、実証実験を行なった。 +Jungle Treeブラウザを実装した後、Jungle上に実際に企業で運用されている許認可管理アプリケーションmaTrixを実装し、データベースとしての表現力、機能の十分性、実用的な性能があるか、実証実験を行なった。 maTrixは、人、役職、役割、権限、組織等の木構造のデータとポリシーファイルを持つ。maTrixの組織構造はデータ同士がidを用いた参照を行うことで表現される。また組織構造は版管理されている。 ポリシーファイルは、データに対するアクセス要求が許可されるか否認されるかを判断するためのルールを誰が(Target)、何を(Resource)、どうできるか(Action)の3つの要素で記述されている。maTrixはアクセス要求に応じたポリシーファイルを参照することで許認可の判断を行う。 @@ -94,19 +94,19 @@ しかし、Jungleは非破壊という性質上、子に親への参照をもたせることが難しいため、Nodeを渡すと親Nodeを返すParentIndexを実装した。 -\subsection{性能測定} -maTrixの実装後、Jungleに実用的な性能があるか確かめるために測定を行った。 -比較対象にはMongoDBを選択した。 -図\ref{fig:compare}はmongoDBとJungleの速度比較のグラフである。 -比較は10000人分のデータに対するアクセスの処理時間で行い、mongoDBへのアクセスはjsを用いて行った。 -\begin{figure}[h] -\begin{center} -\includegraphics[height = 5cm , bb=0 0 360 252]{images/mongoJungleperfomance.pdf} -\caption{mongoDBとの比較} -\label{fig:compare} -\end{center} -\end{figure} +% \subsection{性能測定} +% maTrixの実装後、Jungleに実用的な性能があるか確かめるために測定を行った。 +% 比較対象にはMongoDBを選択した。 +% 図\ref{fig:compare}はmongoDBとJungleの速度比較のグラフである。 +% 比較は10000人分のデータに対するアクセスの処理時間で行い、mongoDBへのアクセスはjsを用いて行った。 +% \begin{figure}[h] +% \begin{center} +% \includegraphics[height = 5cm , bb=0 0 360 252]{images/mongoJungleperfomance.pdf} +% \caption{mongoDBとの比較} +% \label{fig:compare} +% \end{center} +% \end{figure} -Jungleは、mongodbの約500倍の性能が出ている。 -その理由として、mongoDBがmmapを用いてディスクのデータにアクセスしているのに対し、Jungleは全てのデータがメモリ上にあること。 -また、mongoDBは通信を介してアクセスされるが、Jungleは通信を介さないためだと考えられる。 +% Jungleは、mongodbの約500倍の性能が出ている。 +% その理由として、mongoDBがmmapを用いてディスクのデータにアクセスしているのに対し、Jungleは全てのデータがメモリ上にあること。 +% また、mongoDBは通信を介してアクセスされるが、Jungleは通信を介さないためだと考えられる。 diff -r 5d68cbc1ad5e -r e81a5eb2a60f renderingEngine.tex --- a/renderingEngine.tex Thu Nov 10 20:14:04 2016 +0900 +++ b/renderingEngine.tex Thu Nov 10 20:20:05 2016 +0900 @@ -1,11 +1,14 @@ \section{HtmlRenderingEngine} -前章でJungleに実用データベースたる性能があることが分かったので、実際にJungle上に例題アプリケーションとしてHtmlRenderingEngineの開発を行った。 -HtmlRenderingEngineは、出力するデータが記述されたContextTree、出力する形式が記述されたLayoutTreeの２つの木構造を持ち、これらを参照しながらhtmlのRenderingを行う。 + +% 前章でJungleに実用データベースたる性能があることが分かったので、実際に + +次にJungle上に例題アプリケーションとしてHtmlRenderingEngineの開発を行った。 +HtmlRenderingEngineは、出力するデータが記述されたContens tTree、出力する形式が記述されたLayout Treeの2つの木構造を持ち、これらを参照しながらhtmlのRenderingを行う。 本章ではRenderingEngineの実装と発生した問題、解法について解説する。 またRenderingする例題はDiaryを選択した。 -\subsection{ContentTreeのJungle上での表現} -RenderingEngineではContentTreeに図\ref{contentTree}のように出力するデータを格納した。 +\subsection{Contents TreeのJungle上での表現} +RenderingEngineではContents Treeに図\ref{contentTree}のように出力するデータを格納した。 \begin{figure}[h] \begin{center} @@ -38,27 +41,27 @@ \subsection{Layout} htmlの出力形式を定義するLayoutは複数のComponentからなる。 -LayoutTreeには図\ref{layoutTree}のようにデータを格納した。 +Layout Treeには図\ref{layoutTree}のようにデータを格納した。 \begin{figure}[h] \begin{center} -\includegraphics[height = 9cm , bb=0 0 955 1153]{images/LayoutTree.pdf} -\caption{LayoutTree} +\includegraphics[height = 9cm , bb=0 0 955 1153]{images/Layout Tree.pdf} +\caption{Layout Tree} \label{layoutTree} \end{center} \end{figure} -LayoutTreeはNodeName : displayinformationの組で値を保持するNode1の子に複数のComponentを保持する +Layout TreeはNodeName : displayinformationの組で値を保持するNode1の子に複数のComponentを保持する ComponentはdisplayComponentName -\textgreater NodeNameの単一的な参照を行っている。 -Node3は、"use" = "text"のペアでタグを保持しているため、ContentTreeの日記の本文に対応する記述が行ってあることがわかる。 -表\ref{tag}にタグとcontextの対応を記述する +Node3は、"use" = "text"のペアでタグを保持しているため、Contents Treeの日記の本文に対応する記述が行ってあることがわかる。 +表\ref{tag}にタグとContentsの対応を記述する \begin{table}[htb] \begin{center} - \caption{tagとcontextの対応} + \caption{tagとcontentsの対応} \begin{tabular}{|c|c|} \hline - tag & context \\ \hline + tag & content \\ \hline image & 画像の表示 \\ \hline cals & table \\ \hline date & 日付の表示 \\ \hline @@ -82,51 +85,51 @@ 図\ref{multiComponent}の例では、diaryMulti@componentはdiaryText@componentとdiaryImage@componentを参照している。 -\subsection{LayoutTreeのデータ設計} +\subsection{Layout Treeのデータ設計} Jungleは汎用の木構造を持つので、データベースを特に設計しなくても、あるがままの形で格納することが可能である。 しかし、設計を行うことでより効率的に木構造を扱うことが可能になる。 -図\ref{goodLayoutTree}、図\ref{badLayoutTree}は同じデータを格納した２つの木の一部である。 +図\ref{goodLayout Tree}、図\ref{badLayout Tree}は同じデータを格納した２つの木の一部である。 \begin{figure}[h] \begin{center} -\includegraphics[height = 4cm , bb=0 0 422 322]{images/goodLayoutTree.pdf} +\includegraphics[height = 4cm , bb=0 0 422 322]{images/goodLayout Tree.pdf} \caption{コードとギャップのないLayoutの格納方法} -\label{goodLayoutTree} +\label{goodLayout Tree} \end{center} \end{figure} \begin{figure}[h] \begin{center} -\includegraphics[height = 8cm , bb=0 0 1263 932]{images/badLayoutTree.pdf} +\includegraphics[height = 8cm , bb=0 0 1263 932]{images/badLayout Tree.pdf} \caption{コードとギャップのあるLayoutの格納方法} -\label{badLayoutTree} +\label{badLayout Tree} \end{center} \end{figure} -図\ref{goodLayoutTree}のTreeは、１つのNodeにRenderingに必要な値が全て格納されている。 +図\ref{goodLayout Tree}のTreeは、１つのNodeにRenderingに必要な値が全て格納されている。 そのため、Renderingを行う際、複数のNodeをまたぐ必要が無く、簡潔にコードを書くことができる。 -一方、図\ref{badLayoutTree}のTreeはRenderingする際に必要な値が複数Nodeに分散されて保存されている。 +一方、図\ref{badLayout Tree}のTreeはRenderingする際に必要な値が複数Nodeに分散されて保存されている。 そのため、全てのNodeを参照し、値を集める処理を行う必要があり、コードの可読性が下がり余計な処理も増えてしまった。 \subsection{性能評価} -本節では、図\ref{goodLayoutTree}の木と図\ref{badLayoutTree}を使った2つのRenderinEngineの性能測定を行い、木の構造が実行速度にどれだけ影響するかを確かめる。 +本節では、図\ref{goodLayout Tree}の木と図\ref{badLayout Tree}を使った2つのRenderinEngineの性能測定を行い、木の構造が実行速度にどれだけ影響するかを確かめる。 測定は100000回のRenderingRequestを処理するまでの時間の比較で行う。 図\ref{fig:BenchMark}が性能測定結果のグラフである。 設計を行った木の方が高速にRenderingを行えている。 -\begin{figure}[h] -\begin{flushleft} -\includegraphics[height = 8cm , bb=150 0 792 612]{images/benchMarck.pdf} -\caption{性能評価} -\label{fig:BenchMark} -\end{flushleft} -\end{figure} +%\begin{figure}[h] +%\begin{flushleft} +%\includegraphics[height = 8cm , bb=150 0 792 612]{images/benchMarck.pdf} +%\caption{性能評価} +%\label{fig:BenchMark} +%\end{flushleft} +%\end{figure} 測定結果より、Jungleデータベースはデータの設計を行うこと無く格納可能だが、設計を行ったほうがプログラム内のデータ構造とギャップがなく、高速に動作するプログラムを簡潔に記述できるようになる事がわかる。 diff -r 5d68cbc1ad5e -r e81a5eb2a60f summary.tex --- a/summary.tex Thu Nov 10 20:14:04 2016 +0900 +++ b/summary.tex Thu Nov 10 20:20:05 2016 +0900 @@ -9,4 +9,4 @@ その際Jungleのデータ構造でプログラムの処理量、コードの可読性が異なることがわかった。 性能測定では、データ設計を行った木構造を利用したほうが高速に動作した。 今後の課題として、Jungleは汎用の木構造を持ち、設計を行わずに木構造を格納することが可能だが、最適なデータ構造にすることでさらなる性能の向上が見込むことができる。 -よってJungleの設計手法を確立させる必要がある。 +よってJungleの木の設計手法を確立させる必要がある。