Mercurial > hg > Papers > 2014 > toma-master
annotate paper/chapter2.tex @ 70:0b1a059c49fa
fix
| author | kono |
|---|---|
| date | Thu, 13 Feb 2014 12:08:24 +0900 |
| parents | d15c924e9089 |
| children |
| rev | line source |
|---|---|
| 64 | 1 \chapter[Haskellによる並列データベースの設計]{Haskellによる\\並列データベースの設計}\label{ch:design} |
| 2 | 2 |
| 35 | 3 \section{マルチコアプロセッサで十分な性能を得るためには} |
| 47 | 4 現在, CPU はマルチコア化が進んでいる. |
| 5 マルチコアプロセッサで線形に性能向上をするためには, 処理全体で高い並列度を保つ必要がある. | |
| 6 アムダールの法則\cite{amdahl}によると, 並列度が80 \% の場合, どんなにコア数を増やしても性能向上率は5倍にしかならない. | |
|
40
bd30d93097da
describe Jungle and Tree
Daichi TOMA <toma@cr.ie.u-ryukyu.ac.jp>
parents:
35
diff
changeset
|
7 |
| 47 | 8 % ウェブサービスでは, ニーズの変化に柔軟に対応できる能力が求められる. |
| 9 % 利用者や負荷の増大に対し, CPU のコア数に応じてパフォーマンスを線形に向上できる能力, すなわちスケーラビリティが必要となる. | |
| 10 % スケーラビリティが線形的であれば, リソースの追加に比例したパフォーマンスを得ることが可能である. | |
| 11 % 一方, スケーラビリティが線形的でないと, いくらリソースを追加しても必要なパフォーマンスが得られないというケースもありえる. | |
|
20
ff03e6179f19
describe the design.
Daichi TOMA <toma@cr.ie.u-ryukyu.ac.jp>
parents:
10
diff
changeset
|
12 |
| 47 | 13 CPU コア数に応じて, データベースを線形に性能向上させたい場合, 別々の CPU コアから同時にデータベースへアクセスできるようにし, 並列度を高める必要がある. |
| 14 通常は, 同一のデータへアクセスする場合, 競合が発生してしまい処理性能に限界が生じる. | |
| 9 | 15 |
| 47 | 16 本研究では, 非破壊的木構造という手法を用いて競合が発生する問題を解決する. |
| 17 競合を発生させないためには, 既にあるデータを変更しなければよい. | |
| 18 非破壊的木構造は, 変更元となる木構造を変更しない. | |
| 19 そのため, 別々の CPU コアから並列にアクセスが可能であり, スケーラビリティを実現できる. | |
| 9 | 20 |
|
20
ff03e6179f19
describe the design.
Daichi TOMA <toma@cr.ie.u-ryukyu.ac.jp>
parents:
10
diff
changeset
|
21 \newpage |
| 34 | 22 \section{非破壊的木構造} |
| 47 | 23 非破壊的木構造は, 木構造を書き換えることなく編集を行う手法である. |
| 24 既にあるデータを変更しないため, データの競合状態が発生せず, 並列に読み書きが行える. | |
|
20
ff03e6179f19
describe the design.
Daichi TOMA <toma@cr.ie.u-ryukyu.ac.jp>
parents:
10
diff
changeset
|
25 |
| 47 | 26 また, 元の木構造は破壊されることがないため, 自由にコピーを行うことができる. |
| 27 コピーを複数作成することでアクセスを分散させることも可能である. | |
| 9 | 28 |
| 47 | 29 図\ref{fig:nondestructive_tree_modification}では, ノード 6 をノード A へ書き換える処理を行なっている. |
| 9 | 30 |
| 31 \begin{figure}[!htbp] | |
| 32 \begin{center} | |
| 33 \includegraphics[width=120mm]{./images/nondestructive_tree_modification.pdf} | |
| 34 \end{center} | |
| 35 \caption{木構造の非破壊的編集} | |
| 36 \label{fig:nondestructive_tree_modification} | |
| 37 \end{figure} | |
| 38 | |
| 47 | 39 この編集方法を用いた場合, 閲覧者が木構造を参照してる間に, 木の変更を行っても問題がない. |
| 48 | 40 閲覧者は木が変更されたとしても, 保持しているルートノードから整合性を崩さずに参照が可能である（図\ref{fig:nondestructive_tree_modification_in_lace}）. |
| 47 | 41 排他制御をせずに並列に読み書きが可能であるため, スケーラブルなシステムに有用である. |
| 42 元の木構造は破壊されることがないため, 自由にコピーを作成しても構わない. したがってアクセスの負荷の分散も可能である. | |
| 9 | 43 |
| 44 \begin{figure}[!htbp] | |
| 45 \begin{center} | |
| 46 \includegraphics[width=140mm]{./images/nondestructive_tree_modification_in_lace.pdf} | |
| 47 \end{center} | |
| 48 \caption{並列に読み書きが可能な非破壊的木構造} | |
| 49 \label{fig:nondestructive_tree_modification_in_lace} | |
| 50 \end{figure} | |
| 51 | |
| 52 | |
| 53 \newpage | |
|
20
ff03e6179f19
describe the design.
Daichi TOMA <toma@cr.ie.u-ryukyu.ac.jp>
parents:
10
diff
changeset
|
54 \section{ルートノード} |
| 47 | 55 非破壊的木構造では, ルートノードの管理が重要である. |
| 56 ルートノードは, 木の最新の状態を更新・参照するのに使う. | |
| 57 ルートノードの情報は, 全てのスレッドで共有する必要があり, スレッドセーフに取り扱う必要がある. | |
| 48 | 58 一度ルートノードの情報を取得すれば, その後は自由に木構造へアクセスできる（図\ref{fig:rootnode}）. |
|
20
ff03e6179f19
describe the design.
Daichi TOMA <toma@cr.ie.u-ryukyu.ac.jp>
parents:
10
diff
changeset
|
59 |
|
ff03e6179f19
describe the design.
Daichi TOMA <toma@cr.ie.u-ryukyu.ac.jp>
parents:
10
diff
changeset
|
60 \begin{figure}[!htbp] |
|
ff03e6179f19
describe the design.
Daichi TOMA <toma@cr.ie.u-ryukyu.ac.jp>
parents:
10
diff
changeset
|
61 \begin{center} |
|
ff03e6179f19
describe the design.
Daichi TOMA <toma@cr.ie.u-ryukyu.ac.jp>
parents:
10
diff
changeset
|
62 \includegraphics[scale=0.6]{./images/rootnode.pdf} |
|
ff03e6179f19
describe the design.
Daichi TOMA <toma@cr.ie.u-ryukyu.ac.jp>
parents:
10
diff
changeset
|
63 \end{center} |
| 48 | 64 \caption{非破壊的木構造のアクセス} |
|
20
ff03e6179f19
describe the design.
Daichi TOMA <toma@cr.ie.u-ryukyu.ac.jp>
parents:
10
diff
changeset
|
65 \label{fig:rootnode} |
|
ff03e6179f19
describe the design.
Daichi TOMA <toma@cr.ie.u-ryukyu.ac.jp>
parents:
10
diff
changeset
|
66 \end{figure} |
| 9 | 67 |
| 62 | 68 ルートノードはスレッド間で共有する状態を持つため, Haskell では IO モナドを用いて状態を扱う. |
| 47 | 69 これには, Haskell のソフトウェア・トランザクショナル・メモリ（STM）を利用する. |
| 48 | 70 STM はブロックせず, スレッドセーフに状態を扱うことができる. |
| 47 | 71 STM を利用することでロック忘れによる競合状態や, デッドロックといった問題から解放される. |
| 48 | 72 |
| 47 | 73 STM は, STM モナドという特殊なモナドの中でのみ変更できる. |
| 65 | 74 STMの関数が持つ型をソースコード\ref{src:stm}に示す. |
| 75 | |
| 76 \begin{lstlisting}[label=src:stm, caption=STMの関数] | |
| 77 newTVar :: a -> STM (TVar a) | |
| 78 readTVar :: TVar a -> STM a | |
| 79 writeTVar :: TVar a -> a -> STM () | |
| 80 | |
| 81 atomically :: STM a -> IO a | |
| 82 \end{lstlisting} | |
| 83 | |
| 84 TVar というのは, Transactional variablesの略で, STM で管理する変数に対して利用する. | |
| 85 | |
| 86 新たにSTMで管理する変数を作成するnewTVar, 変数から値を読み込むreadTVar, 変数へ値を書き込むwriteTVarが存在する. | |
| 87 これらの関数をSTM モナドの中で使い単一のアクションのブロックとしてまとめ, atomically コンビネータを使ってトランザクションとして実行する（atomically コンビネータを用いることで IO モナドとして返されるため, I/O操作が可能となる）. | |
| 47 | 88 いったんブロック内に入るとそこから出るまでは, そのブロック内の変更は他のスレッドから見ることはできない. |
| 89 こちら側のスレッドからも他のスレッドによる変更はみることはできず, 実行は完全に孤立して行われる. | |
| 90 トランザクションから出る時に, 以下のことが１つだけ起こる. | |
|
20
ff03e6179f19
describe the design.
Daichi TOMA <toma@cr.ie.u-ryukyu.ac.jp>
parents:
10
diff
changeset
|
91 \begin{itemize} |
| 47 | 92 \item 同じデータを平行して変更したスレッドが他になければ, 加えた変更が他のスレッドから見えるようになる. |
| 93 \item そうでなければ, 変更を実際に実行せずに破棄し, アクションのブロックを再度実行する. | |
|
20
ff03e6179f19
describe the design.
Daichi TOMA <toma@cr.ie.u-ryukyu.ac.jp>
parents:
10
diff
changeset
|
94 \end{itemize} |
| 9 | 95 |
| 48 | 96 STM はロックの管理という煩雑な処理から逃れられるだけでなく, 並列性も向上する. |
| 97 どのスレッドもリソースにアクセスするために待つ必要はない. | |
| 60 | 98 ルートノードの情報の取得は, 並列に行うことが可能である. |
| 47 | 99 ルートノードの情報の更新の場合は, 他から変更があれば再度やり直すということが自動的に行われる. |
|
20
ff03e6179f19
describe the design.
Daichi TOMA <toma@cr.ie.u-ryukyu.ac.jp>
parents:
10
diff
changeset
|
100 |
| 47 | 101 以前の実装では, ルートノードだけではなく非破壊的木構造全体をSTMで管理していた\cite{toma:2013}. |
| 49 | 102 しかし, 非破壊的木構造全体をSTMで管理すると並列実行時に性能が出ないため, ルートノードのみの管理に変更を行った. |