Mercurial > hg > Papers > 2017 > tatsuki-master
changeset 28:222d98af3372
commit
author | tatsuki |
---|---|
date | Sun, 12 Feb 2017 18:09:55 +0900 |
parents | 796c18a4aa0d |
children | 92d6882c1143 |
files | slide/.slide.html.swo slide/slide.html |
diffstat | 2 files changed, 101 insertions(+), 281 deletions(-) [+] |
line wrap: on
line diff
--- a/slide/slide.html Sun Feb 12 16:24:24 2017 +0900 +++ b/slide/slide.html Sun Feb 12 18:09:55 2017 +0900 @@ -113,62 +113,75 @@ </div> <div> -<h1>研究の背景と目的</h1> +<h1>データベースとプログラム中のデータ構造のミスマッチ</h1> <font size=5> -<p>プログラムからデータを分離して扱うデータベースには、プログラム中のデータ構造と表構造とのミスマッチという問題がある。</p> -<p>データベースのレコードをプログラム中のオブジェクトとして使えるOR Mapperや、データベース自体も、表に特化したKey Value Storeや、Jsonなどの不定形のデータ構造を格納するように機能拡張されてきている。</p> -<p>しかし、プログラム中のデータは複雑な構造をメモリ上に構築しており、これらの方法でもまだギャップがある。</p> +<p>プログラム中のデータ構造には、構造体、オブジェクトなどがある。それらが、ポインタで結合されリストや木やグラフを構成する。一部はHashMapなどに格納される。</p> +<p>一方でデータベースでは、平たんな表構造を持ち、KEY属性を用いて参照する。</p> +<p>例えばゲーム中のアイテムのリストは、データ構造として容易に表現されるがRDBでは、関係を表すテーブルを用いて表現する必要がある。</p> +<p>データ構造の変更は、並列に行われても整合性を維持するトランザクションである必要があるが、標準的なものは提供されていない。</p> +<p>このようにプログラム中のデータ構造とデータベースの間にはギャップがある。これをインピータンスピスマッチいうことがある。</p> </font> </div> -<!-- <div> -<h1>インピータンスミスマッチ</h1> -<font size=5> -<p>プログラム中のデータ構造とRDBの表構造には大きなギャップがある。これはインピーダンスミスマッチと呼ばれている。</p> -<p>例えばRPGゲーム中のユーザが持つアイテムという単純なものでも、RDBではユーザとアイテムの組をキーとする巨大な表として管理することになる。</p> -<p>プログラム中では、ユーザが持つアイテムリストという簡単な構造を持つが、データのネスト構造を許さない第一正規形を要求するRDBとは相容れない。</p> -</font> +<h1>データベースのトランザクションとデータ構造のギャップ</h1> +<p>データベースには、複数のレコードをアップデートするときに、整合性を維持する仕組みとしてトランザクションがある。</p> +<p>データ構造には並行処理ようにスレッドセーフなものが用意されている。しかし、複数のスレッドセーフなデータ構造はアクセスするときに整合性を維持するトランザクションは自分で用意する必要があり、標準的なものは用意されていない。</p> +<p>特に複数のリストや木構造に対してトランザクションが必要になってきている。</p> </div> ---> <div> -<h1>既存のDBが持つ問題点</h1> +<h1>インピータンスピスマッチを乗り越えるための既存技術</h1> <font size=5> -<p>MySQLやPosgreSQLなどは、Jsonなどの不定形のデータ構造を格納するように機能拡張されるようになってきた。</p> +<p>これまでに開発されてきたものには、 +<ol> +<li>データベースのレコードをプログラム中のオブジェクトとして使えるOR Mapper +<li>データベース自体も、表に特化したKey Value Store +<li>Jsonなどの不定形のデータ構造をRDBのレコードとして格納する機能拡張 +</ol> +</p> <p>しかし、不定形の構造の変更をトランザクションとして、どのように処理するかはJsonの一括変更という形で処理されてしまっており、 並列処理が中心となってきている今のアプリケーションには向いていない。</p> -<p>この拡張はRDBよりの拡張であり、 -並列処理を含むプログラミングからの要請とのミスマッチが残っている。</p> +<p>特に木構造自体が大きくなる場合に問題がある。</p> </font> </div> -<div> -<h1>既存のDBが持つ問題点</h1> -<font size=5> -<p>データベース自体も、表に特化したKey Value Storeや、Jsonなどの不定形のデータ構造を格納するように機能拡張されてきている。</p> -<p>その例としてCassandraや、mongoDBが挙げられる。</p> -<p>しかし、プログラム中のデータは複雑な構造をメモリ上に構築しており、これらの方法でもまだギャップがある。</p> -</font> -</div> <div> <h1>非破壊的木構造データベースJungle</h1> <font size=5> -<p>当研究室ではこれらの問題を解決するために木構造Jungleデータベースを提案している。</p> -<p>Jungleは様々な構造のデータ(例えばXML/JSON/LIST)を木構造としてそのまま格納することが可能である。</p> -<p>Jungleではデータの変更を非破壊的、つまり元の木を保存しつつ、新しい木を構築する方法をとる。</p> -<p>これにより木を参照しながら処理するタスクと木を変更するタスクを並列に処理することができる。</p> -<p>プログラムは、この木を変更されないデータ構造として直接取り扱うことができる。</p> -<p>名前付きの複数の木をatomicに入れ替えるのがJungleの transactionとなる。</p> +<p>プログラム中のデータ構造のうち木構造やリスト構造に着目する。</p> +<p>データベースJungleはこれらを直接データベースとして取り扱い、マルチスレッドからの読み書きをトランザクションとして提供する。</p> +<p>Jungleの木は、外部のノードあるいはディスクに複製され、持続性を提供する。</p> +<p>複数の木の間の参照などの複雑な構造はノードのKey属性のIndexを使って実現する。</p> +<p>Jungleでは、データ構造の並行処理が可能なように、データの変更を非破壊的に行う。</p> +<p>木が変更されている間も、その前の版を安全に読み出すことができる。</p> </font> </div> +<div> +<h1>Jungleによるインピータンスピスマッチの解消</h1> +<font size=5> +<p>Jungleはゲームなどのアイテムのリストをそのまま木構造に格納することができ、トランザクションと持続性を提供する。</p> +<p>Jungleは様々な構造のデータ(例えばXML/JSON/LIST)を木構造としてそのまま格納することが可能である。</p> +<p>決まった版の木は変更されないので、いちいち木を検索することなく木構造をそのままプログラムのデータ構造として用いることができる。</p> +<div> <div> +<h1>Jungleの構造とAPI</h1> +<p>以下では、Jungleの構成要素と木へのアクセス方法を説明する。</p> +<ol> +<li>木とノード +<li>トランザクション +<li>名前による木の作成と取得 +<li>NodePath +<li>ノードの編集 +<li>検索機能 +</div> + <h1>Jungleの構造</h1> <font size=5> <p>木は複数のノードの集合でできており、その木の集合によりJungleが構成されている。</p> @@ -206,6 +219,19 @@ </div> + +<div> +<h1>NodePath</h1> +<font size=5> +<p>Jungleでは木のノードの位置をNodePathを使って表す。</p> +<p>ルートから対象のノードまでの経路を数字で指し示す。</p> +<p>ルートノードは例外として-1と表記される。</p> +<p>NodePathクラスを用いて[-1,1,2,3]を表している例を以下に貼る。</p> +<embed src="../figures/nodepath.pdf" width="800" height="500"/> +</font> +</div> + + <div> <h1>Jungleの木の編集</h1> <font size=5> @@ -220,17 +246,6 @@ </div> -<div> -<h1>NodePath</h1> -<font size=5> -<p>Jungleでは木のノードの位置をNodePathを使って表す。</p> -<p>ルートから対象のノードまでの経路を数字で指し示す。</p> -<p>ルートノードは例外として-1と表記される。</p> -<p>NodePathクラスを用いて[-1,1,2,3]を表している例を以下に貼る。</p> -<embed src="../figures/nodepath.pdf" width="800" height="500"/> -</font> -</div> - @@ -272,45 +287,32 @@ </div> <div> -<h1>Jungleの問題点</h1> +<h1>本修論でのJungleの改良点</h1> <font size=5> -<p>これまでに記述したAPIにより、Jungleはデータの書き込み、読み込みを行える。</p> -<p>しかし、性能はあまり良いものではなかった。</p> -<p>特にIndexを用いた検索が明らかに遅く、検索の手間がO(n^2)となっていた。</p> -<p>本来ならIndexを使った場合の検索の手間はO(Log n)であるべきである。</p> +<ol> +<li>高速な非破壊赤黒木の実装(O(log n)) +<li>検索APIの実装(卒論時) +<li>Indexの差分アップデート(O(log n)) +<li>線形リストの高速化(O(1)) +<li>Jungle Tree自体のバランス化による大きな木の扱い(O(log n)) </font> </div> -<div> -<h1>JungleのIndexが遅い原因</h1> -<font size=5> -<p>Jungle では、今まで Java 上で関数型プログラミングが行えるライブラリ、Functional Java の TreeMap を使用して、Index を実装していた。</p> -<p>しかし、Functional Java の TreeMap は、採用しているアルゴリズムが悪かった。</p> -<p>またコードの量も膨大であり、修正も困難だった。</p> -<p>そこで、自分で、同じ機能を持つ 非破壊 TreeMap を実装することにした。</p> -<p>TreeMap アルゴリズムは赤黒木を採用した。</p> -</font> -</div> - <div> <font size=5> -<h1>Indexに非破壊TreeMapを採用している理由</h1> +<h1>非破壊TreeMapによるJungleのIndex</h1> <p>Jungleは過去の版の木を全て保持している。</p> <p>過去の木に対する検索もサポートしている。</p> -<p>木の版毎にIndexを持っている必要がある</p> -<p>破壊的TreeMapでは、木に更新が入るたびに新しいIndexを作り直す必要がある。</p> -<p>Indexの更新の手間がO(n)になってしまう。</p> -<p>非破壊TreeMapの場合、一度作られたTreeMapに対して編集を行うと、編集後のTreeMapを返す。</p> -<p>その際、編集前のTreeMapのデータは破壊されることはない。</p> -<p>また、過去のIndexとデータを共有している</p> -<p>複数のversionのIndexがあっても、データの差分しかメモリは消費されない</p> -<p>メモリの使用量を抑えつつ複数のversionでIndexを保持できる</p> +<p>木の版毎にIndexを持っている必要がある。</p> +<p>従来は破壊的TreeMapでIndexを実現しており、木に更新が入るたびに新しいIndexをO(n)で作り直す必要があった。</p> +<p>実装した非破壊TreeMapでIndexを実装することにより、更新をO(log n)で行うことができるようになった。 +また、変更されない部分は過去の版と共有されるので、メモリ効率も改良された。 </font> </div> - +<!-- <div> <h1>赤黒木とは</h1> <font size=5> @@ -325,155 +327,39 @@ <p>赤黒木は、上記の条件を満たしている限りデータの検索、削除、探索をO(Log n)で行える。</p> </font> </div> +--> + <div> -<h1>Jungleの問題点2</h1> +<h1>線形の木の取り扱い</h1> <font size=5> -<p>非破壊のTreeMapを実装したことにより、読み込みは極めて高速に行えるようになった。</p> -<p>しかし、書き込みに関してはまだ十分な速度が出ていない。</p> -<p>Jungleの木の編集時に特に問題になっているのは、主に次の三点である。</p> -<ul> -<li>Indexの更新が、毎回フルアップデートしているため更新の手間がO(n)となっている。</li> -<li>線形の木を更新する際、Jungleは全てのノードの複製を取ってしまうため、更新の手間がO(n)となってしまう</li> -<li>木のノード数が増えると、バランスが取れていない場合木の更新が重くなる。</li> -</ul> -<p>以降これらの問題について述べていく。</p> +<p>Jungleは木の編集時、ルートから編集を行う位置までのノードの複製を行う。</p> +<p>そのため、木の編集の手間は木構造の形によって異なる。</p> +<p>特に線形の木の場合、全てのノードの複製を行うため変更の手間がO(n)となってしまう。</p> +<p>線形の木をO(1)で変更するPush/Pop操作とDifferential Jungle Tree操作の実装した。</p> </font> </div> <div> -<h1>Indexの差分アップデート</h1> -<font size=5> -<p>JungleではIndexの更新を行う際、毎回新しいIndexを構築していた。</p> -<p>その為、毎回O(n)のIndexの更新が入っていた。</p> -<p>Indexの差分アップデートを実装することで、Indexの更新の手間をO(Log n)とする。</p> -</font> -</div> - -<div> -<h1>Indexの差分アップデートの実装</h1> +<h1>Push/Pop</h1> <font size=5> -<p>Jungleは木の編集を行う際、編集を行うノードからルートまでの経路のノードの複製を行う。</p> -<p>そのため、編集後の木には存在しない、複製前のノードがIndexに残ってしまう。</p> -<p>それらのノードをIndexから削除し、複製後のノードを登録する必要がある。</p> -<embed src="../figures/non_destructive_tree.pdf" width="800" height="500"/> -<p>この図だと、Indexの更新時にroot、2、5をIndexから削除する必要がある。</p> -<p>その後新しく作られたノードを登録することでIndexの更新は完了する</p> -</font> -</div> - -<div> -<h1>複製前のノードのdelete</h1> -<font size=5> -<p>複製前のノードをIndexから削除するためには、編集を行ったノードを覚えておく必要がある。</p> -<p>Editorの中に編集を加えたノードを格納するリストを定義した。</p> -<p>Indexのアップデート時にリストを使用する。</p> +<p>線形リストのルートの上にルートを付け加える操作(Push)はO(1)である。</p> +<p>逆にルートを取り除き、その子供をルートにする操作(Pop)もO(1)である。</p> +<p>これらにより、線形木を高速に操作することができる。</p> +<p>Pushを連続で行うと、リストは逆順に構築される。</p> +<embed src="../figures/PushPopDemerit.pdf" width="800" height="500"/> </font> </div> <div> -<h1>複製前のノードのdelete</h1> -<font size=5> -<p>複製前のノードは以下の手順で行われる。</p> -<ol> -<li>編集を行ったノードのリストからノードを取得する。</li> -<li>取得したノードが、保持している値をIndexから削除する。 </li> -<li>自身と子供のペアを ParentIndex から削除する。</li> -<li>ParentIndexから自身の親を取得する。</li> -<li>2 - 4 をルートノードにたどり着くか、ParentIndex から親を取得できなくなるまで続ける。 </li> -<li>1 - 5 をリストからノードが無くなるまで続ける。</li> -</ol> -</font> -</div> - -<div> -<h1>編集前のノードのdeleteの例1</h1> -<font size=5> -<p>ノードD、Eを編集した後の、複製前のノードをIndexから削除する例を記述する。</p> -<p>黒のノードは編集後の木に存在しないノード。</p> -<p>赤のノードはIndexから削除が終了したノード。</p> -<p>その他のノードは緑とする。</p> -<br> -<p>編集前ノードのDelete前</p> -<embed src="../figures/indexUpdate.pdf" width="800" height="500"/> -</font> -</div> - -<div> -<h1>編集前のノードのdeleteの例2</h1> -<font size=5> -<p>ノードDについての削除後</p> -<embed src="../figures/indexUpdate2.pdf" width="800" height="500"/> -</font> -</div> - -<div> -<h1>編集前のノードのdeleteの例3</h1> -<font size=5> -<p>ノードEについての削除後</p> -<embed src="../figures/indexUpdate3.pdf" width="800" height="500"/> -<p>このようにIndexからのノードの削除は行われる</p> -</font> -</div> - - -<div> -<h1>ノードのIndexへの追加</h1> -<font size=5> -<p>Indexへのノードは以下の手順で行われる。</p> -<ol> -<li>木からルートノードを取得する。</li> -<li>取得したノードがIndexに登録されているかを調べる。</li> -<li>登録されている場合、そのノード以下のSubTreeは、全てIndexに登録されているので、次のノードに移動する。</li> -<li>登録されていなかった場合、自身が保持している値をIndexに登録する。</li> -<li>自身と子ノードを Parent Index に登録する。</li> -<li>自身の子ノードを取得したノードとして2に戻る。</li> -<li>全てのノードを登録したら終了する。</li> -</ol> -<p>ノードの登録は深さ優先探索と同じ順序で行っていく。</p> -</font> -</div> - -<div> -<h1>ノードのIndexへの追加例</h1> -<font size=5> -<p>ノードD、Eを編集した後の、複製前のノードをIndexから削除する例を記述する。</p> -<p>赤のノードはIndexに存在しないノード。</p> -<p>緑のノードはIndexに追加されているノード。</p> -<br> -<p>以下の図の場合、A、B,D、Eの順に登録され、Cで終了する。</p> -<embed src="../figures/indexUpdate3.pdf" width="800" height="500"/> - -</font> -</div> - - -<div> -<h1>線形の木の構築</h1> -<font size=5> -<p>Jungleは木の編集時、ルートから編集を行う位置までのノードの複製を行う。</p> -<p>そのため、木の編集の手間は木構造の形によって異なる。</p> -<p>特に線形の木の場合、全てのノードの複製を行うため変更の手間がO(n)となってしまう。</p> -<p>Jungleは線形の木をO(1)で変更するPushPopの機能を持つ。</p> -</font> -</div> - -<div> -<h1>PushPop</h1> -<font size=5> -<p>PushPopはルートノードの上に新しいルートを追加するAPIである。</p> -<p>しかし、PushPopで構築した木は逆順になってしまう。</p> -<p>そのため、正順の木を構築する際は使用できない。</p> -<embed src="../figures/PushPopDemerit.pdf" width="800" height="500"/> -</font> -</div> - -<div> <h1>Differential Jungle Tree</h1> <font size=5> -<p>正順の木をO(1)で構築するために実装した。</p> -<p>Differential Jungle Treeは木のバージョン毎に自身の木の最後尾のノードを持つ。</p> +<p>木のノードの追加順の線形リストが必要な場合もある。例えばLogなどである。</p> +<p>Differential Jungle Treeは木の最後尾のノードへのポインタを持つ。</p> +<p>最後尾に新しいノードをAtomicに書き込む。ルートは、版ごとに最後尾のノードを保持しており、 +木自体は変更されるが、その版の木の長さの範囲では変更されていない。</p> +<p>版ごとの最後尾を越えないようにアクセスすることで、線形木の非破壊性を維持することができる。</p> <embed src="../figures/findDifTree.pdf" width="800" height="500"/> <p></p> </font> @@ -481,27 +367,17 @@ <div> <font size=6> -<h1>Differential Jungle Treeの作成</h1> -<p>Differential Jungle Treeを作成するためにJungleに新しいAPIを実装した。</p> +<h1>Differential Jungle Treeの作成API</h1> +<p>Differential Jungle Treeは、特別なAPIで作成する必要がある。</p> <div style="padding: 10px; margin-bottom: 10px; border: 5px double #333333;"> <pre><code class="language-Java"> JungleTree createNewDifferenceTree(String treeName); </code></pre> </div> -<p>上記のAPIは、treeNameで指定した名前のDifferential Jungle Treeを構築する。</p> +<p>差分木への追加を複数回行うと、複数回のトランザクション処理を行う必要がある。 +複数の追加をSub Treeに対して破壊的に行って、そのSub Treeを差分木へ追加することにより、トランザクションを一回で済ませることができるようにしている。</p> </font> </div> -<div> -<font size=6> -<h1>Differential Jungle Treeの編集</h1> -<p>Differential Jungle Treeの木の編集は、Differential Jungle Tree Editorを用いて行う。</p> -<p>既存のDefault Jungle Treeは、木の複製を作った後編集を行う。</p> -<p>Differential Jungle Tree Editorは、自身がSub Treeを持っている。</p> -<p>Sub Tree に対して編集を行う。</p> -<p>Commit時に自身が保持している末尾ノードにSub TreeをAppendすることで木の編集を終了する。</p> -<p>また、Diffirential Jungle Treeの編集は、Editorが持つSub Treeへの編集しか行えないため、一度Commitした木に対して変更を加えることはできない。</p> -</font> -</div> <div> <font size=6> @@ -512,31 +388,6 @@ </font> </div> -<div> -<font size=6> -<h1>Differential Jungle Treeの検索</h1> -<p>Differential Jungle Treeは末尾ノードを使って現在の木構造を表現している。</p> -<p>過去の木に対してIndexを使わないで全探索を行った場合、既存の検索ではその版に存在しないはずのノードが取得できてしまう。</p> -<embed src="../figures/findDifTree.pdf" width="800" height="500"/> -</font> -</div> - -<div> -<font size=6> -<h1>Differential Jungle Treeの検索例</h1> -<p>以下の図の場合Tree Ver1を全探索すると、存在しないはずのノード3、4が取得できてしまう。</p> -<embed src="../figures/findDifTree.pdf" width="800" height="500"/> -</font> -</div> - -<div> -<font size=6> -<h1>Differential Interface Traverserの実装</h1> -<p>この問題を解決するためにDifferential Interface Traverserを実装した。</p> -<p>これは、末尾ノード以下を検索対象から取り除く検索を持つ。</p> -<p>Indexを使った検索の場合、各版ごとに独立したIndexを持つため、Default Jungle Treeと同じ検索でも問題ない。</p> -</font> -</div> <div> <font size=6> @@ -549,50 +400,29 @@ </font> </div> + <div> <font size=6> -<h1>Differential Jungle Treeの整合性2</h1> -<p>Differential Jungle Treeでは、過去の版の木に対して変更を加えた際に木の整合性が崩れてしまう問題もある。</p> -<p>図の中の、過去の木であるTree ver1に対してノード5を追加してCommitした場合、新しい木Tree ver`2が生成される。</p> -<embed src="../figures/badDifTree3.pdf" width="800" height="500"/> - +<h1>Jungle上での巨大な木の扱い</h1> +<p>Jungleは木の編集時、ルートから編集を行う位置までのノードの複製を行う。</p> +<p>そのため、木の編集の手間は木構造の大きさにも依存している。</p> +<p>バランスの取れた木構造を構築することで、編集の手間をO(log n)にすることは可能ではある。</p> +<p>しかし、ユーザーが木の構造を把握しバランスを取るのは難しい。</p> +<p>そこで、自動で木のバランスを取り、最適な木構造を構築する機能を持つRed Black Jungle Treeを実装した。</p> +<p>Red Black Jungle Treeは、木構造を指定した作成を行うことはできないが、Key属性を用いて任意のノードにアクセスすることができる。</p> </font> </div> <div> <font size=6> -<h1>Differential Jungle Treeの整合性3</h1> -<p>Tree ver`2に対してIndexを使わないで検索を行った場合、本来存在しないはずのノード3、4が検索対象に入ってしまう。</p> -<p>これは、Tree ver1の末尾ノードが2つ子を持っているせいで発生する。</p> -<p>この問題を解決するために、過去の木に対する変更は禁止した。</p> -<embed src="../figures/badDifTree2.pdf" width="800" height="500"/> -</font> -</div> - -<div> -<font size=6> -<h1>Jungle上での巨大な木の扱い。</h1> -<p>Jungleは木の編集時、ルートから編集を行う位置までのノードの複製を行う。</p> -<p>そのため、木の編集の手間は木構造の大きさにも依存している。</p> -<p>バランスの取れた木構造を構築することで、編集の手間をO(Log n)にすることは可能ではある。</p> -<p>しかし、ユーザーが木の構造を把握しバランスを取るのは難しい。</p> -<p>そこで、自動で木のバランスを取り、最適な木構造を構築する機能を持つRed Black Jungle Treeを実装した。</p> -<p>Red Black Jungle Treeは、自動でバランスを取ってしまうため、木構造の形でデータを表現することはできない。</p> -</font> -</div> - -<div> -<font size=6> -<h1>Red Black Jungle Treeの作成</h1> -<p>Red Black Jungle Treeを作成するためにJungleに新しいAPIを実装した。</p> +<h1>Red Black Jungle Treeの作成API</h1> +<p>Red Black Jungle Treeは、特別なAPIで作成する必要がある。</p> <div style="padding: 10px; margin-bottom: 10px; border: 5px double #333333;"> <pre><code class="language-Java"> JungleTree createNewRedBlackTree(String treeName,String balanceKey); </code></pre> </div> <p>上記のAPIは、treeNameで指定した名前のRed Black Jungle Treeを構築する。</p> <p>また、第二引数のbalanceKeyを用いて木のバランスを取る。</p> -<p>第二引数のbalanceKeyを使用して、検索することでO(Log n)で検索を行うことができる。</p> -<p>なので、別途Indexを構築する必要はない。</p> </font> </div> @@ -607,16 +437,6 @@ </font> </div> -<div> -<font size=6> -<h1>Red Black Jungle Treeの検索</h1> -<p>Red Black Jungle TreeはIndexを持たないため既存の検索は使用できない。</p> -<p>木の生成時に指定したbalanceKeyを使用して、O(Log n)で探索を行う検索を実装した。</p> -<p>また、balanceKeyを使用しない場合は、既存のDefault Jungle Treeと同じで全探索を行うのでO(n)となる。</p> -</font> -</div> - - <div> <font size=6>