# HG changeset patch
# User suikwasha
# Date 1360866366 -32400
# Node ID a2ea38dd7c86e0a79ea810087de1184bc7f584dd
# Parent  405fdfcca4f723087da0b11846232175b3d26fd7
changed color , added new graph

diff -r 405fdfcca4f7 -r a2ea38dd7c86 images/read_4cores.png
Binary file images/read_4cores.png has changed
diff -r 405fdfcca4f7 -r a2ea38dd7c86 images/read_bldsv10.png
Binary file images/read_bldsv10.png has changed
diff -r 405fdfcca4f7 -r a2ea38dd7c86 images/read_kvm_4cores.png
Binary file images/read_kvm_4cores.png has changed
diff -r 405fdfcca4f7 -r a2ea38dd7c86 images/write_4cores.png
Binary file images/write_4cores.png has changed
diff -r 405fdfcca4f7 -r a2ea38dd7c86 images/write_bldsv10.png
Binary file images/write_bldsv10.png has changed
diff -r 405fdfcca4f7 -r a2ea38dd7c86 images/write_kvm_4cores.png
Binary file images/write_kvm_4cores.png has changed
diff -r 405fdfcca4f7 -r a2ea38dd7c86 index.html
--- a/index.html	Fri Feb 15 00:27:55 2013 +0900
+++ b/index.html	Fri Feb 15 03:26:06 2013 +0900
@@ -15,12 +15,17 @@
    
    <article>
     <h3>概要</h3>
+    <br/>
+    <small>
     <p>従来, ウェブサービスはサーバーで処理, クライアントが結果を表示という方法を取ってきた.</p>
     <p>しかし, リクエストの増大によりスケーラビリティ確保が問題となっている．</p>
     <p>確保の方法としては，サーバーを分散させるだけでクライアントを有効活用しないことが多い．</p>
     <p>我々は, 非破壊木構造を用いてコンテンツを表現し push/pull 方式を用いて, コンテンツを管理する．</p>
-    <p>その方法を用いて分散コンテンツマネージメントシステムの開発を行った．</p>
+    <p>その方法を用いて分散コンテンツマネージメントシステムに必要である非破壊的木構造データベースのJungleの開発とその検証を行い, 分散データベースCassandraよりよい性能を得ることが出来た.</p>
+    </small>
    </article>
+
+	<!--
    
    <article>
     <h3>通常のウェブサービス</h3>
@@ -31,6 +36,8 @@
      <img style="height:200px" src="./images/ordinary_webservice.png"/>
     </p>
    </article>
+
+  -->
    
    <article>
     <h3>通常のウェブサービス</h3>
@@ -50,12 +57,13 @@
     <br/>
     <p>スケーラビリティを上げる方法は？</p>
     <ul style="color:red;text-weight:bold;">
-     <li>スケールアップ</li>
-     <li>スケールアウト</li>
+     <li>スケールアップ : 高価なサーバーを買う</li>
+     <li>スケールアウト : 安価なサーバーを複数用意して利用する</li>
     </ul> 
     <p>という2種類の方法がある.</p>
    </article>
-   
+
+<!--
    <article>
     <h3>スケールアップ</h3>
     <p>処理するサーバーをより高価なサーバーに交換すること.</p>
@@ -95,7 +103,9 @@
     <br/>
     <p style="color:red;">よって, まず分散コンテンツマネージメントシステムとは何か考えていく.</p>
    </article>
-   
+
+  --> 
+
    <article>
     <h3>コンテンツマネージメントシステム (CMS) </h3>
     <p>コンテンツマネージメントシステムとは, Webコンテンツを構成するテキストや画像などのデジタルコンテンツを管理するためのシステム.</p>
@@ -108,14 +118,17 @@
     </ul>
     <p>では, どのようにしてスケーラビリティを確保すれば良いのだろうか？</p>
    </article>
+
    
    <article>
     <h3>スケーラブルにするためには？</h3>
     <p>スケーラブルにするのは簡単ではなく, いくつかの弊害が存在する.</p>
     <p>弊害は, そのシステムの要求する性質によって変化する.</p>
     <br/>
-    <p>例えば, 分散データベースはデータの整合性が大事であり, 実現するためにはどのような方法があるか？</p>
+    <p>例えば, 銀行のシステムはデータの整合性が大事で, ある場所から預金されたお金が別の場所から見えない状態は起きてはならない.</p>
    </article>
+
+<!--
    
    <article>
     <h3>データを他の全ノードに通知する.</h3>
@@ -151,6 +164,8 @@
     <br/>
     <p>では, コンテンツマネージメントシステムではどうだろうか？</p>
    </article>
