--- a/shoshi-paper.aux	Mon Aug 23 16:04:17 2010 +0900
+++ b/shoshi-paper.aux	Mon Aug 23 17:34:52 2010 +0900
@@ -1,31 +1,34 @@
 \relax 
+\citation{YCSB}
 \@writefile{toc}{\contentsline {section}{\numberline {1}はじめに}{1}}
-\@writefile{toc}{\contentsline {section}{\numberline {2}分散データベース Cassandra}{1}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {2.\,1}ConsictencyLevel}{1}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {2.\,2}コンシステント・ハッシュ}{2}}
+\@writefile{toc}{\contentsline {section}{\numberline {2}先行研究}{1}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {2.\,1}Yahoo! Cloud Serving Benchmark}{1}}
+\@writefile{toc}{\contentsline {section}{\numberline {3}分散データベース Cassandra}{1}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {3.\,1}ConsictencyLevel}{1}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {3.\,2}コンシステント・ハッシュ}{2}}
 \newlabel{fig:chash}{{1}{2}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {2.\,3}SEDA}{2}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {3.\,3}SEDA}{2}}
 \newlabel{fig:seda}{{2}{3}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {2.\,4}Cassandra上でのステージの構成}{3}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {2.\,5}YukiWiki on Cassandra}{3}}
-\@writefile{toc}{\contentsline {section}{\numberline {3}実験}{3}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {3.\,1}実験環境}{3}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {3.\,2}実験方法}{3}}
-\newlabel{tab:mysql_tbl_def}{{1}{3}}
-\@writefile{toc}{\contentsline {section}{\numberline {4}実験結果と考察}{4}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {4.\,1}単純なベンチマーク}{4}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {4.\,2}コア数の少ないサーバー上でのベンチマーク}{4}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {3.\,4}Cassandra上でのステージの構成}{3}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {3.\,5}YukiWiki on Cassandra}{3}}
+\@writefile{toc}{\contentsline {section}{\numberline {4}実験}{3}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {4.\,1}実験環境}{3}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {4.\,2}実験方法}{3}}
+\newlabel{tab:mysql_tbl_def}{{1}{4}}
+\@writefile{toc}{\contentsline {section}{\numberline {5}実験結果と考察}{4}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {5.\,1}単純なベンチマーク}{4}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {5.\,2}コア数の少ないサーバー上でのベンチマーク}{4}}
 \newlabel{fig:bench2-R}{{3}{4}}
 \newlabel{fig:bench2-W}{{4}{4}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {4.\,3}コア数の多いサーバー上でのベンチマーク}{4}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {5.\,3}コア数の多いサーバー上でのベンチマーク}{4}}
 \newlabel{fig:bench3-R}{{5}{5}}
 \newlabel{fig:bench3-W}{{6}{5}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {4.\,4}複数ノードで構成したCassadraのベンチマーク}{5}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {5.\,4}複数ノードで構成したCassadraのベンチマーク}{5}}
 \newlabel{fig:bench4-R}{{7}{5}}
 \newlabel{fig:bench4-W}{{8}{5}}
-\bibcite{LS86}{1}
-\bibcite{LS86}{2}
-\bibcite{LS86}{3}
-\bibcite{LS86}{4}
-\@writefile{toc}{\contentsline {section}{\numberline {5}まとめ}{6}}
-\@writefile{toc}{\contentsline {section}{\numberline {6}今後の課題}{6}}
+\bibcite{YCSB}{1}
+\bibcite{SEDA1}{2}
+\bibcite{SEDA2}{3}
+\bibcite{BIGTABLE}{4}
+\@writefile{toc}{\contentsline {section}{\numberline {6}まとめ}{6}}
+\@writefile{toc}{\contentsline {section}{\numberline {7}今後の課題}{6}}

Binary file shoshi-paper.pdf has changed

