# HG changeset patch # User Nobuyasu Oshiro # Date 1391400401 -32400 # Node ID 07aec327a7bc6adeb9be9a15c6937c8b43f39da3 # Parent e36cbf39a9494373b14ef50ed5ba39344327a9fa Added slides.htlm diff -r e36cbf39a949 -r 07aec327a7bc slides/blank.css.less --- a/slides/blank.css.less Mon Feb 03 12:17:40 2014 +0900 +++ b/slides/blank.css.less Mon Feb 03 13:06:41 2014 +0900 @@ -15,8 +15,8 @@ // -- gradient colors for all other slides -@background-gradient-color1: yellow; -@background-gradient-color2: orange; +@background-gradient-color1: white; +@background-gradient-color2: white; // --- font size diff -r e36cbf39a949 -r 07aec327a7bc slides/graffle/scalability.graffle --- a/slides/graffle/scalability.graffle Mon Feb 03 12:17:40 2014 +0900 +++ b/slides/graffle/scalability.graffle Mon Feb 03 13:06:41 2014 +0900 @@ -531,8 +531,212 @@ GraphicsList + Class + LineGraphic + Head + + ID + 10 + + ID + 3087 + Points + + {346.95285922441974, 340.92010707901903} + {439, 297.84167564127193} + + Style + + stroke + + HeadArrow + FilledArrow + Legacy + + LineType + 1 + TailArrow + 0 + Width + 2 + + + Tail + + ID + 3082 + + + + Class + LineGraphic + Head + + ID + 3077 + + ID + 3086 + Points + + {346.99949758391216, 356.97742552662277} + {439, 352.85000557263692} + + Style + + stroke + + HeadArrow + FilledArrow + Legacy + + LineType + 1 + TailArrow + 0 + Width + 2 + + + Tail + + ID + 3082 + + + + Class + LineGraphic + Head + + ID + 10 + + ID + 3085 + Points + + {346.94561250585951, 250.99344309735469} + {439, 297.84167564127193} + + Style + + stroke + + HeadArrow + FilledArrow + Legacy + + LineType + 1 + TailArrow + 0 + Width + 2 + + + Tail + + ID + 3083 + + + + Class + LineGraphic + Head + + ID + 3078 + + ID + 3084 + Points + + {346.99894266210464, 234.15733308722994} + {439, 240.1500020567577} + + Style + + stroke + + HeadArrow + FilledArrow + Legacy + + LineType + 1 + TailArrow + 0 + Width + 2 + + + Tail + + ID + 3083 + + + Bounds - {{266.58111190795898, 216}, {158, 42}} + {{271.5, 208}, {75, 47.364395141601562}} + Class + ShapedGraphic + ID + 3083 + Shape + Rectangle + Style + + shadow + + Draws + NO + + + Text + + Text + {\rtf1\ansi\ansicpg1252\cocoartf1265 +\cocoascreenfonts1{\fonttbl\f0\fswiss\fcharset0 Helvetica;} +{\colortbl;\red255\green255\blue255;} +\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\pardirnatural\qc + +\f0\fs24 \cf0 Server} + + + + Bounds + {{271.5, 335}, {75, 47.364395141601562}} + Class + ShapedGraphic + ID + 3082 + Shape + Rectangle + Style + + shadow + + Draws + NO + + + Text + + Text + {\rtf1\ansi\ansicpg1252\cocoartf1265 +\cocoascreenfonts1{\fonttbl\f0\fswiss\fcharset0 Helvetica;} +{\colortbl;\red255\green255\blue255;} +\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\pardirnatural\qc + +\f0\fs24 \cf0 Server} + + + + Bounds + {{361, 174}, {158, 42}} Class ShapedGraphic ID @@ -597,7 +801,7 @@ TailArrow 0 Width - 3 + 2 Tail @@ -634,7 +838,7 @@ TailArrow 0 Width - 3 + 2 Tail @@ -671,7 +875,7 @@ TailArrow 0 Width - 3 + 2 Tail @@ -697,7 +901,13 @@ Shape Cylinder Style - + + shadow + + Draws + NO + + Text Text @@ -728,7 +938,13 @@ Shape Cylinder Style - + + shadow + + Draws + NO + + Text Text @@ -744,7 +960,7 @@ Bounds - {{156.29400879554748, 235.99996948242188}, {95.868200000000002, 28.999969482421875}} + {{135.74999672584534, 208}, {95.868200000000002, 28.999969482421875}} Class ShapedGraphic ID @@ -777,7 +993,7 @@ {\colortbl;\red255\green255\blue255;} \pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\pardirnatural\qc -\f0\fs24 \cf0 request} +\f0\fs28 \cf0 request} @@ -786,14 +1002,14 @@ Head ID - 3 + 3082 ID 3070 Points {158, 330.99996948242188} - {271.01692328714245, 300.82385038144855} + {271.00819608615024, 351.71731160105139} Style @@ -816,14 +1032,14 @@ Head ID - 3 + 3082 ID 3069 Points {145, 306.99996948242188} - {271.00245677714241, 294.46287682825647} + {271.0231191854599, 346.71433283700662} Style @@ -876,14 +1092,14 @@ Head ID - 3 + 3083 ID 3067 Points {130, 270.99996948242188} - {271.00299547604919, 286.504152806636} + {271.01164216015417, 240.02642991071195} Style @@ -906,14 +1122,14 @@ Head ID - 3 + 3083 ID 3066 Points {123, 243.99996948242188} - {271.01504071534873, 281.14871880566938} + {271.00109284810424, 234.19865924385411} Style @@ -947,7 +1163,13 @@ Shape Cylinder Style - + + shadow + + Draws + NO + + Text Text @@ -1378,6 +1600,14 @@ 3 Shape Rectangle + Style + + shadow + + Draws + NO + + Text Text @@ -1437,7 +1667,7 @@ MasterSheets ModificationDate - 2014-02-02 05:24:01 +0000 + 2014-02-03 03:35:42 +0000 Modifier Oshiro Nobuyasu NotesVisible diff -r e36cbf39a949 -r 07aec327a7bc slides/images/scalability.png Binary file slides/images/scalability.png has changed diff -r e36cbf39a949 -r 07aec327a7bc slides/index.html --- a/slides/index.html Mon Feb 03 12:17:40 2014 +0900 +++ b/slides/index.html Mon Feb 03 13:06:41 2014 +0900 @@ -73,18 +73,24 @@