+
+-->
    
    <article>
     <h3>コンテンツマネージメントシステムでの整合性</h3>
@@ -164,7 +179,7 @@
    <article>
     <h3>スケーラブルにするためには？</h3>
     <p>以上の事柄より次の方法が考えられる.</p>
-    <ul>
+    <ul style="color:red;">
      <li>データの更新を受けたノードが一定時間ごとに, 他のノードへ通知する. 最新データは自分のみに書き込む</li>
      <li>ノードは一定時間ごとに他のノードから更新がないかチェックし, リクエストを受けたときは自分の保持するデータを利用する</li>
     </ul>
@@ -197,6 +212,8 @@
      <img style="height:350px" src="./images/nondestructive_tree_modification.png"/>
     </p>
    </article>
+
+<!--
    
    <article>
     <h3>非破壊的木構造</h3>
@@ -224,6 +241,21 @@
      <img style="height:350px" src="./images/nondestructive_tree_modification_step3.png"/>
     </p>
    </article>
+
+-->
+
+   <article>
+    <h3>非破壊的木構造</h3>
+    <br/>
+    <small>
+    <p>編集対象までパス上に存在するノードをルートノードに向かって, コピーする. 編集対象のノードはコピーする際にAとしてコピーする</p>
+    <p>コピーしたノードに一つ前にコピーしたノードを子供として追加する.</p>
+    <br/>
+    <p style="text-align:center">
+     <img style="height:350px" src="./images/nondestructive_tree_modification_short.png"/>
+    </p>
+    </small>
+   </article>
    
    <article>
     <h3>非破壊的木構造</h3>
@@ -248,7 +280,7 @@
    <article>
     <h3>Push/Pull方式</h3>
     <p>Push/Pull方式とは, </p>
-    <ul>
+    <ul style="color:red;">
      <li>データを定期的にまとめて通知するPush処理</li>
      <li>データを定期的に更新するPull処理</li>
     </ul>
@@ -257,23 +289,17 @@
     <p>非破壊的木構造をPush/Pullすることで, 分散しているコンテンツマネージメントシステムに通知する.</p>
     <p>この方式は, 分散バージョン管理システムでも利用されている.</p>
    </article>
+
+<!--
    
-   <article>
-    <h3>マージ処理</h3>
-    <p>Push/Pull方式を採用した場合, Push先またはPull先の木構造と更新が衝突するおそれがある.</p>
-    <p>その場合は, 2つの木のマージを行う.</p>
-    <br/>
-    <br/>
-    <p style="text-align:center"/>
-     <img style="height:150px" src="./images/merge.png"/>
-    </p>
-   </article>
+
+-->
    
    <article>
     <h3>Push/Pull方式</h3>
     <p>この方式を用いることにより, 前述した</p>
     <br/>
-    <ul>
+    <ul style="color:red">
      <li>データの更新を受けたノードが一定時間ごとに, 他のノードへ通知する. 最新データは自分のみに書き込む</li>
      <li>ノードは一定時間ごとに他のノードから更新がないかチェックし, リクエストを受けたときは自分の保持するデータを利用する</li>
     </ul>
@@ -306,6 +332,8 @@
      <img style="height: 300px" src="./images/basic_architecture_clientside.png"/>
     </p>
    </article>
+
+<!--
    
    <article>
     <h3>分散コンテンツマネージメントシステムの設計</h3>
@@ -322,6 +350,8 @@
     </ul>
     </small>
    </article>
+
+-->
    
    <article>
     <h3>分散コンテンツマネージメントシステムの設計</h3>
@@ -333,23 +363,28 @@
    
    <article>
     <h3>非破壊的木構造データベースJungle</h3>
+    <br/>
+    <small>
     <p>JungleはJavaを用いて開発した非破壊的木構造データベースである. 以下に特徴を示す.</p>
     <ul>
      <li>複数の非破壊的木構造を定義できる.</p>
      <li>データベースは非破壊的木構造の編集履歴をすべて保持する.</p>
      <li>APIが通常の破壊的木構造のAPIと異なり, 非破壊的であることを意識できるようになっている.</p>
     </ul>
+    </small>
    </article>
    
    <article>
     <h3>非破壊的木構造データベースJungleの検証</h3>
-    <p>これまでに, 非破壊的木構造データベースJungleの概要やその利用方法について述べた.</p>
+    <br/>
+    <small>
     <p>次に我々は, Jungleの性能を検証するために, Cassandraと比較する.</p>
     <p>Cassandraとは, スケーラブルな分散KeyValueStoreデータベースである.</p>
     <br/>
     <p style="text-align:center"/>
      <img style="height: 150px" src="./images/apache-cassandra.gif"/>
     </p>
