Mercurial > hg > Papers > 2017 > tatsuki-master

comparison slide/slide.html @ 27:796c18a4aa0d

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
add slide
author tatsuki
date Sun, 12 Feb 2017 16:24:24 +0900
parents
children 222d98af3372
comparison
equal deleted inserted replaced
26:4365c210d1cb 27:796c18a4aa0d
1 <!DOCTYPE html>
2 <html>
3 <head>
4 <meta http-equiv="content-type" content="text/html;charset=utf-8">
5 <title>修論予備審査Slide</title>
6
7 <!--
8 Notes on CSS media types used:
9
10 1) projection -> slideshow mode (display one slide at-a-time; hide all others)
11 2) screen -> outline mode (display all slides-at-once on screen)
12 3) print -> print (and print preview)
13
14 Note: toggle between projection/screen (that is, slideshow/outline) mode using t-key
15
16 Questions, comments?
17 - send them along to the mailinglist/forum online @ http://groups.google.com/group/webslideshow
18 -->
19
20 <!-- styles -->
21 <style media="screen,projection">
22
23 html,
24 body,
25 .presentation { margin: 0; padding: 0; }
26
27 .slide { display: none;
28 position: absolute;
29 top: 0; left: 0;
30 margin: 0;
31 border: none;
32 padding: 2% 4% 0% 4%; /* css note: order is => top right bottom left */
33 -moz-box-sizing: border-box;
34 -webkit-box-sizing: border-box;
35 box-sizing: border-box;
36 width: 100%; height: 100%; /* css note: lets use border-box; no need to add padding+border to get to 100% */
37 overflow-x: hidden; overflow-y: auto;
38 z-index: 2;
39 }
40
41 .slide.current { display: block; } /* only display current slide in projection mode */
42
43 .slide .stepcurrent { color: black; }
44 .slide .step { color: silver; } /* or hide next steps e.g. .step { visibility: hidden; } */
45
46 .slide {
47 /*
48 background-image: -webkit-linear-gradient(top, blue, aqua, blue, aqua);
49 background-image: -moz-linear-gradient(top, blue, aqua, blue, aqua);
50 */
51 }
52 </style>
53
54 <style media="screen">
55 .slide { border-top: 1px solid #888; }
56 .slide:first-child { border: none; }
57 </style>
58
59 <style media="print">
60 .slide { page-break-inside: avoid; }
61 .slide h1 { page-break-after: avoid; }
62 .slide ul { page-break-inside: avoid; }
63 </style>
64
65
66 <!-- add js lib (jquery) -->
67 <script src="js/jquery-1.7.min.js"></script>
68
69 <!-- S6 JS -->
70 <script src="js/jquery.slideshow.js"></script>
71 <script src="js/jquery.slideshow.counter.js"></script>
72 <script src="js/jquery.slideshow.controls.js"></script>
73 <script>
74 $(document).ready( function() {
75 Slideshow.init();
76
77 // Example 2: Start Off in Outline Mode
78 // Slideshow.init( { mode: 'outline' } );
79
80 // Example 3: Use Custom Transition
81 // Slideshow.transition = transitionScrollUp;
82 // Slideshow.init();
83
84 // Example 4: Start Off in Autoplay Mode with Custom Transition
85 // Slideshow.transition = transitionScrollUp;
86 // Slideshow.init( { mode: 'autoplay' } );
87 } );
88 </script>
89
90 </head>
91 <body>
92 <div class="layout">
93 <div id="header"></div>
94 <div id="footer">
95 <div align="right">
96 <img src="image/concurrency.png" width="200">
97 </div>
98 </div>
99 </div>
100
101 <div class="presentation">
102
103 <!-- add slides here; example -->
104 <div id="header">
105
106 <tr>
107 <td><div align="center">
108 <h1><font color="#808db5">ソフトウェア内部で使用するのに適した木構造データベースJungle</font></h1>
109 <h2>琉球大学大学院　情報工学専攻 修士2年次　金川竜己</h2>
110 <p>Feb 13, 2017</p>
111 </div></td>
112 </tr>
113 </div>
114
115 <div>
116 <h1>研究の背景と目的</h1>
117 <font size=5>
118 <p>プログラムからデータを分離して扱うデータベースには、プログラム中のデータ構造と表構造とのミスマッチという問題がある。</p>
119 <p>データベースのレコードをプログラム中のオブジェクトとして使えるOR Mapperや、データベース自体も、表に特化したKey Value Storeや、Jsonなどの不定形のデータ構造を格納するように機能拡張されてきている。</p>
120 <p>しかし、プログラム中のデータは複雑な構造をメモリ上に構築しており、これらの方法でもまだギャップがある。</p>
121 </font>
122 </div>
123
124 <!--
125 <div>
126 <h1>インピータンスミスマッチ</h1>
127 <font size=5>
128 <p>プログラム中のデータ構造とRDBの表構造には大きなギャップがある。これはインピーダンスミスマッチと呼ばれている。</p>
129 <p>例えばRPGゲーム中のユーザが持つアイテムという単純なものでも、RDBではユーザとアイテムの組をキーとする巨大な表として管理することになる。</p>
130 <p>プログラム中では、ユーザが持つアイテムリストという簡単な構造を持つが、データのネスト構造を許さない第一正規形を要求するRDBとは相容れない。</p>
131 </font>
132 </div>
133 -->
134
135
136 <div>
137 <h1>既存のDBが持つ問題点</h1>
138 <font size=5>
139 <p>MySQLやPosgreSQLなどは、Jsonなどの不定形のデータ構造を格納するように機能拡張されるようになってきた。</p>
140 <p>しかし、不定形の構造の変更をトランザクションとして、どのように処理するかはJsonの一括変更という形で処理されてしまっており、
141 並列処理が中心となってきている今のアプリケーションには向いていない。</p>
142 <p>この拡張はRDBよりの拡張であり、
143 並列処理を含むプログラミングからの要請とのミスマッチが残っている。</p>
144
145 </font>
146 </div>
147
148 <div>
149 <h1>既存のDBが持つ問題点</h1>
150 <font size=5>
151 <p>データベース自体も、表に特化したKey Value Storeや、Jsonなどの不定形のデータ構造を格納するように機能拡張されてきている。</p>
152 <p>その例としてCassandraや、mongoDBが挙げられる。</p>
153 <p>しかし、プログラム中のデータは複雑な構造をメモリ上に構築しており、これらの方法でもまだギャップがある。</p>
154 </font>
155 </div>
156
157
158 <div>
159 <h1>非破壊的木構造データベースJungle</h1>
160 <font size=5>
161 <p>当研究室ではこれらの問題を解決するために木構造Jungleデータベースを提案している。</p>
162 <p>Jungleは様々な構造のデータ(例えばXML/JSON/LIST)を木構造としてそのまま格納することが可能である。</p>
163 <p>Jungleではデータの変更を非破壊的、つまり元の木を保存しつつ、新しい木を構築する方法をとる。</p>
164 <p>これにより木を参照しながら処理するタスクと木を変更するタスクを並列に処理することができる。</p>
165 <p>プログラムは、この木を変更されないデータ構造として直接取り扱うことができる。</p>
166 <p>名前付きの複数の木をatomicに入れ替えるのがJungleの transactionとなる。</p>
167 </font>
168 </div>
169
170
171 <div>
172 <h1>Jungleの構造</h1>
173 <font size=5>
174 <p>木は複数のノードの集合でできており、その木の集合によりJungleが構成されている。</p>
175 <p>ノードは自身の子のリストと属性名と属性値の組でデータを持つ。これはデータベースのレコードに値する。</p>
176 <p>通常のレコードと異なり、ノードは自身の子供を持つ。</p>
177 <p>親から子への片方向の参照しか持たない。</p>
178 <embed src="../figures/multiComponent.pdf" width="800" height="500"/>
179 </font>
180 </div>
181
182 <div>
183 <h1>JungleのTransaction</h1>
184 <font size=5>
185 <p>データの変更は一度生成した木を上書きせず、ルートから変更を行うノードまでコピーを行い、新しく木構造を構築する。最後にルートをアトミックに入れ替えてコミットする。コミットが失敗した場合は最初からやり直す。</p>
186 <embed src="../figures/non_destructive_tree.pdf" width="800" height="500"/>
187 </font>
188 </div>
189
190 <div>
191 <h1>Jungleの木</h1>
192 <font size=5>
193 <p>Jungleは木を名前で生成、管理している。</p>
194
195 <div style="padding: 10px; margin-bottom: 10px; border: 5px double #333333;">
196 <pre><code class="language-Java">
197 // Jungleに新しく木を生成する。木の名前が重複した場合、生成に失敗しnullを返す
198 JungleTree createNewTree(String treeName)
199
200 // JungleからtreeNameと名前が一致するtreeを取得する。名前が一致するTreeがない場合取得は失敗しnullを返す
201 JungleTree getTreeByName(String treeName)
202 </code></pre>
203 </div>
204
205 </font>
206 </div>
207
208
209 <div>
210 <h1>Jungleの木の編集</h1>
211 <font size=5>
212 <p>Jungleの木の編集はJungleTreeEditorクラスを用いて行われる。</p>
213
214 <p>JungleTreeEditorクラスには編集を行うためのAPIが実装されている。</p>
215
216 <p>また、ノードを指定して編集を行う際には、NodePathクラスを用いる。</p>
217
218 <p>木の編集を行った後は、Commitを行い変更をPushする必要がある。</p>
219 </font>
220 </div>
221
222
223 <div>
224 <h1>NodePath</h1>
225 <font size=5>
226 <p>Jungleでは木のノードの位置をNodePathを使って表す。</p>
227 <p>ルートから対象のノードまでの経路を数字で指し示す。</p>
228 <p>ルートノードは例外として-1と表記される。</p>
229 <p>NodePathクラスを用いて[-1,1,2,3]を表している例を以下に貼る。</p>
230 <embed src="../figures/nodepath.pdf" width="800" height="500"/>
231 </font>
232 </div>
233
234
235
236
237 <div>
238 <h1>JungleTreeEditorのAPI</h1>
239 <font size=5>
240 <p>JungleTreeEditorが提供している木の編集APIを以下に記す。</p>
241 <div style="padding: 10px; margin-bottom: 10px; border: 5px double #333333;">
242 <pre><code class="language-Java">
243
244 </code></pre>
245 </div>
246
247 </font>
248 </div>
249
250
251
252 <div>
253 <h1>Jungleの検索機能</h1>
254 <font size=5>
255 <p>Jungleの木への検索は、木の走査を行うTraverserクラス内に実装してある。</p>
256
257 <p>属性名key 属性値valueの組を使用して検索を行う。</p>
258
259 <p>以下に検索を行う関数findの定義を記述する。</p>
260
261 <div style="padding: 10px; margin-bottom: 10px; border: 5px double #333333;">
262 <pre><code class="language-Java">public Iterator&lt;TreeNode&gt; find(Query query, String key, String value);
263 </code></pre>
264 </div>
265
266 <p>関数findは引数に、Query query、String key、String valueの3つの引数を取り、条件に一致したノードのIteratorを返す。</p>
267
268 <p>第1引数には、探索の条件を記述する関数boolean comdition(TreeNode)を定義したInterface Queryを、第2、第3引数の、String key、String valueはIndexを用いた絞込みに使用する。</p>
269
270
271 </font>
272 </div>
273
274 <div>
275 <h1>Jungleの問題点</h1>
276 <font size=5>
277 <p>これまでに記述したAPIにより、Jungleはデータの書き込み、読み込みを行える。</p>
278 <p>しかし、性能はあまり良いものではなかった。</p>
279 <p>特にIndexを用いた検索が明らかに遅く、検索の手間がO(n^2)となっていた。</p>
280 <p>本来ならIndexを使った場合の検索の手間はO(Log n)であるべきである。</p>
281 </font>
282 </div>
283
284
285 <div>
286 <h1>JungleのIndexが遅い原因</h1>
287 <font size=5>
288 <p>Jungle では、今まで Java 上で関数型プログラミングが行えるライブラリ、Functional Java の TreeMap を使用して、Index を実装していた。</p>
289 <p>しかし、Functional Java の TreeMap は、採用しているアルゴリズムが悪かった。</p>
290 <p>またコードの量も膨大であり、修正も困難だった。</p>
291 <p>そこで、自分で、同じ機能を持つ 非破壊 TreeMap を実装することにした。</p>
292 <p>TreeMap アルゴリズムは赤黒木を採用した。</p>
293 </font>
294 </div>
295
296
297 <div>
298 <font size=5>
299 <h1>Indexに非破壊TreeMapを採用している理由</h1>
300 <p>Jungleは過去の版の木を全て保持している。</p>
301 <p>過去の木に対する検索もサポートしている。</p>
302 <p>木の版毎にIndexを持っている必要がある</p>
303 <p>破壊的TreeMapでは、木に更新が入るたびに新しいIndexを作り直す必要がある。</p>
304 <p>Indexの更新の手間がO(n)になってしまう。</p>
305 <p>非破壊TreeMapの場合、一度作られたTreeMapに対して編集を行うと、編集後のTreeMapを返す。</p>
306 <p>その際、編集前のTreeMapのデータは破壊されることはない。</p>
307 <p>また、過去のIndexとデータを共有している</p>
308 <p>複数のversionのIndexがあっても、データの差分しかメモリは消費されない</p>
309 <p>メモリの使用量を抑えつつ複数のversionでIndexを保持できる</p>
310 </font>
311 </div>
312
313
314 <div>
315 <h1>赤黒木とは</h1>
316 <font size=5>
317 <p>赤黒木とは、二分探索木の一つで、以下の条件を満たした木のことである</p>
318 <ul>
319 <li>全てのノードは赤か黒の色を持つ</li>
320 <li>ルートノードの色は黒</li>
321 <li>全ての葉の色は黒</li>
322 <li>赤いノードの子の色は黒</li>
323 <li>全ての葉からルートまでの経路には同じ個数の黒いノードがある</li>
324 </ul>
325 <p>赤黒木は、上記の条件を満たしている限りデータの検索、削除、探索をO(Log n)で行える。</p>
326 </font>
327 </div>
328
329 <div>
330 <h1>Jungleの問題点2</h1>
331 <font size=5>
332 <p>非破壊のTreeMapを実装したことにより、読み込みは極めて高速に行えるようになった。</p>
333 <p>しかし、書き込みに関してはまだ十分な速度が出ていない。</p>
334 <p>Jungleの木の編集時に特に問題になっているのは、主に次の三点である。</p>
335 <ul>
336 <li>Indexの更新が、毎回フルアップデートしているため更新の手間がO(n)となっている。</li>
337 <li>線形の木を更新する際、Jungleは全てのノードの複製を取ってしまうため、更新の手間がO(n)となってしまう</li>
338 <li>木のノード数が増えると、バランスが取れていない場合木の更新が重くなる。</li>
339 </ul>
340 <p>以降これらの問題について述べていく。</p>
341 </font>
342 </div>
343
344 <div>
345 <h1>Indexの差分アップデート</h1>
346 <font size=5>
347 <p>JungleではIndexの更新を行う際、毎回新しいIndexを構築していた。</p>
348 <p>その為、毎回O(n)のIndexの更新が入っていた。</p>
349 <p>Indexの差分アップデートを実装することで、Indexの更新の手間をO(Log n)とする。</p>
350 </font>
351 </div>
352
353 <div>
354 <h1>Indexの差分アップデートの実装</h1>
355 <font size=5>
356 <p>Jungleは木の編集を行う際、編集を行うノードからルートまでの経路のノードの複製を行う。</p>
357 <p>そのため、編集後の木には存在しない、複製前のノードがIndexに残ってしまう。</p>
358 <p>それらのノードをIndexから削除し、複製後のノードを登録する必要がある。</p>
359 <embed src="../figures/non_destructive_tree.pdf" width="800" height="500"/>
360 <p>この図だと、Indexの更新時にroot、2、5をIndexから削除する必要がある。</p>
361 <p>その後新しく作られたノードを登録することでIndexの更新は完了する</p>
362 </font>
363 </div>
364
365 <div>
366 <h1>複製前のノードのdelete</h1>
367 <font size=5>
368 <p>複製前のノードをIndexから削除するためには、編集を行ったノードを覚えておく必要がある。</p>
369 <p>Editorの中に編集を加えたノードを格納するリストを定義した。</p>
370 <p>Indexのアップデート時にリストを使用する。</p>
371 </font>
372 </div>
373
374
375 <div>
376 <h1>複製前のノードのdelete</h1>
377 <font size=5>
378 <p>複製前のノードは以下の手順で行われる。</p>
379 <ol>
380 <li>編集を行ったノードのリストからノードを取得する。</li>
381 <li>取得したノードが、保持している値をIndexから削除する。 </li>
382 <li>自身と子供のペアを ParentIndex から削除する。</li>
383 <li>ParentIndexから自身の親を取得する。</li>
384 <li>2 - 4 をルートノードにたどり着くか、ParentIndex から親を取得できなくなるまで続ける。 </li>
385 <li>1 - 5 をリストからノードが無くなるまで続ける。</li>
386 </ol>
387 </font>
388 </div>
389
390 <div>
391 <h1>編集前のノードのdeleteの例1</h1>
392 <font size=5>
393 <p>ノードD、Eを編集した後の、複製前のノードをIndexから削除する例を記述する。</p>
394 <p>黒のノードは編集後の木に存在しないノード。</p>
395 <p>赤のノードはIndexから削除が終了したノード。</p>
396 <p>その他のノードは緑とする。</p>
397 <br>
398 <p>編集前ノードのDelete前</p>
399 <embed src="../figures/indexUpdate.pdf" width="800" height="500"/>
400 </font>
401 </div>
402
403 <div>
404 <h1>編集前のノードのdeleteの例2</h1>
405 <font size=5>
406 <p>ノードDについての削除後</p>
407 <embed src="../figures/indexUpdate2.pdf" width="800" height="500"/>
408 </font>
409 </div>
410
411 <div>
412 <h1>編集前のノードのdeleteの例3</h1>
413 <font size=5>
414 <p>ノードEについての削除後</p>
415 <embed src="../figures/indexUpdate3.pdf" width="800" height="500"/>
416 <p>このようにIndexからのノードの削除は行われる</p>
417 </font>
418 </div>
419
420
421 <div>
422 <h1>ノードのIndexへの追加</h1>
423 <font size=5>
424 <p>Indexへのノードは以下の手順で行われる。</p>
425 <ol>
426 <li>木からルートノードを取得する。</li>
427 <li>取得したノードがIndexに登録されているかを調べる。</li>
428 <li>登録されている場合、そのノード以下のSubTreeは、全てIndexに登録されているので、次のノードに移動する。</li>
429 <li>登録されていなかった場合、自身が保持している値をIndexに登録する。</li>
430 <li>自身と子ノードを Parent Index に登録する。</li>
431 <li>自身の子ノードを取得したノードとして2に戻る。</li>
432 <li>全てのノードを登録したら終了する。</li>
433 </ol>
434 <p>ノードの登録は深さ優先探索と同じ順序で行っていく。</p>
435 </font>
436 </div>
437
438 <div>
439 <h1>ノードのIndexへの追加例</h1>
440 <font size=5>
441 <p>ノードD、Eを編集した後の、複製前のノードをIndexから削除する例を記述する。</p>
442 <p>赤のノードはIndexに存在しないノード。</p>
443 <p>緑のノードはIndexに追加されているノード。</p>
444 <br>
445 <p>以下の図の場合、A、B，D、Eの順に登録され、Cで終了する。</p>
446 <embed src="../figures/indexUpdate3.pdf" width="800" height="500"/>
447
448 </font>
449 </div>
450
451
452 <div>
453 <h1>線形の木の構築</h1>
454 <font size=5>
455 <p>Jungleは木の編集時、ルートから編集を行う位置までのノードの複製を行う。</p>
456 <p>そのため、木の編集の手間は木構造の形によって異なる。</p>
457 <p>特に線形の木の場合、全てのノードの複製を行うため変更の手間がO(n)となってしまう。</p>
458 <p>Jungleは線形の木をO(1)で変更するPushPopの機能を持つ。</p>
459 </font>
460 </div>
461
462 <div>
463 <h1>PushPop</h1>
464 <font size=5>
465 <p>PushPopはルートノードの上に新しいルートを追加するAPIである。</p>
466 <p>しかし、PushPopで構築した木は逆順になってしまう。</p>
467 <p>そのため、正順の木を構築する際は使用できない。</p>
468 <embed src="../figures/PushPopDemerit.pdf" width="800" height="500"/>
469 </font>
470 </div>
471
472 <div>
473 <h1>Differential Jungle Tree</h1>
474 <font size=5>
475 <p>正順の木をO(1)で構築するために実装した。</p>
476 <p>Differential Jungle Treeは木のバージョン毎に自身の木の最後尾のノードを持つ。</p>
477 <embed src="../figures/findDifTree.pdf" width="800" height="500"/>
478 <p></p>
479 </font>
480 </div>
481
482 <div>
483 <font size=6>
484 <h1>Differential Jungle Treeの作成</h1>
485 <p>Differential Jungle Treeを作成するためにJungleに新しいAPIを実装した。</p>
486 <div style="padding: 10px; margin-bottom: 10px; border: 5px double #333333;">
487 <pre><code class="language-Java"> JungleTree createNewDifferenceTree(String treeName);
488 </code></pre>
489 </div>
490 <p>上記のAPIは、treeNameで指定した名前のDifferential Jungle Treeを構築する。</p>
491 </font>
492 </div>
493
494 <div>
495 <font size=6>
496 <h1>Differential Jungle Treeの編集</h1>
497 <p>Differential Jungle Treeの木の編集は、Differential Jungle Tree Editorを用いて行う。</p>
498 <p>既存のDefault Jungle Treeは、木の複製を作った後編集を行う。</p>
499 <p>Differential Jungle Tree Editorは、自身がSub Treeを持っている。</p>
500 <p>Sub Tree に対して編集を行う。</p>
501 <p>Commit時に自身が保持している末尾ノードにSub TreeをAppendすることで木の編集を終了する。</p>
502 <p>また、Diffirential Jungle Treeの編集は、Editorが持つSub Treeへの編集しか行えないため、一度Commitした木に対して変更を加えることはできない。</p>
503 </font>
504 </div>
505
506 <div>
507 <font size=6>
508 <h1>Differential Jungle Treeの編集の例</h1>
509 <p>Differential Jungle Treeの編集例を以下の図に記す。</p>
510 <embed src="../figures/EditDifferencialTree.pdf" width="800" height="500"/>
511 <p></p>
512 </font>
513 </div>
514
515 <div>
516 <font size=6>
517 <h1>Differential Jungle Treeの検索</h1>
518 <p>Differential Jungle Treeは末尾ノードを使って現在の木構造を表現している。</p>
519 <p>過去の木に対してIndexを使わないで全探索を行った場合、既存の検索ではその版に存在しないはずのノードが取得できてしまう。</p>
520 <embed src="../figures/findDifTree.pdf" width="800" height="500"/>
521 </font>
522 </div>
523
524 <div>
525 <font size=6>
526 <h1>Differential Jungle Treeの検索例</h1>
527 <p>以下の図の場合Tree Ver1を全探索すると、存在しないはずのノード３、４が取得できてしまう。</p>
528 <embed src="../figures/findDifTree.pdf" width="800" height="500"/>
529 </font>
530 </div>
531
532 <div>
533 <font size=6>
534 <h1>Differential Interface Traverserの実装</h1>
535 <p>この問題を解決するためにDifferential Interface Traverserを実装した。</p>
536 <p>これは、末尾ノード以下を検索対象から取り除く検索を持つ。</p>
537 <p>Indexを使った検索の場合、各版ごとに独立したIndexを持つため、Default Jungle Treeと同じ検索でも問題ない。</p>
538 </font>
539 </div>
540
541 <div>
542 <font size=6>
543 <h1>Differential Jungle Treeの整合性</h1>
544 <p>Default Jungle TreeへCommitは編集後の木のルートをAtomicに入れ替えることで行う。</p>
545 <p>しかしDifferential Jungle Treeは、ルートの入れ替えと、Editorが持つ木構造の末尾ノードへのAppendの２つのプロセスからなる。</p>
546 <p>ルートの入れ替えに関しては、Default Jungle Treeと同じように行う。</p>
547 <p>Editorが持っている木構造の末尾ノードへのAppendは、ルートの入れ替えに成功した場合のみ行う。</p>
548 <p>そうすることで、別Threadで行われているCommitと競合した際に、ルートを入れ替えたThreadと別ThreadがAppendを行い木の整合性が崩れることを回避している。</p>
549 </font>
550 </div>
551
552 <div>
553 <font size=6>
554 <h1>Differential Jungle Treeの整合性2</h1>
555 <p>Differential Jungle Treeでは、過去の版の木に対して変更を加えた際に木の整合性が崩れてしまう問題もある。</p>
556 <p>図の中の、過去の木であるTree ver1に対してノード5を追加してCommitした場合、新しい木Tree ver`2が生成される。</p>
557 <embed src="../figures/badDifTree3.pdf" width="800" height="500"/>
558
559 </font>
560 </div>
561
562 <div>
563 <font size=6>
564 <h1>Differential Jungle Treeの整合性3</h1>
565 <p>Tree ver`2に対してIndexを使わないで検索を行った場合、本来存在しないはずのノード3、４が検索対象に入ってしまう。</p>
566 <p>これは、Tree ver1の末尾ノードが2つ子を持っているせいで発生する。</p>
567 <p>この問題を解決するために、過去の木に対する変更は禁止した。</p>
568 <embed src="../figures/badDifTree2.pdf" width="800" height="500"/>
569 </font>
570 </div>
571
572 <div>
573 <font size=6>
574 <h1>Jungle上での巨大な木の扱い。</h1>
575 <p>Jungleは木の編集時、ルートから編集を行う位置までのノードの複製を行う。</p>
576 <p>そのため、木の編集の手間は木構造の大きさにも依存している。</p>
577 <p>バランスの取れた木構造を構築することで、編集の手間をO(Log n)にすることは可能ではある。</p>
578 <p>しかし、ユーザーが木の構造を把握しバランスを取るのは難しい。</p>
579 <p>そこで、自動で木のバランスを取り、最適な木構造を構築する機能を持つRed Black Jungle Treeを実装した。</p>
580 <p>Red Black Jungle Treeは、自動でバランスを取ってしまうため、木構造の形でデータを表現することはできない。</p>
581 </font>
582 </div>
583
584 <div>
585 <font size=6>
586 <h1>Red Black Jungle Treeの作成</h1>
587 <p>Red Black Jungle Treeを作成するためにJungleに新しいAPIを実装した。</p>
588 <div style="padding: 10px; margin-bottom: 10px; border: 5px double #333333;">
589 <pre><code class="language-Java"> JungleTree createNewRedBlackTree(String treeName,String balanceKey);
590 </code></pre>
591 </div>
592 <p>上記のAPIは、treeNameで指定した名前のRed Black Jungle Treeを構築する。</p>
593 <p>また、第二引数のbalanceKeyを用いて木のバランスを取る。</p>
594 <p>第二引数のbalanceKeyを使用して、検索することでO(Log n)で検索を行うことができる。</p>
595 <p>なので、別途Indexを構築する必要はない。</p>
596 </font>
597 </div>
598
599
600 <div>
601 <font size=6>
602 <h1>NodePathの拡張</h1>
603 <p>Red Black Jungle Treeは、ノードを追加、削除するたびに木のバランスが行われるため、各ノードのPathが変わってしまう。</p>
604 <p>その為、編集を加える際に、編集対象のノードのPathを調べる必要がある。</p>
605 <p>その問題を解決するために、ノードを数値ではなく属性名と属性値の組でノードを指定できるようにした。</p>
606 <p>ノードの指定に使用する属性名は、Red Black Jungle Treeの第二引数で指定したbalanceKeyを使用する必要がある。</p>
607 </font>
608 </div>
609
610 <div>
611 <font size=6>
612 <h1>Red Black Jungle Treeの検索</h1>
613 <p>Red Black Jungle TreeはIndexを持たないため既存の検索は使用できない。</p>
614 <p>木の生成時に指定したbalanceKeyを使用して、O(Log n)で探索を行う検索を実装した。</p>
615 <p>また、balanceKeyを使用しない場合は、既存のDefault Jungle Treeと同じで全探索を行うのでO(n)となる。</p>
616 </font>
617 </div>
618
619
620
621 <div>
622 <font size=6>
623 <h1>新たに追加した要素の評価</h1>
624 <p>Jungleに新しく追加した機能の性能測定を行う。</p>
625 <p>新しく実装したTreeMapとFunctionalJavaのTreeMap</p>
626 <p>IndexのFullアップデートと差分アップデート</p>
627 <p>Default Jungle TreeとDefferential Jungle Tree</p>
628 <p>Default Jungle Tree と Red Black Jungle Tree</p>
629 <p>最後に既存のDBであるPostgreSQLとMongoDBとJungleの比較を行う。</p>
630 </font>
631 </div>
632
633
634
635 <div>
636 <font size=6>
637 <h1>TreeMapの測定</h1>
638 <p>比較対象には、 TreeMap 実装前に Jungle で使用していた Functional Java の TreeMap を使用する。</p>
639 <p> TreeMap に1000回の Get を行った際のグラフである。</p>
640 <!--
641 <p>X 軸は Get を行う TreeMap のノード数。</p>
642 <p>Y 軸は Get にかかった時間を表す。</p>
643 -->
644 <embed src="../result/treemap/find.pdf" width="800" height="500"/>
645 </font>
646 </div>
647
648
649
650 <div>
651 <font size=6>
652 <h1>TreeMapの測定の考察</h1>
653 <p>新たに実装したTreeMapの方が極めて高速な検索を行えている。</p>
654 <p>理由として、JungleのTreeMapは二分探索木の探索アルゴリズムで探索するのに対して、Functional Javaは検索対象のノードがルートになる木を再構築し、ルートを返すといったアルゴリズムのを採用しているからである</p>
655 <p>また、データのInsertは、ほぼ同じ速度、DeleteはJungleの方が極めて高速に行えていた。</p>
656 </font>
657 </div>
658
659 <div>
660 <font size=6>
661 <h1>Indexの差分アップデートの測定</h1>
662 <p>比較対象は、IndexのFullアップデートとする。</p>
663 <p>測定は木にノードを追加、Commitを1 セットの変更として行う。</p>
664 <!--
665 <p>X 軸は、木に行った変更のセット数。</p>
666 <p>Y 軸は、木の構築にかかった時間を表す。</p>
667 -->
668 <embed src="../result/createIndex.pdf" width="800" height="500"/>
669 </font>
670 </div>
671
672 <div>
673 <font size=6>
674 <h1>Indexの差分アップデートの測定の考察</h1>
675 <p>IndexのFullアップデートに比べて差分Updateの方が高速に木の構築に成功している。</p>
676 <p>期待通りの性能が出たといえる。</p>
677 </font>
678 </div>
679
680 <div>
681 <font size=6>
682 <h1>正順の線形木の構築時間の測定</h1>
683 <p>Differential Jungle Treeの性能測定を行う。</p>
684 <p>比較対象はDefault Jungle Treeを選択した。</p>
685 <p>また、木の構築時間を測るためにIndexを構築していない。</p>
686 <!--
687 <p>X軸は構築した木のノード数。</p>
688 <p>Y 軸は構築にかかった時間を表す。</p>
689 -->
690 <embed src="../result/createListTree.pdf" width="800" height="500"/>
691 </font>
692 </div>
693
694 <div>
695 <font size=6>
696 <h1>正順の線形木の構築時間の考察</h1>
697 <p>Commit毎に全てのノードの複製を行うDefault Jungle Treeに比べて、木の複製を行わないDifferential Jungle Treeが早いのは当然だといえる。</p>
698 <p>期待通りの性能が出た。</p>
699 </font>
700 </div>
701
702 <div>
703 <font size=6>
704 <h1>Red Black Jungle Tree の測定</h1>
705 <p>比較対象は、Default Jungle Treeを選択した。</p>
706 <embed src="../result/createRedBlackTreeAndDefaultTreeTime.pdf" width="800" height="500"/>
707 </font>
708 </div>
709
710 <div>
711 <font size=6>
712 <h1>Red Black Jungle Tree の測定の考察</h1>
713 <p>Red Black Jungle Treeは自身の木の形がIndexと同じ働きを持っている。</p>
714 <p>なのでIndexを木の編集時作る必要がない。</p>
715 <p>Commit のたびにIndexを作っているDefault Jungle Treeより早くなるのは当然だといえる。</p>
716 <p>期待通りの性能が出た。</p>
717 </font>
718 </div>
719
720 <div>
721 <font size=6>
722 <h1>既存のDBとJungleの比較</h1>
723 <p>比較対象はMongoDBとPostgreSQLを選択した。</p>
724 <p>PostgreSQLはJson形式でデータを格納している。</p>
725 <p>データの検索速度を比較した。</p>
726 <embed src="../result/comparedb.pdf" width="800" height="500"/>
727 </font>
728 </div>
729
730 <div>
731 <font size=6>
732 <h1>既存のDBとJungleの比較の考察</h1>
733 <p>MongoDBとPostgreSQLは、プログラム外にあるデータベースに通信を用いてアクセスしている。</p>
734 <p>Jungleは、メモリの中にデータを持ち通信を使わずデータにアクセスできる。</p>
735 <p>期待通りの性能が出た。</p>
736 </font>
737 </div>
738
739
740
741 <div>
742 <font size=6>
743 <h1>まとめ</h1>
744 <p>Jungleの性能を向上させるために新たな要素を追加した。</p>
745 <ol>
746 <li>非破壊TreeMap</li>
747 <li>Indexの差分アップデート</li>
748 <li>Differential Jungle Tree</li>
749 <li>Red Black Jungle Tree</li>
750 </ol>
751 <p>実装後の測定では、全てが既存の木と比べて高速に動いていた。</p>
752 <p>また、Jungleは既存のDBと比較しても、極めて高速な検索が行えることがわかった。</p>
753 </font>
754 </div>
755
756
757 <div>
758 <font size=6>
759 <h1>今後の課題</h1>
760 <h2>木の設計手法の確立</h2>
761 <p>JungleはRDB と異なり格納するデータの自由度は大きい。</p>
762 <p>どのようなデータ構造も設計を行わずに格納することが可能である。</p>
763 <p>十分なパフォーマンスを出すためには、データを最適化する必要がある。</p>
764 <p>最適な木構造はアプリケーションによって違うため、Jungle の設計手法を確立させる必要がある。</p>
765 </font>
766 </div>
767
768
769
770 </div>
771
772
773
774 </div>
775
776 </div> <!-- presentation -->
777 </body>
778 </html>