概要

-

非破壊的木構造データベースJungleに分散実装を行い掲示板システムに特化したデーターベースを作成し、その評価を行った。

分散データベースCassandraより2倍以上速く、分散環境下においては10倍以上速い結果も確認された。


-

ウェブサービスにとってデータベースは必須であり、ウェブサービスの規模に比例してデータベースへの負荷も高まる。

-

データベースの処理能力の高さはそのままウェブサービスの質に繋がるため、データベースのスケーラビリティの確保は重要である。

-

スケーラビリティ確保の方法としてデータ分散があるが、分散する方法により性能も変わってくる。

-

+ 研究の目的と背景 +

+

ウェブサービスにとってデータベースは必須であり、ウェブサービスの規模に比例してデータベースへの負荷も高まる。

+

データベースの処理能力の高さはそのままウェブサービスの質に繋がるため、データベースのスケーラビリティの確保は重要である。

+

スケーラビリティ確保の方法としてデータ分散があるが、分散する方法により性能も変わってくる。

+

スケーラビリティのある分散データベースとしてJungleの実装を行う。

+
+ + +
+

ウェブサービスにおけるデータベースの重要性

ウェブサービスへの負荷が高まることは、データベースへの負荷が高まることでもある。

@@ -114,10 +120,14 @@ データベースのスケーラビリティ

データベースのスケーラビリティを考えるとき、どういう用途で使用するかを考えるのが重要。