+    </small>
    </article>
    
    <article>
@@ -450,14 +485,13 @@
     <h3>非破壊的木構造データベースJungleの検証</h3>
     <br/>
     <small>
-    <p>サーバーとクラスタがそれぞれ2種類あるため, 本検証では合計4組み合わせの検証を行う</p>
+    <p>サーバーとクラスタがそれぞれ2種類あるため, 本検証では合計3組み合わせの検証を行う</p>
     <br/>
     <br/>
     <ul>
      <li>コア数の多いサーバー と VMWareクラスタ</li>
      <li>コア数の少ないサーバー と VMWareクラスタ</li>
-     <li>コア数の多いサーバー と KVMクラスタ</li>
-     <li>コア数の少ないサーバー と KVMクラスタ</li>
+     <li>KVMクラスタの検証結果 と VMWareクラスタの検証結果の比較</li>
     </ul>
     </small>
    </article>
@@ -475,7 +509,7 @@
       <th style="text-align:center;">書き込みの実験結果</th>
      </tr>
     </table>
-    <p>JungleがCassandraより僅かながら上回っているが, ノード数25のところで追いぬかれている部分もある.</p>
+    <p>JungleがCassandraより僅かながら上回っているが, ノード数25のところで追いぬかれている部分もある. Jungleは木構造がロックフリーなため高い性能が出ている</p>
     </small>
    </article>
    
@@ -500,7 +534,7 @@
     <h3>非破壊的木構造データベースJungleの検証</h3>
     <br/>
     <small>
-    <p>実験結果 : コア数の少ないサーバー と VMWareクラスタ (書き込み) </p>
+    <p>実験結果 : コア数の少ないサーバー と VMWareクラスタ</p>
     <table style="text-align:center;font-size:0.7em;"/>
      <tr>
       <td><img style="height:300px;" src="./images/write_4cores.png"/></td>
@@ -534,33 +568,16 @@
     <h3>非破壊的木構造データベースJungleの検証</h3>
     <br/>
     <small>
-    <p>実験結果 : コア数の多いサーバー と KVMクラスタ</p>
+    <p>実験結果 : VMWareクラスタ と KVMクラスタの比較</p>
     <table style="text-align:center;font-size:0.7em;"/>
      <tr>
-      <td><img style="height:300px;" src="./images/kvm_write_bldsv10.png"/></td>
+      <td><img style="height:300px;" src="./images/kvm_vmware_read_jungle_bldsv10.png"/></td>
      </tr>
      <tr>
-      <th style="text-align:center;">書き込みの実験結果</th>
+      <th style="text-align:center;">多コアサーバーを用いたJungleの読み込みの実験結果</th>
      </tr>
     </table>
-    <p>結果の推移の仕方はVMWareの検証と似ているが, 平均時間がVMWareより遅い結果が出ている.</p>
-    </small>
-   </article>
-   
-   <article>
-    <h3>非破壊的木構造データベースJungleの検証</h3>
-    <br/>
-    <small>
-    <p>実験結果 : コア数の多いサーバー と KVMクラスタ</p>
-    <table style="text-align:center;font-size:0.7em;"/>
-     <tr>
-      <td><img style="height:300px;" src="./images/kvm_read_bldsv10.png"/></td>
-     </tr>
-     <tr>
-      <th style="text-align:center;">読み込みの実験結果</th>
-     </tr>
-    </table>
-    <p>こちらの結果でも, 推移の仕方はVMWareの検証と似ているが, 平均時間がVMWareより遅い結果が出ている.</p>
+    <p>KVMの平均時間がVMWareより遅い結果が出ている. しかし, 結果の推移は似ているため, チューニングの問題と考えられる</p>
     </small>
    </article>
    
@@ -568,42 +585,24 @@
     <h3>非破壊的木構造データベースJungleの検証</h3>
     <br/>
     <small>
-    <p>実験結果 : コア数の少ないサーバー と KVMクラスタ</p>
-    <table style="text-align:center;font-size:0.7em;"/>
-     <tr>
-      <td><img style="height:300px;" src="./images/write_kvm_4cores.png"/></td>
-     </tr>
-     <tr>
-      <th style="text-align:center;">書き込みの実験結果</th>
-     </tr>
-    </table>
+    <p>検証結果の考察1</p>
+    <br/>
+    <ul>
+     <li>JungleとCassandraでは, Jungleのほうが僅かながら速いことが解った.</li>
+     <li>Cassandraはスケーラブルな分散データベースであり, Jungleと同様に自由にコピーを作成できるデータベースである.</li>
+     <li>よって, シングルノードでの検証において十分な速度が測定できたことから, マルチノード環境でもCassandra同様にスケールする可能性があることが分る</li>
+    </ul>
     </small>
    </article>