--- a/shoshi-paper.tex	Mon Aug 23 16:04:17 2010 +0900
+++ b/shoshi-paper.tex	Mon Aug 23 17:34:52 2010 +0900
@@ -43,7 +43,7 @@
 %
 % 和文アブストラクト
 \Jabstract{
-現在, 数ある分散Key-Valueストアの中でもCassandraが注目を集めている. 
+数ある分散Key-Valueストアの中でもCassandraが注目を集めている. 
 CassandraはConsitency levelの変更が可能であり、スケーラビリテイを
 高めるための使い方には工夫が必要である. 
 本研究では, Cassandra上で動作するCMSを実装し学科のクラスタ上で動作させ
@@ -60,12 +60,15 @@
 %
 
 \section{はじめに}
-インターネットやスマートフォンなどの普及に伴い，インターネット上のサービスを使用するユーザーが急速に増え続けている．サービスを利用するユーザーが増えると，いままでのシステムでは膨大なアクセスに対応できなくなり，サービスの品質を維持することができなる．
-品質を維持するためには，使用するサーバー性能の向上を測ればよい．しかし，性能の良いサーバーを揃えるには膨大なコストを必要とし，これをスケールアップと呼ぶ．
+インターネットやスマートフォンなどの普及に伴い，インターネット上のサービスを使用するユーザーが急速に増え続けている．サービスを利用するユーザーが増えると，いままでのシステムでは膨大なアクセスに対応できなくなり，サービスの品質を維持することができなくなる．
+%品質を維持するためには，使用するサーバー性能の向上を測ればよい．しかし，性能の良いサーバーを揃えるには膨大なコストを必要とし，これをスケールアップと呼ぶ．
 そこで，安価なサーバーを複数用意し，連携させることによって性能を向上させる方法があり，これをスケールアウトと呼ぶ．この方法では，従来使用してきたソフトウェアを複数のサーバーに移動するだけではうまく動作しない．
 複数のサーバーを強調させるのは難しく，データの整合性や通信速度，負荷分散など様々な考慮をしなければならないためである．
 Cassandraは複数のサーバーで動作を想定した分散データベースである．
-本研究では，実際に分散させることによって高価なサーバーを超えることが出来る性能を出すことが出来るのか，また，どの様にCassandra上で動くソフトウェアを開発することによって性能を発揮することが出来るのかを，９０台のPCクラスタ上でベンチマークを取り検証する．
+本研究では，実際に分散させることによって高価なサーバーを超えることが出来る性能を出すことが出来るのか，また，どの様にCassandra上で動くソフトウェアを開発することによって性能を発揮することが出来るのかを，９０台のPCクラスタ上でベンチマークを取り検証した，その結果，コア数の多いサーバー上で高い性能を得ることが出来た．
+\section{先行研究}
+\subsection{Yahoo! Cloud Serving Benchmark}
+数のデータベース（Sherpa,BitTable,Azure）などがあるが, 実際にはどのデータベースを使用すればよいか確かではない. この研究では, 異なるデータベースの性能を比較する共通なフレームワークを開発する．\cite{YCSB}
 \section{分散データベース Cassandra}
 Cassandraは, FaceBookが自社のために開発した分散Key-Valueストアデータベースである. 2008年にオープンソースとして公開され, 2009年にApache Incubatorのプロジェクトとなった. 2010年にはApacheのトップレベルプロジェクトとなり, 現在でも頻繁にバージョンアップが行われている. 
 \subsection{ConsictencyLevel}
@@ -100,7 +103,7 @@
 ReplicationFactorのノード数に書き込みを終えてからレスポンスを返す. 
 \end{enumerate}
 \subsection{コンシステント・ハッシュ}
-Cassandraは複数のノードにデータを分散して格納する. その為に使用されているのがコンシステント・ハッシュである. 普通, n台で構成されたノードにデータを分散する場合, HASH(key) mod nで分散させる. この場合だと, ノードが追加・削除された場合すべてのデータの位置を再計算する必要があり面倒である. 
+Cassandraは複数のノードにデータを分散して格納する. その為に使用されているのがコンシステント・ハッシュである. 普通, n台で構成されたノードにデータを分散する場合, hash(key) mod nで分散させる. この場合だと, ノードが追加・削除された場合すべてのデータの位置を再計算する必要があり面倒である. 
 
 そこで, 図\ref{fig:chash}のようなものを考える. 図\ref{fig:chash}はハッシュ関数が取りうる値を範囲としたリングである. このリング上に構成するノードを配置していく. この図の場合, アルファベットがノードで数字がデータ, 矢印が担当するノードである. 
 次に, ハッシュ関数により計算された値をリングの上に配置する. このとき, リングを右回りに周り一番最初にあたったノードがデータを担当するノードとする. 
@@ -151,13 +154,13 @@
 \item{Mem : 1GB}
 \item{O S : CentOS 5}
 \end{itemize}
-\item{実験用サーバー1( MacMini )}
+\item{MacMini}
 \begin{itemize}
 \item{CPU : Core2 Duo}
 \item{Mem : 4GB}
 \item{O S : OSX SnowLeopard}
 \end{itemize}
-\item{実験用サーバー2}
+\item{Core i7}
 \begin{itemize}
 \item{CPU : Core i7 950 @3.0GHz}
 \item{Mem : 16GB}
@@ -196,8 +199,8 @@
 \begin{center}
 \begin{tabular}{|c|c|c|}  \hline
 & Cassandra & MySQL \\ \hline
-サーバー1 & 13.72s & 5.94s \\ \hline
-サーバー2 & 12.56s & 3.99s \\ \hline
+MacMini& 13.72s & 5.94s \\ \hline
+Core i7& 12.56s & 3.99s \\ \hline
 \end{tabular}
 \end{center}
 \vspace{5mm}
@@ -205,13 +208,13 @@
 \begin{center}
 \begin{tabular}{|c|c|c|} \hline
 & Cassandra & MySQL \\ \hline
-サーバー1 & 11.75s & 5.7s \\ \hline
-サーバー2 & 9.62s & 5.3s \\ \hline
+MacMini& 11.75s & 5.7s \\ \hline
+Core i7& 9.62s & 5.3s \\ \hline
 \end{tabular}
 \end{center}
 \end{table}
 \subsection{コア数の少ないサーバー上でのベンチマーク}
-次に, クライアントを並列化しての実験を行う. ここでは, コア数の少ないサーバー1を用いる. クライアントの並列化はスクリプトを指定した時間に同時起動するようにして実装した. 
+次に, クライアントを並列化しての実験を行う. ここでは, コア数の少ないMacMiniを用いる. クライアントの並列化はスクリプトを指定した時間に同時起動するようにして実装した. 
 実験結果を図\ref{fig:bench2-R}と図\ref{fig:bench2-W}に示す. 
 
 Readは両方とも, 同じような推移の仕方をしているが, Cassandraの方が遅い. しかし, WriteはCassandraの方が断然速く動作している. この実験では, Cassandraの動作を基準に考えたため書き込みのコマンドにREPLACEを使用した. REPLACEは置き換えるようなコマンドである. そのため, INSERTに比べて多少遅くなる. それがこのグラフに出ているのではないかと考えられる. SEDAは複数のスレッドで動作しているためコア数が少ないサーバーでは性能が出にくいことがわかる. 
@@ -219,71 +222,73 @@
 \begin{center}
 	\scalebox{0.33}{\includegraphics{./fig/serv1_read.pdf}}
 \end{center}
-\caption{サーバー1上でのベンチマーク(Read)}
+\caption{MacMini上でのベンチマーク(Read)}
 \label{fig:bench2-R}
 \end{figure}
 \begin{figure}[h]
 \begin{center}
 	\scalebox{0.33}{\includegraphics{./fig/serv1_write.pdf}}
 \end{center}
-\caption{サーバー1上でのベンチマーク(Write)}
+\caption{MacMini上でのベンチマーク(Write)}
 \label{fig:bench2-W}
 \end{figure}
 \subsection{コア数の多いサーバー上でのベンチマーク}
-クライアントを並列化した状態で, コア数の多いサーバー2を用いたベンチマークを行う. 実験結果を図\ref{fig:bench3-R}と図\ref{fig:bench3-W}に示す. 
+クライアントを並列化した状態で, コア数の多いCore i7を用いたベンチマークを行う. 実験結果を図\ref{fig:bench3-R}と図\ref{fig:bench3-W}に示す. 
 
-Read/Write共にMySQLの性能を超えることに成功した. Readにおいてはコア数が少ない場合に超えることが出来なかったが, 並列度が70度付近でMySQLを超えることが出来ている. Cassandraの平均時間は並列度がましても, MySQLよりは平均時間の増加度が少ない. これは, SEDAの特徴である, 多くのタスクを並列に実行すると性能がでるという部分が確認することが出来た. また, SEDAはマルチスレッド前提であるため, コア数が少ないサーバー1では性能が出ず, コア数の多いサーバー2で性能が発揮できるということがわかった. 
+Read/Write共にMySQLの性能を超えることに成功した. Readにおいてはコア数が少ない場合に超えることが出来なかったが, 並列度が70度付近でMySQLを上回る正農がでている.
+Cassandraの平均時間は並列度が増加しても, MySQLよりは平均時間の上昇は少ない. これは, SEDAの特徴である, 多くのタスクを並列に実行すると性能を発揮することを確認することが出来た. 
+また, SEDAはマルチスレッド前提であるため, コア数が少ないMacMiniでは性能が出ず, コア数の多いCore i7で性能が発揮できるということが分かる．
 
 つまり, Cassandraは負荷が高いときにMySQLを超える性能を出すことが出来る. 負荷がかかっても性能の劣化が少ないことを考えると考えると遅延をあまり考慮しなくても済むのではないだろうか. 
 \begin{figure}[h]
 \begin{center}
 	\scalebox{0.33}{\includegraphics{./fig/serv2_read.pdf}}
 \end{center}
-\caption{サーバー2上でのベンチマーク(Read)}
+\caption{Core i7上でのベンチマーク(Read)}
 \label{fig:bench3-R}
 \end{figure}
 \begin{figure}[h]
 \begin{center}
 	\scalebox{0.33}{\includegraphics{./fig/serv2_write.pdf}}
 \end{center}
-\caption{サーバー2上でのベンチマーク(Write)}
+\caption{Core i7上でのベンチマーク(Write)}
 \label{fig:bench3-W}
 \end{figure}
 \subsection{複数ノードで構成したCassadraのベンチマーク}
-最後に分散しなかったCassandraと複数ノードで構成したCassandraの比較を行う. サーバーはサーバー1を5台使用して行った. 実験結果を図\ref{fig:bench4-R}と図\ref{fig:bench4-W}に示す. 
-
-Read/Writeともに, 今回の場合は分散を行わなかったほうが性能を引き出せてることが分る. これは, 実験に使用したデータがRead/Write共に1つだけで, 結局は同じノードにリクエストが転送されている. そのため, リクエストは1台のノードに集中する. よって, 性能が出ないのではないかと考えられる. Cassandraをただ増やすだけでは性能は得ることが出来ず, データも分散させて実験を行わないといけないことがわかった. 
+最後に分散しなかったCassandraと複数ノードで構成したCassandraの比較を行う. サーバーはMacMiniを5台使用して行った. 実験結果を図\ref{fig:bench4-R}と図\ref{fig:bench4-W}に示す. 
+Read/Writeともに, 今回の場合は分散を行わなかったほうが性能を引き出せてることが分る. これは, 実験に使用したデータがRead/Write共に1つだけで, 結局は同じノードにリクエストが転送されている. そのため, リクエストは1台のノードに集中する. よって, 性能が出ないのではないかと考えられる. Cassandraをただ増やすだけでは性能は得ることが出来ず, データも分散させて実験を行わなければならない.
 \begin{figure}[h]
 \begin{center}
 	\scalebox{0.33}{\includegraphics{./fig/cluster_read.pdf}}
 \end{center}
-\caption{サーバー1を複数ノードにしたベンチマーク(Read)}
+\caption{MacMiniを複数ノードにしたベンチマーク(Read)}
 \label{fig:bench4-R}
 \end{figure}
 \begin{figure}[h]
 \begin{center}
 	\scalebox{0.33}{\includegraphics{./fig/cluster_write.pdf}}
 \end{center}
-\caption{サーバー1を複数ノードにしたベンチマーク(Write)}
+\caption{MacMiniを複数ノードにしたベンチマーク(Write)}
 \label{fig:bench4-W}
 \end{figure}
 \newpage
 \section{まとめ}
-今回の実験で, Cassandraを使用するには従来の使用方法ではいけないということがわかった. Cassandraはコア数が少ない場合, ReadはMySQLより遅いがほぼ同し推移の仕方をする. Writeは，コア数が少なくてもクライアントの並列度を高く設定すれば，MySQLに勝つことがある．
-コア数が多い場合，Read・Write共に，初めはやはりMySQLの方が動作が早いが，グラフの傾きはMySQLの方が大きくCassandraはかなり緩やかである．特にCassandraのWhiteの性能は高く, MySQLを大きく上回っている．
+Cassandraは従来の使用方法では性能を発揮することが出来ずコア数が多いサーバーでクライアントの並列度が高い場合に性能を発揮する. 
+これは，ベンチマークの結果を考察すると，コア数が少ない場合ReadはMySQLより遅いがほぼ同し推移の仕方をする. Writeは，コア数が少なくてもクライアントの並列度を高く設定すればMySQLより性能が出る．
+コア数が多い場合，Read・Write共に，初めはやはりMySQLの方が動作が早いが，グラフの傾きはMySQLの方が大きくCassandraは緩やかである．特にCassandraのWhiteの性能は高く, MySQLを大きく上回っている．
 また, 単純にCassandraのノード数を増やしても性能は高くならない. これは, データも綺麗に分散させてあげないとデータを読み込む際に一定のノードに集中してしまい，他のノードにアクセスを分散しても結局は保持しているノードに聞きに行かないといけないことになるからである． 
-データもある程度分散させなければならないため，汎用的なHASH関数では性能が発揮できなく, そのアプリケーション専用の関数が必要だと思われる. 
-格納されるデータを決めるのにPartitionerというものがあり, それを利用することで実装できると思われる．
+データもある程度分散させなければならないため，汎用的なhash関数では性能が発揮できなく, そのアプリケーション専用の関数が必要だと思われる. 
+格納されるデータを決めるのにStrategyというものがあり, それを利用することで実装できると思われる．
 \section{今後の課題}
-今後は, Partitionerを拡張し複数のデータをノードに分散させた環境下でベンチマークを行い, その結果をCassandra単体でのベンチマーク結果と比較したいと考えている. 他にも, 沖縄東京間などの離れた地域での分散をCassandraでどの様に行なっていくか実験していきたい. 
+今後は, Strategyを拡張し複数のデータをノードに分散させた環境下でベンチマークを行い, その結果をCassandra単体でのベンチマーク結果と比較したいと考えている.
 
 %
 \begin{adjustvboxheight} % needed only when Appendix follows
 \begin{thebibliography}{99}
-\bibitem{LS86} Benchmarking Cloud Serving Systems with YCSB
-\bibitem{LS86} The Staged Event-Driven Architecture for Highly-Concurrent Server Applications
-\bibitem{LS86} SEDA : An Architecture for Well-Conditioned , Scalable Internet Services
-\bibitem{LS86} Bigtable : A Distributed Storege System for Structured Data
+\bibitem{YCSB} Benchmarking Cloud Serving Systems with YCSB
+\bibitem{SEDA1} The Staged Event-Driven Architecture for Highly-Concurrent Server Applications
+\bibitem{SEDA2} SEDA : An Architecture for Well-Conditioned , Scalable Internet Services
+\bibitem{BIGTABLE} Bigtable : A Distributed Storege System for Structured Data
 \end{thebibliography}
 \end{adjustvboxheight} % needed only when Appendix follows
 \end{document}