--- a/shoshi-paper.tex	Tue Aug 17 16:47:50 2010 +0900
+++ b/shoshi-paper.tex	Mon Aug 23 16:04:17 2010 +0900
@@ -27,20 +27,22 @@
 % 再定義は原則として避けること. 
 
 \begin{document}
-
 % 論文のタイトル
-\title{Cassandraを使ったアプリケーションのPCクラスタを使ったスケーラビリティの検証}
+\title{Cassandraを使ったCMSのPCクラスタを使ったスケーラビリティの検証}
 
 % 著者
 % 和文論文の場合, 姓と名の間には半角スペースを入れ, 
 % 複数の著者の間は全角スペースで区切る
 %
 \author{玉城 将士 \and 河野 真治
+\shozoku{Shoshi TAMAKI, Shinji KONO}{琉球大学工学部情報工学学科}
+{Dept. \ of Information Engineering, Ryukyu University}
 }
 
+
 %
 % 和文アブストラクト
-\Jabstract{%
+\Jabstract{
 現在, 数ある分散Key-Valueストアの中でもCassandraが注目を集めている. 
 CassandraはConsitency levelの変更が可能であり、スケーラビリテイを
 高めるための使い方には工夫が必要である. 
@@ -48,24 +50,22 @@
 る. 
 特に, CoreDuo などの安価だが非力なマシンの振舞を調べることを行なった. 
 そしてその環境上でスケーラビリティを確認する実験手法に関して考察する. 
-
 }
 %
 % 英文アブストラクト(大会論文には必要なし)
 % \Eabstract{}
-\shozoku{Shoshi TAMAKI, Shinji KONO}{琉球大学工学部情報工学学科}%
-{Dept. \ of Information Engineering, Ryukyu University}
+
+\maketitle
 
 %
-\maketitle
 
 \section{はじめに}
-近年インターネットやスマートフォンなどの普及に伴い, インターネット上のサービスを使用するユーザーが急速に増え続けている. サービスを利用するユーザーが増えると, いままでのシステムでは膨大なアクセスに対応できなくなり, サービスの品質を維持することができなる. 
-品質を維持するためには, 使用するサーバー性能の向上を測ればよい. しかし, 性能の良いサーバーを揃えるには膨大なコストを必要とし, これをスケールアップと呼ぶ. 
-そこで, 安価なサーバーを複数用意し, 連携させることによって性能を向上させる方法があり, これをスケールアウトと呼ぶ. この方法では, 従来使用してきたソフトウェアを複数のサーバーに移動するだけではうまく動作しない. 
-複数のサーバーを強調させるのは難しく, データの整合性や通信速度, 負荷分散など様々な考慮をしなければならないためである. 
-Cassandraは複数のサーバーで動作を想定した分散データベースである. 
-本研究では, 実際に分散させることによって高価なサーバーを超えることが出来る性能を出すことが出来るのか, また, どの様にCassandra上で動くソフトウェアを開発することによって性能を発揮することが出来るのかを, 90台のPCクラスタ上でベンチマークを取り検証する. 
+インターネットやスマートフォンなどの普及に伴い，インターネット上のサービスを使用するユーザーが急速に増え続けている．サービスを利用するユーザーが増えると，いままでのシステムでは膨大なアクセスに対応できなくなり，サービスの品質を維持することができなる．
+品質を維持するためには，使用するサーバー性能の向上を測ればよい．しかし，性能の良いサーバーを揃えるには膨大なコストを必要とし，これをスケールアップと呼ぶ．
+そこで，安価なサーバーを複数用意し，連携させることによって性能を向上させる方法があり，これをスケールアウトと呼ぶ．この方法では，従来使用してきたソフトウェアを複数のサーバーに移動するだけではうまく動作しない．
+複数のサーバーを強調させるのは難しく，データの整合性や通信速度，負荷分散など様々な考慮をしなければならないためである．
+Cassandraは複数のサーバーで動作を想定した分散データベースである．
+本研究では，実際に分散させることによって高価なサーバーを超えることが出来る性能を出すことが出来るのか，また，どの様にCassandra上で動くソフトウェアを開発することによって性能を発揮することが出来るのかを，９０台のPCクラスタ上でベンチマークを取り検証する．
 \section{分散データベース Cassandra}
 Cassandraは, FaceBookが自社のために開発した分散Key-Valueストアデータベースである. 2008年にオープンソースとして公開され, 2009年にApache Incubatorのプロジェクトとなった. 2010年にはApacheのトップレベルプロジェクトとなり, 現在でも頻繁にバージョンアップが行われている. 
 \subsection{ConsictencyLevel}
@@ -108,7 +108,7 @@
 Cassandraでは, 右回りに回ったとき担当するノード数を複数にする場合, ReplicationFactorで調整することが出来る. 
 \begin{figure}[h]
 \begin{center}
-\includegraphics{. /fig/ConsistentHash. pdf}
+\includegraphics{./fig/ConsistentHash.pdf}
 \end{center}
 \caption{コンシステントハッシュ}
 \label{fig:chash}
@@ -120,7 +120,7 @@
 このアーキテクチャはマルチスレッドベースなためマルチコアなPCと多数のタスクがある状況で性能を発揮することができる. しかし, あまりにもスレッドプールやタスクが多すぎると, コンテキストに切り替えに時間がかかり性能は低下する. そのため, Cassandraでは最低4コアを搭載した計算機で動作させることを推奨している. 
 \begin{figure}[h]
 \begin{center}
-\includegraphics{. /fig/SEDA. pdf}
+\includegraphics{./fig/SEDA.pdf}
 \end{center}
 \caption{SEDA}
 \label{fig:seda}
@@ -138,6 +138,9 @@
 \item{MIGRATION STAGE}\\
 \end{itemize}
 実際にはもっと多数のステージが存在し, この他にもクライアントの接続を待つスレッドプールやMemTableのFlushを行うスレッドプールがあり, 全部で40個程度のスレッドが動作している. 
+\subsection{YukiWiki on Cassandra}
+今回の検証のため, CMSのであるWikiクローンのYukiWikiをCassandra上で動作するように改造した．YukiWikiは文書の管理にTIEHASHを使用しており，Cassandra用のTIEHASHを作成することで簡単に実装することが出来る．\\
+Cassandra上で動作するため，このWikiで複数のサーバー上でデータを共有することが出来るようになった．
 \section{実験}
 本研究では, Cassandraのスケーラビリティの検証の為にベンチマークテストを行う. 実験環境は以下のとおりである. 
 \subsection{実験環境}
@@ -156,7 +159,7 @@
 \end{itemize}
 \item{実験用サーバー2}
 \begin{itemize}
-\item{CPU : Core i7 950 @3. 0GHz}
+\item{CPU : Core i7 950 @3.0GHz}
 \item{Mem : 16GB}
 \item{O S : CentOS 5}
 \end{itemize}
@@ -166,9 +169,9 @@
 \item{クライアント}
 クラスタ管理ツールのTorqueを使用し, 使用するノード数を指定してクラスタにジョブを投げてPHPスクリプトを実行させる. このPHPスクリプトはCassandraとMySQLに10000回リクエストを送信するスクリプトである. 
 \item{Cassandra}
-Cassandra 0. 6. 3を使用した. 
+Cassandra 0.6.3を使用した. 
 \item{MySQL}
-MySQL 5. 5を使用した. Cassandraと似たデータ構造を持たせるために表\ref{tab:mysql_tbl_def}のような構造でテーブルを作成した. 
+MySQL 5.5を使用した. Cassandraと似たデータ構造を持たせるために表\ref{tab:mysql_tbl_def}のような構造でテーブルを作成した. 
 \begin{table}[h]
 \caption{テーブルの定義}
 \label{tab:mysql_tbl_def}
@@ -193,8 +196,8 @@
 \begin{center}
 \begin{tabular}{|c|c|c|}  \hline
 & Cassandra & MySQL \\ \hline
-サーバー1 & 13. 72s & 5. 94s \\ \hline
-サーバー2 & 12. 56s & 3. 99s \\ \hline
+サーバー1 & 13.72s & 5.94s \\ \hline
+サーバー2 & 12.56s & 3.99s \\ \hline
 \end{tabular}
 \end{center}
 \vspace{5mm}
@@ -202,8 +205,8 @@
 \begin{center}
 \begin{tabular}{|c|c|c|} \hline
 & Cassandra & MySQL \\ \hline
-サーバー1 & 11. 75s & 5. 7s \\ \hline
-サーバー2 & 9. 62s & 5. 3s \\ \hline
+サーバー1 & 11.75s & 5.7s \\ \hline
+サーバー2 & 9.62s & 5.3s \\ \hline
 \end{tabular}
 \end{center}
 \end{table}
@@ -214,14 +217,14 @@
 Readは両方とも, 同じような推移の仕方をしているが, Cassandraの方が遅い. しかし, WriteはCassandraの方が断然速く動作している. この実験では, Cassandraの動作を基準に考えたため書き込みのコマンドにREPLACEを使用した. REPLACEは置き換えるようなコマンドである. そのため, INSERTに比べて多少遅くなる. それがこのグラフに出ているのではないかと考えられる. SEDAは複数のスレッドで動作しているためコア数が少ないサーバーでは性能が出にくいことがわかる. 
 \begin{figure}[h]
 \begin{center}
-	\scalebox{0. 33}{\includegraphics{. /fig/serv1_read. pdf}}
+	\scalebox{0.33}{\includegraphics{./fig/serv1_read.pdf}}
 \end{center}
 \caption{サーバー1上でのベンチマーク(Read)}
 \label{fig:bench2-R}
 \end{figure}
 \begin{figure}[h]
 \begin{center}
-	\scalebox{0. 33}{\includegraphics{. /fig/serv1_write. pdf}}
+	\scalebox{0.33}{\includegraphics{./fig/serv1_write.pdf}}
 \end{center}
 \caption{サーバー1上でのベンチマーク(Write)}
 \label{fig:bench2-W}
@@ -234,14 +237,14 @@
 つまり, Cassandraは負荷が高いときにMySQLを超える性能を出すことが出来る. 負荷がかかっても性能の劣化が少ないことを考えると考えると遅延をあまり考慮しなくても済むのではないだろうか. 
 \begin{figure}[h]
 \begin{center}
-	\scalebox{0. 33}{\includegraphics{. /fig/serv2_read. pdf}}
+	\scalebox{0.33}{\includegraphics{./fig/serv2_read.pdf}}
 \end{center}
 \caption{サーバー2上でのベンチマーク(Read)}
 \label{fig:bench3-R}
 \end{figure}
 \begin{figure}[h]
 \begin{center}
-	\scalebox{0. 33}{\includegraphics{. /fig/serv2_write. pdf}}
+	\scalebox{0.33}{\includegraphics{./fig/serv2_write.pdf}}
 \end{center}
 \caption{サーバー2上でのベンチマーク(Write)}
 \label{fig:bench3-W}
@@ -252,28 +255,28 @@
 Read/Writeともに, 今回の場合は分散を行わなかったほうが性能を引き出せてることが分る. これは, 実験に使用したデータがRead/Write共に1つだけで, 結局は同じノードにリクエストが転送されている. そのため, リクエストは1台のノードに集中する. よって, 性能が出ないのではないかと考えられる. Cassandraをただ増やすだけでは性能は得ることが出来ず, データも分散させて実験を行わないといけないことがわかった. 
 \begin{figure}[h]
 \begin{center}
-	\scalebox{0. 33}{\includegraphics{. /fig/cluster_read. pdf}}
+	\scalebox{0.33}{\includegraphics{./fig/cluster_read.pdf}}
 \end{center}
 \caption{サーバー1を複数ノードにしたベンチマーク(Read)}
 \label{fig:bench4-R}
 \end{figure}
 \begin{figure}[h]
 \begin{center}
-	\scalebox{0. 33}{\includegraphics{. /fig/cluster_write. pdf}}
+	\scalebox{0.33}{\includegraphics{./fig/cluster_write.pdf}}
 \end{center}
 \caption{サーバー1を複数ノードにしたベンチマーク(Write)}
 \label{fig:bench4-W}
 \end{figure}
 \newpage
 \section{まとめ}
-今回の実験で, Cassandraを使用するには従来の使用方法ではいけないということがわかった. Cassandraの性能を発揮するにはRead/Writeが多い環境下でコア数の多いサーバーを使用する必要がある. さらに, 単純にCassandraのノード数を増やしても性能は高くならならず, 逆に遅くなることがある. 
- 
-そのため, 格納されるデータもある程度分散させなければならない. 格納されるデータを決めるのにPartitionerというものがあり, 効率よく分散させるためには, アプリケーションが使用するデータの特性に応じてカスタマイズする必要があると考えられる. 
+今回の実験で, Cassandraを使用するには従来の使用方法ではいけないということがわかった. Cassandraはコア数が少ない場合, ReadはMySQLより遅いがほぼ同し推移の仕方をする. Writeは，コア数が少なくてもクライアントの並列度を高く設定すれば，MySQLに勝つことがある．
+コア数が多い場合，Read・Write共に，初めはやはりMySQLの方が動作が早いが，グラフの傾きはMySQLの方が大きくCassandraはかなり緩やかである．特にCassandraのWhiteの性能は高く, MySQLを大きく上回っている．
+また, 単純にCassandraのノード数を増やしても性能は高くならない. これは, データも綺麗に分散させてあげないとデータを読み込む際に一定のノードに集中してしまい，他のノードにアクセスを分散しても結局は保持しているノードに聞きに行かないといけないことになるからである． 
+データもある程度分散させなければならないため，汎用的なHASH関数では性能が発揮できなく, そのアプリケーション専用の関数が必要だと思われる. 
+格納されるデータを決めるのにPartitionerというものがあり, それを利用することで実装できると思われる．
 \section{今後の課題}
 今後は, Partitionerを拡張し複数のデータをノードに分散させた環境下でベンチマークを行い, その結果をCassandra単体でのベンチマーク結果と比較したいと考えている. 他にも, 沖縄東京間などの離れた地域での分散をCassandraでどの様に行なっていくか実験していきたい. 
 
-{\bf 謝辞}\\
-うわあああああああああああああああああああああああああああああああああああああああ
 %
 \begin{adjustvboxheight} % needed only when Appendix follows
 \begin{thebibliography}{99}