-   
+
    <article>
     <h3>非破壊的木構造データベースJungleの検証</h3>
     <br/>
     <small>
-    <p>実験結果 : コア数の少ないサーバー と KVMクラスタ</p>
-    <table style="text-align:center;font-size:0.7em;"/>
-     <tr>
-      <td><img style="height:300px;" src="./images/read_kvm_4cores.png"/></td>
-     </tr>
-     <tr>
-      <th style="text-align:center;">読み込みの実験結果</th>
-     </tr>
-    </table>
-    </small>
-   </article>
-   
-   <article>
-    <h3>非破壊的木構造データベースJungleの検証</h3>
+    <p>検証結果の考察2</p>
     <br/>
-    <small>
-    <p>検証結果の考察</p>
     <ul>
-     <li>JungleとCassandraでは, Jungleのほうが僅かながら速いことが解った.</li>
-     <li>しかし, 多コアサーバーと少ないコアのサーバーでは違いが同じであり. 台数効果を確認できなかった.</li>
+     <li>多コアサーバーと少ないコアのサーバーでは違いが同じであり. 台数効果を確認できなかった.</li>
      <li>多コアサーバーと少ないコアのサーバーでは, 利用しているCPUが同じであるため, 検証対象である掲示板システムを更にチューニングする必要があると思われる.</p>
      <li>VMWareとKVMの比較では, 結果の推移はVMWareと同様であるがKVMのほうが遅いことが確認できた.</li>
      <li>KVMには, 様々なIOに関するオブションが存在し, チューニングの余地が未だあると考えられる.</li>
@@ -619,11 +618,57 @@
      <li>本研究では, スケーラブルな分散コンテンツマネージメントシステムの開発するために, 非破壊的木構造とPush/Pull方式を用いた方法を提案した.</li>
      <li>実装では, システムでまず必要だと思われる非破壊的木構造のデータベースJungleの実装を行った.</li>
      <li>実装したJungleを分散データベースCassandraと比較するために簡易掲示板システムを構築した.</li>
-     <li>検証では, Cassandraより多少良い結果を得ることが出来たが, コア数での台数効果は確認できなかった.</li>
+     <li>検証では, Cassandra良い結果を得ることが出来た. Cassandraは分散データベースであるため, 分散したJungleの性能にも期待が持てる.</li>
      <li>VMWareクラスタとKVMクラスタの比較では, KVMクラスタでの結果がVMWwareより遅くIO関連のチューニングが必要であることが解った.</li>
     </ul>
     </small>
    </article>
+
+   <article>
+    <h3>今後の課題</h3>
+    <br/>
+    <small>
+     <p>メモリ使用量の問題</p>
+     <p>Jungleは非破壊的木構造データベースであるため, すべての木構造を保持する. </p>
+     <p>そのため, メモリ上に使われない木構造も居座ることになり, かつ, GCで掃除されることがない.</p>
+     <p>この問題を解決するために, ある程度使われなくなった木構造は外部に書き出す必要がある.</p>
+    </small>
+   </article>
+
+   <article>
+    <h3>今後の課題</h3>
+    <br/>
+    <small>
+     <p>KVMチューニングの問題</p>
+     <p>現在のKVMクラスタはVMWare程度の性能が出ていないのが検証からわかっている.</p>
+     <p>KVMにはvirtioなどのIO関連の設定が多数存在しており, それらのチューニングをする必要があると考えられる.</p>
+    </small>
+   </article>
+
+   <article>
+    <h3>今後の課題</h3>
+    <br/>
+    <small>
+     <p>永続化の問題</p>
+     <p>現在のJungleの実装では永続化が未実装である. </p>
+     <p>永続化は, Jungleのインターフェイスをファイルシステム用に実装することで, </p>
+     <p>ファイルシステム上に同様にして木構造のファイルを構築することができると考えられる</p>
+    </small>
+   </article>
+
+   <article>
+   </article>
+
+   <article>
+    <h3>マージ処理</h3>
+    <p>Push/Pull方式を採用した場合, Push先またはPull先の木構造と更新が衝突するおそれがある.</p>
+    <p>その場合は, 2つの木のマージを行う.</p>
+    <br/>
+    <br/>
+    <p style="text-align:center"/>
+     <img style="height:150px" src="./images/merge.png"/>
+    </p>
+   </article>
    
    <!--