-
  • 例えば銀行の口座の情報を扱うデータベースは、データの整合性が最優先である。違う値がみられてはいけない。
  • +
  • 例えば、掲示板システムにおいては、書き込みと読み込みが速いことが求められる。

  • -

    ウェブサービスにおいても、どのようなサービスを行うかによってスケーラビリティの確保の仕方も変わってくる。

    +

    ウェブサービスは、サービスの内容によってスケーラビリティの確保の仕方も変わってくる。

    本研究で開発しているデータベースはコンテンツマネジメントシステム(CMS)を対象としている。

    +

    + +

    +
    @@ -138,25 +148,6 @@

    JungleはスケーラビリティのあるCMSの設計を目指して当研究室で開発されているデータベース。

    データを木構造で、さらに非破壊で保持する。


    -

    まず、破壊的木構造と非破壊的木構造について説明する。

    -
    - -
    -

    破壊的木構造

    -

    木構造の通常のデータ表現

    -

    破壊的木構造は、木構造により保持しているデータの編集をデータを直接書き換えることで行う

    -

    - -

    -
    - -
    -

    破壊的木構造

    -

    破壊的木構造ではデータの編集中にそのデータを読むことができない

    -

    編集が完了するまでまたなければならない

    -

    - -

    @@ -166,36 +157,13 @@

    非破壊的木構造は一度作成したデータは変更しない

    新しい木構造を作成することでデータの編集を行う

    - +

    - 非破壊的木構造におけるデータ編集 -

    -

    目的とするノード5ををコピーして内容を編集する。ノード100となる

    -

    ルートノードから目的のノード5までに続くルートノードとノード2のコピーとりノード100と繋げる

    - -

    - -

    -
    - -
    -

    - 非破壊的木構造におけるデータ編集と読み込み -

    -

    新しく作成したルートノードに変更を加えていないノードへの参照を持たせる。新しい木構造のデータができる

    -

    最新のルートノードの登録を新しく作成した側のルートノードへと登録する

    -

    - -

    -
    - -
    -

    非破壊的木構造の利点

    非破壊的木構造は通常の木構造である破壊的木構造に比べ、以下のような利点を持つ

    @@ -224,14 +192,10 @@ - - @@ -242,17 +206,6 @@

    - データ更新衝突の解決 -

    -

    トポロジー形成とデータ伝搬手段については述べた。

    -

    次に問題になることはデータの整合性をどのようにとるか。

    -

    例えば、ノードの持つデータが全て同じ値にしなければならない場合は、データを持つノード全てにロックを掛けて - 変更を加える必要がある。この方法はスケールしない。

    -

    多少古い値を読んでも問題無く、結果整合性でよいというのなら幾つかのノードに書き込むだけで良い。こちらの方法はスケールする。

    -
    - -
    -

    非破壊的木構造の利点を活かした分散設計

    Jungleで扱うつもりのデータは結果整合性でもよいCMSを想定していることを始めに説明した。

    diff -r e36cbf39a949 -r 07aec327a7bc slides/index.html_back --- a/slides/index.html_back Mon Feb 03 12:17:40 2014 +0900 +++ b/slides/index.html_back Mon Feb 03 13:06:41 2014 +0900 @@ -1,189 +1,742 @@ - - - - - 分散データベースJungle - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    - - -
    - -
    - - - -
    -

    分散データベースJungleに関する研究

    -
      -

      琉球大学 大城信康 -
      - 14 Jan 2013 -

      -
    -
    - -
    -

    研究の背景と目的

    -
      -
    • スマートフォンやタブレット端末の普及により、大量のデータを扱うウェブサービスが現れてきている。
    • -
    • しかしそれに伴い、サーバサイド側への負荷も増大しウェブサービスがダウンする事態が出てきている。
    • -
    • そのため、スケーラビリティはウェブサービスにおいて重要な性質の1つとなっている。 -
    • スケーラビリティとは、ある複数のノードから構成される分散ソフトウェアがあるとき、その分散ソフトウェアに対して単純にノード - を追加するだけで性能を線形に上昇させることができる性質である
    • -
    • スケーラビリティのあるプログラムについてアーキテクチャの設計から行った
    • -
    -
    - -
    -

    研究の背景と目的

    - -
      -
    • 当研究室では非破壊的木構造を用いたデータベースである Jungle を開発している
    • -
    • 非破壊的木構造とは、データの編集の際に一度木構造として保存したデータには触れず、新しく木構造を作成してデータの編集を行うこと
    • -
    • Jungle は分散データベースとして設計・実装されているが、分断耐性や永続性といった部分の実装がまだ - 行われていない
    • -
    • 本研究では、Jungle を用いてスケーラビリティをもつアーキテクチャの追求を行う
    • -
    -
    - -
    -

    今週の作業

    -
      -
    • 論文の執筆
    • -
    • ベンチマーク測定環境の構築
    • -
    -
    - -
    -

    ベンチマーク測定環境の構築

    -
      -
    • csクラスタ(VM)上で掲示板プログラムを走らせ、ベンチマークをとる
    • -
    • Jungle と Cassandra 両方を走らせる環境の構築を行った
    • -

      問題が発生

      -
    • Cassandra でConsistencyLevelをいじってもデータを伝搬してくれない
    • -
    • Jungle の分散結果が良くならない。圧倒的に遅い。Cassandra の結果の2倍3倍遅くなる
    • -
    -
    - -
    -

    問題解決

    -
      -
    • Cassandra はConsistencyLevelとは別にReplication factorというレプリケーション(複製)をとるノードの数を指定する項目がある
    • -
    • Cassandra のConsistencyLevelはこのReplication factorの数に対して行われる
    • -
        -
      • Replication factorをNとした場合、ConsistencyLevelをALLにするとこのNの数だけノードに書き込まれるのをまつ
      • -
      • Replication factorをノードの全体の数に合わせてあげるとよい
      • -
      • Replication factorの設定はv1.1くらいまでは設定ファイルでできるが、v1.2からはキースペース生成時に設定するか - ./bin/cassandra-cli を使ってCassandraのデータにアクセスして変更する必要がある
      • -
      -
      -
    • Jungle の結果が悪い原因
    • -
        -
      • Javaのメモリの量を増やす設定をいれることで解決
      • -
      -
    -
    - -
    -

    単体・複数ノードへの負荷

    -
      -
    • クライアント数最大12台。各クライアント5000回のリクエストを出す
    • -
    - -
    - -
    -

    ベンチマーク改良

    -
      -
    • Jungleの結果をbldsvで起動した時に近い結果になることが確認できた
    • -
    • Cassandra も Jungle のグラフも横ばいになっている。クライアント側からの負荷が足りない。
    • -
    • Cassandra の ConsystencyLevel をいじっても結果が変わらないのも負荷が足りないから?
    • -

      次の課題

      -
    • クライアント側はKVMで動かしていて現在12台しか無い
    • -
    • 負荷をかけるプログラムをforkすることでプロセスを増やして負荷を増やすよう改良する必要がある
    • -
      -
    • 論文書こう
    • -
    -
    - -
    -

    今後の作業

    -
      -
    • 修論作成
    • -
    • ベンチマークプログラム作成
    • -
    -
    -
    - - + + + + + 分散 Database Jungle に関する研究 + + + + + +
    + + +
    +

    + 分散 Database Jungle に関する研究 +
    + +

    +

    + 大城 信康 +
    + Feb 3, 2013 +

    +
    + +
    +

    + 概要 +

    +

    非破壊的木構造データベースJungleに分散実装を行い掲示板システムに特化したデーターベースを作成し、その評価を行った。

    +

    分散データベースCassandraより2倍以上速く、分散環境下においては10倍以上速い結果も確認された。

    +
    +
    + +
    +

    + 研究の目的と背景 +

    +

    ウェブサービスにとってデータベースは必須であり、ウェブサービスの規模に比例してデータベースへの負荷も高まる。

    +

    データベースの処理能力の高さはそのままウェブサービスの質に繋がるため、データベースのスケーラビリティの確保は重要である。

    +

    スケーラビリティ確保の方法としてデータ分散があるが、分散する方法により性能も変わってくる。

    +

    スケーラビリティのある分散データベースとしてJungleの実装を行う。

    +
    + + +
    +

    + ウェブサービスにおけるデータベースの重要性 +

    +

    ウェブサービスへの負荷が高まることは、データベースへの負荷が高まることでもある。

    +

    データベースの性能が低ければ負荷に耐え切れずサービスはダウンする

    +

    + +

    +

    そのため、データベースにはスケーラビリティが必要

    +
    + +
    +

    + スケーラビリティとは +

    +

    システムが負荷の増大に対して柔軟に拡張して対応できる性質

    +

    主に次の2つの方法によりシステムはスケールされる

    +
      +
    • スケールアップ
      高価な単一マシンによる性能アップ
    • +
      +
    • スケールアウト
      汎用的なマシンを複数台用意することで性能アップ
    • +
    +

    分散システムにおいてはスケールアウトによりスケーラビリティを高める

    +
    + +
    +

    + データベースのスケーラビリティ +

    +

    データベースのスケーラビリティを考えるとき、どういう用途で使用するかを考えるのが重要。

    +
  • 例えば、掲示板システムにおいては、書き込みと読み込みが速いことが求められる。
  • +
    +

    ウェブサービスは、サービスの内容によってスケーラビリティの確保の仕方も変わってくる。

    +

    本研究で開発しているデータベースはコンテンツマネジメントシステム(CMS)を対象としている。

    +

    + +

    + +
    + +
    +

    + コンテンツマネジメントシステム(CMS) +

    +

    Webコンテンツを構成するテキストや画像などのデジタルコンテンツを管理し配信するシステム。

    +
  • 例:ブログツール、Wiki
  • +

    分散コンテンツマネジメントシステムに求められること。

    +
  • Webコンテンツを分散して管理
  • +
  • スケールアウトするシステム
  • +

    データ全体の整合性に遅延がある、結果整合性でもよい。書き込みや読み込みを優先としたデータベースが必要。

    +

    そこで、非破壊的木構造データベースJungleの提案を行った。

    +
    + +
    +

    非破壊的木構造データベースJungle

    +

    JungleはスケーラビリティのあるCMSの設計を目指して当研究室で開発されているデータベース。

    +

    データを木構造で、さらに非破壊で保持する。

    +
    +
    + +
    +

    破壊的木構造

    +

    木構造の通常のデータ表現

    +

    破壊的木構造は、木構造により保持しているデータの編集をデータを直接書き換えることで行う

    +

    + +

    +
    + +
    +

    破壊的木構造

    +

    破壊的木構造ではデータの編集中にそのデータを読むことができない

    +

    編集が完了するまでまたなければならない

    +

    + +

    +
    + +
    +

    + 非破壊的木構造 +

    +

    非破壊的木構造は一度作成したデータは変更しない

    +

    新しい木構造を作成することでデータの編集を行う

    +

    + +

    +

    +
    + +
    +

    + 非破壊的木構造におけるデータ編集 +

    +

    目的とするノード5ををコピーして内容を編集する。ノード100となる

    +

    ルートノードから目的のノード5までに続くルートノードとノード2のコピーとりノード100と繋げる

    + +

    + +

    +
    + +
    +

    + 非破壊的木構造におけるデータ編集と読み込み +

    +

    新しく作成したルートノードに変更を加えていないノードへの参照を持たせる。新しい木構造のデータができる

    +

    最新のルートノードの登録を新しく作成した側のルートノードへと登録する

    +

    + +

    +
    + +
    +

    + 非破壊的木構造の利点 +

    +

    非破壊的木構造は通常の木構造である破壊的木構造に比べ、以下のような利点を持つ

    +
      +
    • 一度作成したデータは変更されない
    • +
    • データが変更されないため自由にコピーを作ることができる(いつでも読み込みが可能)
    • +
    • ロックがすくない。ロックが必要なのは最新のルートノードを登録するときだけ
    • +
    +

    ロックが少なく、いつでもコピーが可能なことから、非破壊的木構造はスケーラブルなシステムに有用となる

    +
    + +
    +

    + Jungleの分散設計 +

    +

    ここまでJungleに実装されている非破壊的木構造の利点について述べた。

    +

    次に、Jungleにおける分散設計について述べる。

    +

    データ分散を行うにあたり、まず考えることはトポロジーの形成と他のノードからデータの伝搬の仕方である。

    +

    Jungleはこの問題に対し、ツリートポロジーを形成し、データ編集の際に発生するcommit logを他のノードに流すことで解決する。

    +
    + +
    +

    + Jungleの分散設計:トポロジー形成とログによるデータ分散 +

    + +
    ツリートポロジーを形成 commit log伝搬によるデータ分散
    - -
    + + + + + + + + +
    ツリートポロジーを形成commit log伝搬によるデータ分散
    + + + +
    +

    サーバノード同士でツリートポロジーを形成する。データ編集をどのように行ったのかを示すログ commit log を伝搬させデータの分散を行う。

    +
    +
    + +
    +

    + 非破壊的木構造の利点を活かした分散設計 +

    +

    Jungleで扱うつもりのデータは結果整合性でもよいCMSを想定していることを始めに説明した。

    +

    そこでJungleはMergeを使うことでデータの整合性をとることにした。

    +

    Mergeとは、2つ以上の変更を1つの変更にまとめることである。

    +

    分散システムにおいては、2つ以上のデータの更新が同じデータに対して行われていた場合、 + 更新を受け取って新しいデータを作ることを指す。

    +

    Mergeは自動で解決出来る場合とそうでない場合がある。

    +
    + + +
    +

    + Mergeによる更新の衝突を自然に解決 +

    + + + + + + + + +

    +

    上の図は通常のデータ更新を示す

    +

    下の図は、同じ木に対して2つのデータの更新があったが編集を無事終えるケースを示す

    +
    +
    + + + +
    +

    + Mergeによる更新の衝突が自然に解決できない場合 +

    + + + + +

    +

    木の同じノードに対してデータの編集が行われた場合、どのような編集結果にすればよいかわからない。

    +

    どのような木が組まれ、どのようにデータを保存するかはアプリケーション毎に変わってくる。そのため、アプリケーション毎に + Mergeアルゴリズムは考えなくてはならない。

    + +
    + +
    +

    + JungleとMergeの相性 +

    +

    Jungleは非破壊で過去のデータも保持しているため、更新時に過去のデータを参照して自然なMergeを行うことが可能。

    +

    自然にMergeできない場合においても、アプリケーション毎にMergeアルゴリズムを設計することで対応する。

    +

    Mergeが自動で行われるようになれば、Jungleで扱う木構造データは編集を自由に行うことができる。

    +

    木構造データが自由に行えるようになれば、Jungleはデータのリクエストに対して手元のデータを返すことができる。

    +

    古いデータを編集されたものが更新されても、いずれはMergeにより最新のデータと合わせられるから。

    +

    +
    + + +
    +

    + Jungleの分散実装 +

    +

    以上がJungleにおける分散設計になる。

    +
    +

    この分散設計を元にJungleのサーバノード同士でツリトポロジーを構成し、ログによるデータ分散を実装した。

    +

    また、Mergeの例として掲示板プログラムにおけるMergeの実装も行った。

    +
    + + + +
    +

    + Jungleの分散実装:掲示板システムにおけるMerge +

    +

    Jungleではアプリケーション毎にMergeアルゴリズムを設計

    +

    後述する性能比較に用いた掲示板システムにおけるMergeの実装を考える

    +

    掲示板システムにおけるデータ構造を以下に示す

    +

    + +

    +
    + +
    +

    + Jungleの分散実装:掲示板システムにおけるMerge +

    + + + + + + + + + + + + + + +

    1

    2

    3

    +
    +
    + +
    +

    + 分散データベースJungleの評価 +

    +

    分散データベースとしてJungleの性能を評価する。

    +

    分散Key-ValueデーターべースCassandraと比較を行う。

    +

    比較方法は、Jungle, Cassandra をそれぞれバックエンドとした簡易掲示板を作成する。

    +

    掲示板に対してHTTP Requestで並列に読み込みと書き込みの負荷をかけ計測する。

    +

    レスポンスが返る平均時間と標準偏差を求めグラフ化する

    +
    + + +
    +

    + JungleとCassandraの比較方法 +

    +

    実験は以下の2つを行う

    + + + + + + + + + + + + + +
    実験1:サーバ単体への負荷実験2:複数台のサーバに対する負荷

    複数のクライアントから単体のサーバへ負荷をかける

    複数のクライアントから複数のサーバへ負荷をかける

    +

    サーバ単体の性能と, 分散環境下における性能の2つを調べる。

    +

    分散環境下におけるノードは全て繋がっている

    +
    +
    + +
    +

    + 実験に使用するサーバの仕様 +

    + + + + + + + + + + + + + + + + + + + + + + + + + +
    ブレードサーバ
    CPUIntel(R) Xeon(R) CPU X5650@2.67GHz
    コア数24
    Memory132GB
    OSFedora 16
    HyperVisorなし(物理マシン)
    + +

    並列環境

    +
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    VMWareクラスタKVMクラスタ
    台数4812
    CPUIntel(R) Xeon(R) CPU X5650@2.67GHzIntel(R) Xeon(R) CPU X5650@2.67GHz
    コア数44
    Memory8GB8GB
    OSFedora 16Fedora 16
    HyperVisorVMWare ESXiKVM (Linux Fedora 16)
    + +
    + + +
    +

    + 実験1:単体サーバへの負荷 +

    +

    + +

    +
    + +
    +

    + 実験1:単体サーバへの負荷(読み込み) +

    + +

    ブレードサーバ一台に対して複数のクライアントからの負荷

    + + + + + + + +
    読み込みの実験結果
    +

    JungleがCassandraより良い結果を示している

    +

    クライアントが55台のときのJungleの最速とCassandraの最遅は3倍近く離れている

    +
    +
    + +
    +

    + 実験1:単体サーバへの負荷(書き込み) +

    + +

    ブレードサーバ一台に対して複数のクライアントからの負荷

    + + + + + + + +
    書き込みの実験結果
    +

    読み込み同様Jungleのほうが良い結果を示している

    +

    読み込みよりJungleとCassandraの結果が重なる部分が減っている

    +
    +
    + +
    +

    + 実験1の考察 +

    +

    読み込み、書き込みともにJungleの性能がよく。平均だけみても2倍以上早い部分もある。

    +

    特に書き込みに関してはクライアントの数が増えるにつれ差が開いている。

    + +

    これはJungleが全体的にロックが少ないことが要因としてあげられる。 +

    Jungleは非破壊でデータの保持をするため、読み込みは自由に行える。書き込み時には木のコピーをとりルートノードを入れ替える + ときのみロックが発生する。

    +
    + +
    +

    + 実験2:分散環境下における負荷 +

    +

    + +

    +
    + +
    +

    + 実験2:分散環境下における読み込み +

    + + + + + + + +
    +
    読み込みの実験結果
    +

    CassandraはConsistency Level ONE(赤)とQUORUM(緑)両方を測定

    +

    Jungleは1秒から5秒をキープ

    +
    +
    + +
    +

    + 実験2:分散環境下における書き込み +

    + + + + + + + +
    +
    書き込みの実験結果
    +

    CassandraはConsistency Level ONE(赤)とQUORUM(緑)両方を測定

    +

    Jungleは5.5秒から7.3秒をキープ

    +
    +
    + + +
    +

    + 実験2の考察 +

    +

    こちらもJungleがCassadraより良い結果を示した。実験1よりも差がでている。

    +

    Jungleのグラフが横ばいになっていることに注目したい。

    + +

    Jungleはリクエストに対し手元にあるデータを返す。そのためノードの数が増えてもレスポンスの早さを維持できる。

    +

    Cassandraはデータを持っている数台のノードに読み込みに行くという作業が入るためJungleより遅くなってしまう

    +

    Jungleは同期を取らないためデータ全体の整合性は落ちるが、分散管理システムを参考にした設計の有用性を示すことができた。

    +
    + + +
    +

    + まとめ +

    +

    本研究では非破壊的木構造Jungleに分散データベースの実装を行った

    +

    非破壊的木構造における利点を述べ、スケーラビリティの高い分散版管理システムとの類似性を述べた

    +

    Mergeアルゴリズムの1つとして掲示板プログラムにおけるMergeについて設計・実装を行った

    +

    性能比較の実験のためJungle、Cassandraで利用できる簡易掲示板の作成を行った

    +

    実験は単体サーバと分散環境下において行い、どちらともCassandraよりよい結果をえることができた

    +
    + + +
    +

    + 今後の課題 +

    +

    データ分割の実装

    +
      +
    • 現在の実装は全てのノードで全てのデータを持たせている
    • +
    • この方法ではメモリの使用量が高いこととネットワーク帯域への負荷が懸念される
    • +
    • ノード単位で保持するデータを分ける実装が必要
    • +
    • その場合、木構造単位でノード毎にデータを分ける
    • +
    • 持っていないデータの要求が来た場合は、データを持っているノードに取りに行くようにする
    • +
    +
    + +
    +

    + 今後の課題 +

    +

    Mergeアルゴリズムの設計

    +
      +
    • JungleはMergeを使うことで更新データ衝突の問題を解決する。
    • +
    • 今回実装した掲示板プログラムにおけるMergeは単純なもの。
    • +
    • 他のアプリケーションではどのようにMergeを行うのか考察が必要。
    • +
    +
    + + +
    +

    + 今後の課題 +

    +

    過去のデータの掃除について

    +
      +
    • Jungleは非破壊でデータを保持するため過去のメモリの使用量が大きい
    • +
    • ある程度の単位で過去のデータの掃除を行いたい
    • +
    • そのためにはどのノードがどのデータを持っているかという情報を扱うことが必要
    • +
    • どれくらいデータが古くなると掃除を行うか判断が必要
    • +
    +
    + +
    +

    +

    +

    +
      +
    +
    + +
    +

    + Mergeは必ずできるのか +

    +

    Mergeを必ず行うことは難しい

    +

    例えば、更新するデータが画像だった場合、2つの画像のデータから新しい画像を作るわけにはいかない。

    +

    後に更新したものを優先するといった方法をとるか、ユーザの選択に委ねるしかない。

    +
    + + +
    +

    + 分散Key-ValueストアCassandraの特徴 +

    + +

    ring型トポロジーを形成。ring上にはHash値があり、書き込むデータのキーのハッシュ値により書き込むノードを決定

    +

    1つのデータの複製を最大何とるかというReplication factorの設定がある。

    +

    Consistency Levelというデータの読み書きの際に何台のノードから読み書きするかを決定できる

    +

    Consistency LevelにはONE,QUORUM,ALLがある。QUORUMはReplication factorの数/2+1 のノードに読み書きする。

    +
    +

    + +

    +
    + + +
    +

    + Jungleの分散設計:分散版管理システム +

    +

    Jungleは分散設計を行うにあたってGitやMercurialといった分散版管理システムを意識している

    +

    分散版管理システムとは多人数によるソフトウェア開発において変更履歴を管理するシステム

    +

    分散版管理システムは次の特徴とAPIを持つ

    +
      +
    • 開発者それぞれがリポジトリのクローンしてローカルに持ち、開発はローカルのリポジトリを通すことで行われる
    • +
    • ローカルのリポジトリは独立に存在し、サーバ上にある他人のリポジトリから変更履歴をとることができる。また自身の変更履歴を伝えることもできる
    • +
    • データ更新時に先に別の更新が入っていた(衝突)場合はMergeによりデータの整合性をとる
    • +
    +
    + +
    +

    + Jungleの分散設計:分散版管理システム +

    +

    分散版管理システムAPI

    +
      +
    • commit:データに変更を加えたことをリポジトリに登録
    • +
    • push:ローカルのリポジトリで行った変更履歴を他のリポジトリへまとめて送る
    • +
    • pull:他のリポジトリからの変更履歴をまとめて受け取る
    • +
    +

    + +

    + +

    分版版管理システムはリポジトリが壊れても別のリポジトリよりデータを復旧できることと、push/pullそれとMergeによる整合性 + の確保で、高いスケーラビリティを持っている

    +
    +
    + +
    +

    + Jungleの分散設計:分散版管理システム +

    +

    Jungleと分散版管理システムには似通った点がある

    +
  • どちらもデータのコピーが自由
  • +
  • データ更新しても過去のデータに影響を与えない
  • +
    +

    同じAPIを実装することで、分散版管理システムと同じく高いスケーラビリティが期待できる

    +

    具体的には

    +
      +
    • pushやpullによる定期的なデータの更新
    • +
    • Mergeによる更新データ衝突の解決
    • +
    +
    + + + + + + diff -r e36cbf39a949 -r 07aec327a7bc slides/slides.html --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/slides/slides.html Mon Feb 03 13:06:41 2014 +0900 @@ -0,0 +1,296 @@ + + + + + 分散 Database Jungle に関する研究 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    + +
    + + + +
    +

    分散 Database Jungleに関する研究

    +
      +

      琉球大学 大城信康 +
      + Feb 3, 2013 +

      +
    +
    + +
    +

    概要

    +

    非破壊的木構造データベースJungleに分散実装を行い掲示板システムに特化したデーターベースを作成し、その評価を行った。

    +

    分散データベースCassandraより2倍以上速く、分散環境下においては10倍以上速くなる結果も確認された。

    +
    +
    + +
    +

    研究の背景と目的

    +

    ウェブサービスにとってデータベースは必須であり、ウェブサービスの規模に比例してデータベースへの負荷も高まる。

    +

    データベースの処理能力の高さはそのままウェブサービスの質に繋がるため、データベースのスケーラビリティの確保は重要である。

    +

    スケーラビリティ確保の方法としてデータ分散があるが、分散する方法により性能も変わってくる。

    +
    + +
    +

    + ウェブサービスにおけるデータベースの重要性 +

    +

    ウェブサービスへの負荷が高まることは、データベースへの負荷が高まることでもある。

    +

    データベースの性能が低ければ負荷に耐え切れずサービスはダウンする

    +

    + +

    +

    そのため、データベースにはスケーラビリティが必要

    +
    + +
    +

    + スケーラビリティとは +

    +

    システムが負荷の増大に対して柔軟に拡張して対応できる性質

    +

    主に次の2つの方法によりシステムはスケールされる

    +
      +
    • スケールアップ
      高価な単一マシンによる性能アップ
    • +
      +
    • スケールアウト
      汎用的なマシンを複数台用意することで性能アップ
    • +
    +

    分散システムにおいてはスケールアウトによりスケーラビリティを高める

    +
    + +
    +

    + データベースのスケーラビリティ +

    +

    データベースのスケーラビリティを考えるとき、どういう用途で使用するかを考えるのが重要。

    +
  • 例えば、掲示板システムにおいては、書き込みと読み込みが速いことが求められる。
  • +
    +

    ウェブサービスにおいても、どのようなサービスを行うかによってスケーラビリティの確保の仕方も変わってくる。

    +

    本研究で開発しているデータベースはコンテンツマネジメントシステム(CMS)を対象としている。

    +

    + +

    + +
    + +
    +

    + コンテンツマネジメントシステム(CMS) +

    +

    Webコンテンツを構成するテキストや画像などのデジタルコンテンツを管理し配信するシステム。

    +
  • 例:ブログツール、Wiki
  • +

    分散コンテンツマネジメントシステムに求められること。

    +
  • Webコンテンツを分散して管理
  • +
  • スケールアウトするシステム
  • +

    データ全体の整合性に遅延がある、結果整合性でもよい。書き込みや読み込みを優先としたデータベースが必要。

    +

    そこで、非破壊的木構造データベースJungleの提案を行った。

    +
    + +
    +

    + 非破壊的木構造データベースJungle +

    +

    JungleはスケーラビリティのあるCMSの設計を目指して当研究室で開発されているデータベース。

    +

    データを木構造で、さらに非破壊で保持する。

    +
    + +
    +

    + 非破壊的木構造 +

    +

    非破壊的木構造は一度作成したデータは変更しない

    +

    新しい木構造を作成することでデータの編集を行う

    +

    + +

    +
    + +
    +

    + 非破壊的木構造の利点 +

    +

    非破壊的木構造は通常の木構造である破壊的木構造に比べ、以下のような利点を持つ

    +
      +
    • 一度作成したデータは変更されない
    • +
    • データが変更されないため自由にコピーを作ることができる(いつでも読み込みが可能)
    • +
    • ロックがすくない。ロックが必要なのは最新のルートノードを登録するときだけ
    • +
    +

    ロックが少なく、いつでもコピーが可能なことから、非破壊的木構造はスケーラブルなシステムに有用となる

    +
    + +
    +

    + Jungleの分散設計 +

    +

    ここまでJungleに実装されている非破壊的木構造の利点について述べた。

    +

    次に、Jungleにおける分散設計について述べる。

    +

    データ分散を行うにあたり、まず考えることはトポロジーの形成と他のノードからデータの伝搬の仕方である。

    +

    Jungleはこの問題に対し、ツリートポロジーを形成し、データ編集の際に発生するcommit logを他のノードに流すことで解決する。

    +
    + +
    +

    + Jungleトポロジーの形成 +

    +

    Jungleのトポロジー形成には当研究室で開発している並列分散フレームワークAliceを使用する。

    +

    Aliceは以下の機能が提供されている

    +
      +
    • 複数のノードによる分散トポロジーの設定
    • +
    • トポロジー上でのデータアクセス機構
    • +
    +

    JungleにAliceを組み込み、Jungleのノード同士でトポロジーを形成する。

    +

    Aliceの機能である他ノードへのデータアクセス機構を使用してデータ分散を行う。

    + +
    + +
    +

    + Jungleの分散設計: データ変更コマンドのAPI +

    + + +
    + +
    +

    + +

    + + +
    + + + +
    +

    + 掲示板システムにおけるMerge +

    +

    + +

    +

    2つの状態をもつ掲示板の書き込みができる。

    +

    掲示板はcommutativeなため、Mergeが自然に行える。

    +
    + + + +
    +

    + Jungleの分散設計:トポロジー形成とログによるデータ分散 +

    + + + + + + + +
    commit log伝搬によるデータ分散
    + +
    +

    サーバノード同士でツリートポロジーを形成する。データ編集をどのように行ったのかを示すログ commit log を伝搬させデータの分散を行う。

    +
    + +
    +

    + +

    + +
    + +
    +

    + +

    + +
    + +
    +

    + +

    + +
    + + + + + +
    + +