# HG changeset patch # User tatsuki # Date 1486959477 -32400 # Node ID 5c154df2a4d75eb617a8eec01e5a9766d1ded304 # Parent edda4302866b248fc099648fe9ba537f2a3559f3 commit diff -r edda4302866b -r 5c154df2a4d7 slide/images/compareDBbigJson.svg --- a/slide/images/compareDBbigJson.svg Mon Feb 13 06:17:40 2017 +0900 +++ b/slide/images/compareDBbigJson.svg Mon Feb 13 13:17:57 2017 +0900 @@ -1,192 +1,161 @@ - -image/svg+xml0 -5000 -10000 -15000 -20000 -25000 -30000 -5000 -10000 -15000 -20000 -time(ms) -JsonSize -"jungleFindBenchMark" using 1:2 -"mongFindBenchMark" using 1:2 -"postgresFindBenchMark" using 1:2 - \ No newline at end of file + + + + +Gnuplot +Produced by GNUPLOT 5.0 patchlevel 5 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + 0 + + + + + 5000 + + + + + 10000 + + + + + 15000 + + + + + 20000 + + + + + 25000 + + + + + 30000 + + + + + 5000 + + + + + 10000 + + + + + 15000 + + + + + 20000 + + + + + + + + + time(ms) + + + + + JsonSize + + + + + "Jungle" using 1:2 + + + + + "Jungle" using 1:2 + + + + + + "MongoDB" using 1:2 + + + "MongoDB" using 1:2 + + + + + + "PostgreSQL" using 1:2 + + + "PostgreSQL" using 1:2 + + + + + + + + + + + + + + + + + + diff -r edda4302866b -r 5c154df2a4d7 slide/slide.html --- a/slide/slide.html Mon Feb 13 06:17:40 2017 +0900 +++ b/slide/slide.html Mon Feb 13 13:17:57 2017 +0900 @@ -127,9 +127,9 @@

データベースのトランザクションとデータ構造のギャップ

データベースには、複数のレコードをアップデートするときに、整合性を維持する仕組みとしてトランザクションがある。

-

データ構造には並行処理ようにスレッドセーフなものが用意されている。

-

しかし、複数のスレッドセーフなデータ構造はアクセスするときに整合性を維持するトランザクションを自分で用意する必要があり、標準的なものは用意されていない。

-

特に複数のリストや木構造に対してトランザクションが必要になってきている。

+

データ構造には並行処理用にスレッドセーフなものが用意されている。

+

しかし、複数のスレッドセーフなデータ構造は、アクセスするときに整合性を維持するトランザクションを自分で用意する必要があり、標準的なものは用意されていない。

+

特に複数のリストや木構造に対してのトランザクションが必要になってきている。

@@ -203,9 +203,11 @@
-

JungleのTransaction

+

Jungleのトランザクション

データの変更は一度生成した木を上書きせず、ルートから変更を行うノードまでコピーを行い、新しく木構造を構築する。

+

木の変更に関係ないノードは参照を行い過去の木と共有する。

+

そして新しい木構造に変更を加える。

最後にルートをアトミックに入れ替えてCommitする。

他のThreadとCommitが競合し失敗した場合は最初からやり直す。

- -

既存のDBとJungleの比較

-

比較対象はMongoDBとPostgreSQLを選択した。

-

PostgreSQLはJson形式でデータを格納している。

-

データの検索速度を比較した。

- + +

グラフのX軸は、データ1件あたりのJSONのサイズ。

+

グラフのY軸は、検索にかかった時間を表している。

+

既存のDBとJungleの比較の考察

-

MongoDBとPostgreSQLは、プログラム外にあるデータベースに通信を用いてアクセスしている。

-

Jungleは、メモリの中にデータを持ち通信を使わずデータにアクセスできる。

-

期待通りの性能が出た。

+

PostgreSQLは、JSONのサイズが大きくなると性能が落ちる。一方、MongoDBとJungleはJSONのサイズが変わっても性能はあまり落ちない。

+

PostgreSQLのIndexは、JSONのサイズには対応していなかった。

+

MongoDBとJungleの性能差の理由としては、通信の有無が原因と考えられる。

+

MongoDBは通信を介してデータにアクセスしているのに対して、Jungleはプログラムの中にデータを持つため通信を行わずにデータにアクセスできている。

- +

まとめ

Jungleの性能を向上させるために新たな要素を追加した。

    -
  1. 高速な非破壊赤黒木の実装(O(log n))

  2. -
  3. 検索APIの実装(卒論時)

  4. -
  5. Indexの差分アップデート(O(log n))

  6. -
  7. 線形リストの高速化(O(1))

  8. -
  9. Jungle Tree自体のバランス化による大きな木の扱い(O(log n))

  10. +
  11. 高速な非破壊赤黒木の実装

  12. +
  13. 検索APIの実装

  14. +
  15. Indexの差分アップデート)

  16. +
  17. 線形リストの高速化

  18. +
  19. Jungle Tree自体のバランス化による大きな木の扱い

-

実装後の測定では、全てが既存の木と比べて高速に動いていた。

-

また、Jungleは既存のDBと比較しても、極めて高速な検索が行えることがわかった。

+

Jungleは既存のDBと比較しても、極めて高速な検索が行えることがわかった。