Mercurial > hg > Papers > 2010 > jsst-shoshi

changeset 1:5d53f54e7152

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
minor fix
author Shinji KONO <kono@ie.u-ryukyu.ac.jp>
date Tue, 17 Aug 2010 16:47:50 +0900
parents 3537d0ffdf6f
children 67b20ecbb946
files Makefile shoshi-paper.dvi shoshi-paper.log shoshi-paper.pdf shoshi-paper.tex
diffstat 5 files changed, 143 insertions(+), 104 deletions(-) [+]
line wrap: on
line diff
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/Makefile	Tue Aug 17 16:47:50 2010 +0900
@@ -0,0 +1,24 @@
+FILE=shoshi-paper
+
+platex:
+	platex ${FILE}.tex
+	platex ${FILE}.tex
+
+pdf: platex
+	dvipdfmx ${FILE}.dvi
+	open ${FILE}.pdf
+
+repdf: platex
+	pkill Preview
+	dvipdfmx ${FILE}.dvi
+	open ${FILE}.pdf
+	
+xdvi: platex
+	xdvi ${FILE}.dvi
+
+.PHONY:clean
+clean:
+	rm -f ${FILE}.log ${FILE}.aux ${FILE}.dvi
+
+remove:
+	rm -rf ${FILE}.log ${FILE}.aux ${FILE}.toc ${FILE}.dvi ${FILE}.dvi *.PNG *.eps *.bb *.png *.pdf *.graffle *.key *.dat img/*
Binary file shoshi-paper.dvi has changed
--- a/shoshi-paper.log	Tue Aug 10 18:08:07 2010 +0900
+++ b/shoshi-paper.log	Tue Aug 17 16:47:50 2010 +0900
@@ -1,5 +1,5 @@
-This is pTeX, Version 3.141592-p3.1.10 (utf8.euc) (Web2C 7.5.4) (format=platex 2009.9.19)  10 AUG 2010 16:31
-**./shoshi-paper.tex
+This is pTeX, Version 3.141592-p3.1.10 (utf8.euc) (Web2C 7.5.4) (format=platex 2009.10.12)  17 AUG 2010 16:33
+**shoshi-paper.tex
 (./shoshi-paper.tex
 pLaTeX2e <2006/11/10>+0 (based on LaTeX2e <2003/12/01> patch level 0)
 (./compsoft.cls
@@ -55,25 +55,25 @@
 \currentKai=\count98
  (./mediabb.sty
 Package: mediabb 2006/10/26 v1.9 iNOUE Koich! <inoue@ma.ns.musashi-tech.ac.jp>
- (/opt/local/share/texmf-dist/tex/latex/graphics/graphicx.sty
+ (/usr/local/share/texmf-dist/tex/latex/graphics/graphicx.sty
 Package: graphicx 1999/02/16 v1.0f Enhanced LaTeX Graphics (DPC,SPQR)
 
-(/opt/local/share/texmf-dist/tex/latex/graphics/keyval.sty
+(/usr/local/share/texmf-dist/tex/latex/graphics/keyval.sty
 Package: keyval 1999/03/16 v1.13 key=value parser (DPC)
 \KV@toks@=\toks15
 )
-(/opt/local/share/texmf/tex/latex/graphics/dvipdfmx-contrib-latex/graphics.sty
+(/usr/local/share/texmf/tex/latex/graphics/dvipdfmx-contrib-latex/graphics.sty
 Package: graphics 2001/07/07 v1.0n Standard LaTeX Graphics (DPC,SPQR)
 
-(/opt/local/share/texmf-dist/tex/latex/graphics/trig.sty
+(/usr/local/share/texmf-dist/tex/latex/graphics/trig.sty
 Package: trig 1999/03/16 v1.09 sin cos tan (DPC)
 )
-(/opt/local/share/texmf-dist/tex/latex/graphics/graphics.cfg
+(/usr/local/share/texmf-dist/tex/latex/graphics/graphics.cfg
 File: graphics.cfg 2005/02/03 v1.3 graphics configuration of teTeX/TeXLive
 )
 Package graphics Info: Driver file: dvipdfm.def on input line 81.
 
-(/opt/local/share/texmf-dist/tex/latex/dvipdfm/dvipdfm.def
+(/usr/local/share/texmf-dist/tex/latex/dvipdfm/dvipdfm.def
 File: dvipdfm.def 1999/9/6 vx.x Driver-dependant file
 ))
 \Gin@req@height=\dimen135
@@ -180,12 +180,12 @@
 
  ) 
 Here is how much of TeX's memory you used:
- 809 strings out of 94682
- 9475 string characters out of 1177971
- 71058 words of memory out of 1500000
- 4127 multiletter control sequences out of 10000+50000
+ 809 strings out of 95541
+ 9473 string characters out of 1187747
+ 69189 words of memory out of 1500000
+ 3988 multiletter control sequences out of 10000+50000
  18606 words of font info for 72 fonts, out of 1200000 for 2000
- 566 hyphenation exceptions out of 8191
- 32i,9n,36p,1331b,664s stack positions out of 5000i,500n,6000p,200000b,5000s
+ 14 hyphenation exceptions out of 8191
+ 32i,9n,36p,1329b,663s stack positions out of 5000i,500n,6000p,200000b,5000s
 
 Output written on shoshi-paper.dvi (6 pages, 31464 bytes).
Binary file shoshi-paper.pdf has changed
--- a/shoshi-paper.tex	Tue Aug 10 18:08:07 2010 +0900
+++ b/shoshi-paper.tex	Tue Aug 17 16:47:50 2010 +0900
@@ -1,30 +1,30 @@
-% Sample file for the use of compsoft style file.
+% Sample file for the use of compsoft style file. 
 %
 \documentclass[T]{compsoft}
 
 % Preamble
 %
-% 「コンピュータソフトウェア」誌に掲載される論文の場合，次で
-% 巻数，号数，開始ページ，終了ページを指定する．
+% 「コンピュータソフトウェア」誌に掲載される論文の場合, 次で
+% 巻数, 号数, 開始ページ, 終了ページを指定する. 
 %\volNoPp{16}{5}{78}{83}
 
-% ワークショップによる推薦論文の場合，ワークショップ名を指定する．
+% ワークショップによる推薦論文の場合, ワークショップ名を指定する. 
 % \suisen{ワークショップ名}
 
-% 特集の場合，特集のタイトルを与える．
+% 特集の場合, 特集のタイトルを与える. 
 % \tokushu{特集のタイトル}
 
-% 大会論文の場合，\taikai で開催年を指定する．ここで指定した年から
-% 大会の回数は計算される．
+% 大会論文の場合, \taikai で開催年を指定する. ここで指定した年から
+% 大会の回数は計算される. 
 \taikai{2010}
 
-%pdf ここに，使用するパッケージを列挙する．
+%pdf ここに, 使用するパッケージを列挙する. 
 \usepackage{mediabb}
 \usepackage{graphicx}
 %\usepackage[dvips]{graphics}
 
-% ユーザが定義したマクロなどはここに置く．ただし学会誌のスタイルの
-% 再定義は原則として避けること．
+% ユーザが定義したマクロなどはここに置く. ただし学会誌のスタイルの
+% 再定義は原則として避けること. 
 
 \begin{document}
 
@@ -32,93 +32,101 @@
 \title{Cassandraを使ったアプリケーションのPCクラスタを使ったスケーラビリティの検証}
 
 % 著者
-% 和文論文の場合，姓と名の間には半角スペースを入れ，
+% 和文論文の場合, 姓と名の間には半角スペースを入れ, 
 % 複数の著者の間は全角スペースで区切る
 %
-\author{玉城 将士
+\author{玉城 将士 \and 河野 真治
 }
 
 %
 % 和文アブストラクト
 \Jabstract{%
-現在，数ある分散Key-Valueストアの中でもCassandraが注目を集めている．
+現在, 数ある分散Key-Valueストアの中でもCassandraが注目を集めている. 
 CassandraはConsitency levelの変更が可能であり、スケーラビリテイを
-高めるための使い方には工夫が必要である。
-本研究では，Cassandra上で動作するCMSを開発し学科のクラスタ上で動作させ
-る．そしてその環境上でスケーラビリティを確認する実験手法に関して
-考察する。
+高めるための使い方には工夫が必要である. 
+本研究では, Cassandra上で動作するCMSを実装し学科のクラスタ上で動作させ
+る. 
+特に, CoreDuo などの安価だが非力なマシンの振舞を調べることを行なった. 
+そしてその環境上でスケーラビリティを確認する実験手法に関して考察する. 
+
 }
 %
-% 英文アブストラクト（大会論文には必要なし)
+% 英文アブストラクト(大会論文には必要なし)
 % \Eabstract{}
+\shozoku{Shoshi TAMAKI, Shinji KONO}{琉球大学工学部情報工学学科}%
+{Dept. \ of Information Engineering, Ryukyu University}
+
 %
 \maketitle
 
 \section{はじめに}
-近年インターネットやスマートフォンなどの普及に伴い，インターネット上のサービスを使用するユーザーが急速に増え続けている．サービスを利用するユーザーが増えると，いままでのシステムでは膨大なアクセスに対応できなくなり，サービスの品質を維持することができなる．
-品質を維持するためには，使用するサーバー性能の向上を測ればよい．しかし，性能の良いサーバーを揃えるには膨大なコストを必要とし，これをスケールアップと呼ぶ．
-そこで，安価なサーバーを複数用意し，連携させることによって性能を向上させる方法があり，これをスケールアウトと呼ぶ．この方法では，従来使用してきたソフトウェアを複数のサーバーに移動するだけではうまく動作しない．
-複数のサーバーを強調させるのは難しく，データの整合性や通信速度，負荷分散など様々な考慮をしなければならないためである．
-Cassandraは複数のサーバーで動作を想定した分散データベースである．
-本研究では，実際に分散させることによって高価なサーバーを超えることが出来る性能を出すことが出来るのか，また，どの様にCassandra上で動くソフトウェアを開発することによって性能を発揮することが出来るのかを，９０台のPCクラスタ上でベンチマークを取り検証する．
+近年インターネットやスマートフォンなどの普及に伴い, インターネット上のサービスを使用するユーザーが急速に増え続けている. サービスを利用するユーザーが増えると, いままでのシステムでは膨大なアクセスに対応できなくなり, サービスの品質を維持することができなる. 
+品質を維持するためには, 使用するサーバー性能の向上を測ればよい. しかし, 性能の良いサーバーを揃えるには膨大なコストを必要とし, これをスケールアップと呼ぶ. 
+そこで, 安価なサーバーを複数用意し, 連携させることによって性能を向上させる方法があり, これをスケールアウトと呼ぶ. この方法では, 従来使用してきたソフトウェアを複数のサーバーに移動するだけではうまく動作しない. 
+複数のサーバーを強調させるのは難しく, データの整合性や通信速度, 負荷分散など様々な考慮をしなければならないためである. 
+Cassandraは複数のサーバーで動作を想定した分散データベースである. 
+本研究では, 実際に分散させることによって高価なサーバーを超えることが出来る性能を出すことが出来るのか, また, どの様にCassandra上で動くソフトウェアを開発することによって性能を発揮することが出来るのかを, 90台のPCクラスタ上でベンチマークを取り検証する. 
 \section{分散データベース Cassandra}
-Cassandraは，FaceBookが自社のために開発した分散Key-Valueストアデータベースである．2008年にオープンソースとして公開され，2009年にApache Incubatorのプロジェクトとなった．2010年にはApacheのトップレベルプロジェクトとなり，現在でも頻繁にバージョンアップが行われている．
+Cassandraは, FaceBookが自社のために開発した分散Key-Valueストアデータベースである. 2008年にオープンソースとして公開され, 2009年にApache Incubatorのプロジェクトとなった. 2010年にはApacheのトップレベルプロジェクトとなり, 現在でも頻繁にバージョンアップが行われている. 
 \subsection{ConsictencyLevel}
-Cassandraには，ConsistencyLevelが用意されている．これは，整合性と応答速度どちらを取るか選ぶためのパラメータであり，リクエストごとに設定することが出来る．
-また，ReadとWriteでConsistencyLevelの意味は異なる．
-このConsistencyLevelを適用するノードの台数をReplicationFactorといい，Cassandraの設定ファイルで設定することが出来る．\\
+Cassandraには, ConsistencyLevelが用意されている. これは, 整合性と応答速度どちらを取るか選ぶためのパラメータであり, リクエストごとに設定することが出来る. 
+また, ReadとWriteでConsistencyLevelの意味は異なる. 
+このConsistencyLevelを適用するノードの台数をReplicationFactorといい, Cassandraの設定ファイルで設定することが出来る. 
+
 {\gt Read}
 \begin{enumerate}
 \item{ConsistencyLevel::ZERO}\\
-サポートされていない．
+サポートされていない. 
 \item{ConsistencyLevel::ANY}\\
-サポートされていない．
+サポートされていない. 
 \item{ConsistencyLevel::ONE}\\
-一番最初に返答したノードの値を返すが値が最新のものであるかは保証できない．整合性の調査は常に非同期で行われており，再度読み出しを行うときに結果が変わっている可能性がある．
+一番最初に返答したノードの値を返すが値が最新のものであるかは保証できない. 整合性の調査は常に非同期で行われており, 再度読み出しを行うときに結果が変わっている可能性がある. 
 \item{ConsistencyLevel::QUORUM}\\
-すべてのノードにリクエストを送信し，取得した値のタイムスタンプを比較し，最も多数のノードが返した値のうちで最新のタイムスタンプを持つ値を返す．
+すべてのノードにリクエストを送信し, 取得した値のタイムスタンプを比較し, 最も多数のノードが返した値のうちで最新のタイムスタンプを持つ値を返す. 
 \item{ConsistencyLevel::ALL}\\
-すべてのノードにリクエストを送信し，もっともタイムスタンプの新しいノードの値を返す．
+すべてのノードにリクエストを送信し, もっともタイムスタンプの新しいノードの値を返す. 
 \end{enumerate}
 {\gt Write}
 \begin{enumerate}
 \item{ConsistencyLevel::ZERO}\\
-何も保証しない，書き込みは非同期的に行われる．
+何も保証しない, 書き込みは非同期的に行われる. 
 \item{ConsistencyLevel::ANY}\\
-別のどこか他のノードに書き込まれることを保証する．
+別のどこか他のノードに書き込まれることを保証する. 
 \item{ConsistencyLevel::ONE}\\
-最低１つのノードのログとメモリテーブルに書き込まれていることを保証する．
+最低1つのノードのログとメモリテーブルに書き込まれていることを保証する. 
 \item{ConsistencyLevel::QUORUM}\\
-(ReplicationFactor/2) + 1のノードに書き込むことに書き込みを終えてからクライアントにレスポンスを返す．
+(ReplicationFactor/2) + 1のノードに書き込むことに書き込みを終えてからクライアントにレスポンスを返す. 
 \item{ConsistencyLevel::ALL}\\
-ReplicationFactorのノード数に書き込みを終えてからレスポンスを返す．
+ReplicationFactorのノード数に書き込みを終えてからレスポンスを返す. 
 \end{enumerate}
 \subsection{コンシステント・ハッシュ}
-Cassandraは複数のノードにデータを分散して格納する．その為に使用されているのがコンシステント・ハッシュである．普通，n台で構成されたノードにデータを分散する場合，HASH(key) mod nで分散させる．この場合だと，ノードが追加・削除された場合すべてのデータの位置を再計算する必要があり面倒である．\\
-そこで，図\ref{fig:chash}のようなものを考える．図\ref{fig:chash}はハッシュ関数が取りうる値を範囲としたリングである．このリング上に構成するノードを配置していく．この図の場合，アルファベットがノードで数字がデータ，矢印が担当するノードである．
-次に，ハッシュ関数により計算された値をリングの上に配置する．このとき，リングを右回りに周り一番最初にあたったノードがデータを担当するノードとする．
-こうすると，ノードが追加・削除された場合に，全体を再計算する必要はなく，担当するノードがいなくなったデータのみを再計算し，次の担当するノードに移せばよい．
-Cassandraでは，右回りに回ったとき担当するノード数を複数にする場合，ReplicationFactorで調整することが出来る．
+Cassandraは複数のノードにデータを分散して格納する. その為に使用されているのがコンシステント・ハッシュである. 普通, n台で構成されたノードにデータを分散する場合, HASH(key) mod nで分散させる. この場合だと, ノードが追加・削除された場合すべてのデータの位置を再計算する必要があり面倒である. 
+
+そこで, 図\ref{fig:chash}のようなものを考える. 図\ref{fig:chash}はハッシュ関数が取りうる値を範囲としたリングである. このリング上に構成するノードを配置していく. この図の場合, アルファベットがノードで数字がデータ, 矢印が担当するノードである. 
+次に, ハッシュ関数により計算された値をリングの上に配置する. このとき, リングを右回りに周り一番最初にあたったノードがデータを担当するノードとする. 
+こうすると, ノードが追加・削除された場合に, 全体を再計算する必要はなく, 担当するノードがいなくなったデータのみを再計算し, 次の担当するノードに移せばよい. 
+Cassandraでは, 右回りに回ったとき担当するノード数を複数にする場合, ReplicationFactorで調整することが出来る. 
 \begin{figure}[h]
 \begin{center}
-\includegraphics{./fig/ConsistentHash.pdf}
+\includegraphics{. /fig/ConsistentHash. pdf}
 \end{center}
 \caption{コンシステントハッシュ}
 \label{fig:chash}
 \end{figure}
 \subsection{SEDA}
-SEDA(Staged Event-Driven Architecture)は，Cassandraで使用されているアーキテクチャである．処理を複数のステージに分解しタスクキューとスレッドプールを用意し処理を行う．処理の様子を図\ref{fig:seda}に示す．
-タスクが各ステージのタスクキューに入ると，スレッドプールにどれかのスレッドがタスクキューの中からタスクを取り出し処理を行う．処理が終わるとそのタスクを次のステージのタスクキューに入れる．\\
-このアーキテクチャはマルチスレッドベースなためマルチコアなPCと多数のタスクがある状況で性能を発揮することができる．しかし，あまりにもスレッドプールやタスクが多すぎると，コンテキストに切り替えに時間がかかり性能は低下する．そのため，Cassandraでは最低４コアを搭載した計算機で動作させることを推奨している．
+SEDA(Staged Event-Driven Architecture)は, Cassandraで使用されているアーキテクチャである. 処理を複数のステージに分解しタスクキューとスレッドプールを用意し処理を行う. 処理の様子を図\ref{fig:seda}に示す. 
+タスクが各ステージのタスクキューに入ると, スレッドプールにどれかのスレッドがタスクキューの中からタスクを取り出し処理を行う. 処理が終わるとそのタスクを次のステージのタスクキューに入れる. 
+
+このアーキテクチャはマルチスレッドベースなためマルチコアなPCと多数のタスクがある状況で性能を発揮することができる. しかし, あまりにもスレッドプールやタスクが多すぎると, コンテキストに切り替えに時間がかかり性能は低下する. そのため, Cassandraでは最低4コアを搭載した計算機で動作させることを推奨している. 
 \begin{figure}[h]
 \begin{center}
-\includegraphics{./fig/SEDA.pdf}
+\includegraphics{. /fig/SEDA. pdf}
 \end{center}
 \caption{SEDA}
 \label{fig:seda}
 \end{figure}
 \subsection{Cassandra上でのステージの構成}
-Cassandraは主に以下のステージにより構成されており，concurrent.StageManagerを参照すると見つけることが出来る．
+Cassandraは主に以下のステージにより構成されており, concurrent. StageManagerを参照すると見つけることが出来る. 
 \begin{itemize}
 \item{READ STAGE}
 \item{MUTATION STAGE}
@@ -129,38 +137,38 @@
 \item{LOADBALANCE STAGE}
 \item{MIGRATION STAGE}\\
 \end{itemize}
-実際にはもっと多数のステージが存在し，この他にもクライアントの接続を待つスレッドプールやMemTableのFlushを行うスレッドプールがあり，全部で４０個程度のスレッドが動作している．
+実際にはもっと多数のステージが存在し, この他にもクライアントの接続を待つスレッドプールやMemTableのFlushを行うスレッドプールがあり, 全部で40個程度のスレッドが動作している. 
 \section{実験}
-本研究では，Cassandraのスケーラビリティの検証の為にベンチマークテストを行う．実験環境は以下のとおりである．
+本研究では, Cassandraのスケーラビリティの検証の為にベンチマークテストを行う. 実験環境は以下のとおりである. 
 \subsection{実験環境}
 \begin{enumerate}
-\item{クラスタ（クライアント）}
+\item{クラスタ(クライアント)}
 \begin{itemize}
 \item{CPU : Core Duo}
 \item{Mem : 1GB}
 \item{O S : CentOS 5}
 \end{itemize}
-\item{実験用サーバー１( MacMini )}
+\item{実験用サーバー1( MacMini )}
 \begin{itemize}
 \item{CPU : Core2 Duo}
 \item{Mem : 4GB}
 \item{O S : OSX SnowLeopard}
 \end{itemize}
-\item{実験用サーバー２}
+\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}
 \end{enumerate}
 \subsection{実験方法}
 \begin{enumerate}
-\item{クライアント}\\
-クラスタ管理ツールのTorqueを使用し，使用するノード数を指定してクラスタにジョブを投げてPHPスクリプトを実行させる．このPHPスクリプトはCassandraとMySQLに10000回リクエストを送信するスクリプトである．
-\item{Cassandra}\\
-Cassandra 0.6.3を使用した．
-\item{MySQL}\\
-MySQL 5.5を使用した．Cassandraと似たデータ構造を持たせるために表\ref{tab:mysql_tbl_def}のような構造でテーブルを作成した．
+\item{クライアント}
+クラスタ管理ツールのTorqueを使用し, 使用するノード数を指定してクラスタにジョブを投げてPHPスクリプトを実行させる. このPHPスクリプトはCassandraとMySQLに10000回リクエストを送信するスクリプトである. 
+\item{Cassandra}
+Cassandra 0. 6. 3を使用した. 
+\item{MySQL}
+MySQL 5. 5を使用した. Cassandraと似たデータ構造を持たせるために表\ref{tab:mysql_tbl_def}のような構造でテーブルを作成した. 
 \begin{table}[h]
 \caption{テーブルの定義}
 \label{tab:mysql_tbl_def}
@@ -177,15 +185,16 @@
 \newpage
 \section{実験結果と考察}
 \subsection{単純なベンチマーク}
-はじめに，単純なベンチマークを行った．単体のクライアントとサーバーを用意し，CassandraとMySQLの実行時間の比較を行った．結果を表\ref{tab:bench1}に示す．この時のCassandraのConsistencyLevelはONEである．\\
-結果を見てみると，MySQLよりCassandraのほうが高速に動作していることが分かる．MyySQLはC++で記述されているがCassandraはJavaであるため，動作が遅い．よって，単純な使用方法ではCassandraよりMySQLの方が優れていると言える，普通の方法ではCassandraの性能を引き出すことは出来ない．
+はじめに, 単純なベンチマークを行った. 単体のクライアントとサーバーを用意し, CassandraとMySQLの実行時間の比較を行った. 結果を表\ref{tab:bench1}に示す. この時のCassandraのConsistencyLevelはONEである. 
+
+結果を見てみると, MySQLよりCassandraのほうが高速に動作していることが分かる. MyySQLはC++で記述されているがCassandraはJavaであるため, 動作が遅い. よって, 単純な使用方法ではCassandraよりMySQLの方が優れていると言える, 普通の方法ではCassandraの性能を引き出すことは出来ない. 
 \begin{table}[h]
 \caption{単純なベンチマークの結果(Read)}
 \begin{center}
 \begin{tabular}{|c|c|c|}  \hline
 & Cassandra & MySQL \\ \hline
-サーバー１ & 13.72s & 5.94s \\ \hline
-サーバー２ & 12.56s & 3.99s \\ \hline
+サーバー1 & 13. 72s & 5. 94s \\ \hline
+サーバー2 & 12. 56s & 3. 99s \\ \hline
 \end{tabular}
 \end{center}
 \vspace{5mm}
@@ -193,70 +202,76 @@
 \begin{center}
 \begin{tabular}{|c|c|c|} \hline
 & Cassandra & MySQL \\ \hline
-サーバー１ & 11.75s & 5.7s \\ \hline
-サーバー２ & 9.62s & 5.3s \\ \hline
+サーバー1 & 11. 75s & 5. 7s \\ \hline
+サーバー2 & 9. 62s & 5. 3s \\ \hline
 \end{tabular}
 \end{center}
 \end{table}
 \subsection{コア数の少ないサーバー上でのベンチマーク}
-次に，クライアントを並列化しての実験を行う．ここでは，コア数の少ないサーバー１を用いる．クライアントの並列化はスクリプトを指定した時間に同時起動するようにして実装した．\\
-実験結果を図\ref{fig:bench2-R}と図\ref{fig:bench2-W}に示す．\\
-Readは両方とも，同じような推移の仕方をしているが，Cassandraの方が遅い．しかし，WriteはCassandraの方が断然速く動作している．この実験では，Cassandraの動作を基準に考えたため書き込みのコマンドにREPLACEを使用した．REPLACEは置き換えるようなコマンドである．そのため，INSERTに比べて多少遅くなる．それがこのグラフに出ているのではないかと考えられる．SEDAは複数のスレッドで動作しているためコア数が少ないサーバーでは性能が出にくいことがわかる．
+次に, クライアントを並列化しての実験を行う. ここでは, コア数の少ないサーバー1を用いる. クライアントの並列化はスクリプトを指定した時間に同時起動するようにして実装した. 
+実験結果を図\ref{fig:bench2-R}と図\ref{fig:bench2-W}に示す. 
+
+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{サーバー１上でのベンチマーク(Read)}
+\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{サーバー１上でのベンチマーク(Write)}
+\caption{サーバー1上でのベンチマーク(Write)}
 \label{fig:bench2-W}
 \end{figure}
 \subsection{コア数の多いサーバー上でのベンチマーク}
-クライアントを並列化した状態で，コア数の多いサーバー２を用いたベンチマークを行う．実験結果を図\ref{fig:bench3-R}と図\ref{fig:bench3-W}に示す．\\
-Read/Write共にMySQLの性能を超えることに成功した．Readにおいてはコア数が少ない場合に超えることが出来なかったが，並列度が７０度付近でMySQLを超えることが出来ている．Cassandraの平均時間は並列度がましても，MySQLよりは平均時間の増加度が少ない．これは，SEDAの特徴である，多くのタスクを並列に実行すると性能がでるという部分が確認することが出来た．また，SEDAはマルチスレッド前提であるため，コア数が少ないサーバー１では性能が出ず，コア数の多いサーバー２で性能が発揮できるということがわかった．\\
-つまり，Cassandraは負荷が高いときにMySQLを超える性能を出すことが出来る．負荷がかかっても性能の劣化が少ないことを考えると考えると遅延をあまり考慮しなくても済むのではないだろうか．
+クライアントを並列化した状態で, コア数の多いサーバー2を用いたベンチマークを行う. 実験結果を図\ref{fig:bench3-R}と図\ref{fig:bench3-W}に示す. 
+
+Read/Write共にMySQLの性能を超えることに成功した. Readにおいてはコア数が少ない場合に超えることが出来なかったが, 並列度が70度付近でMySQLを超えることが出来ている. Cassandraの平均時間は並列度がましても, MySQLよりは平均時間の増加度が少ない. これは, SEDAの特徴である, 多くのタスクを並列に実行すると性能がでるという部分が確認することが出来た. また, SEDAはマルチスレッド前提であるため, コア数が少ないサーバー1では性能が出ず, コア数の多いサーバー2で性能が発揮できるということがわかった. 
+
+つまり, 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{サーバー２上でのベンチマーク(Read)}
+\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{サーバー２上でのベンチマーク(Write)}
+\caption{サーバー2上でのベンチマーク(Write)}
 \label{fig:bench3-W}
 \end{figure}
 \subsection{複数ノードで構成したCassadraのベンチマーク}
-最後に分散しなかったCassandraと複数ノードで構成したCassandraの比較を行う．サーバーはサーバー１を５台使用して行った．実験結果を図\ref{fig:bench4-R}と図\ref{fig:bench4-W}に示す．\\
-Read/Writeともに，今回の場合は分散を行わなかったほうが性能を引き出せてることが分る．これは，実験に使用したデータがRead/Write共に１つだけで，結局は同じノードにリクエストが転送されている．そのため，リクエストは１台のノードに集中する．よって，性能が出ないのではないかと考えられる．Cassandraをただ増やすだけでは性能は得ることが出来ず，データも分散させて実験を行わないといけないことがわかった．
+最後に分散しなかったCassandraと複数ノードで構成したCassandraの比較を行う. サーバーはサーバー1を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}}
+	\scalebox{0. 33}{\includegraphics{. /fig/cluster_read. pdf}}
 \end{center}
-\caption{サーバー１を複数ノードにしたベンチマーク(Read)}
+\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{サーバー１を複数ノードにしたベンチマーク(Write)}
+\caption{サーバー1を複数ノードにしたベンチマーク(Write)}
 \label{fig:bench4-W}
 \end{figure}
 \newpage
 \section{まとめ}
-今回の実験で，Cassandraを使用するには従来の使用方法ではいけないということがわかった．Cassandraの性能を発揮するにはRead/Writeが多い環境下でコア数の多いサーバーを使用する必要がある．さらに，単純にCassandraのノード数を増やしても性能は高くならならず，逆に遅くなることがある．\\
-そのため，格納されるデータもある程度分散させなければならない．格納されるデータを決めるのにPartitionerというものがあり，効率よく分散させるためには，アプリケーションが使用するデータの特性に応じてカスタマイズする必要があると考えられる．
+今回の実験で, Cassandraを使用するには従来の使用方法ではいけないということがわかった. Cassandraの性能を発揮するにはRead/Writeが多い環境下でコア数の多いサーバーを使用する必要がある. さらに, 単純にCassandraのノード数を増やしても性能は高くならならず, 逆に遅くなることがある. 
+ 
+そのため, 格納されるデータもある程度分散させなければならない. 格納されるデータを決めるのにPartitionerというものがあり, 効率よく分散させるためには, アプリケーションが使用するデータの特性に応じてカスタマイズする必要があると考えられる. 
 \section{今後の課題}
-今後は，Partitionerを拡張し複数のデータをノードに分散させた環境下でベンチマークを行い，その結果をCassandra単体でのベンチマーク結果と比較したいと考えている．他にも，沖縄東京間などの離れた地域での分散をCassandraでどの様に行なっていくか実験していきたい．\\
+今後は, Partitionerを拡張し複数のデータをノードに分散させた環境下でベンチマークを行い, その結果をCassandra単体でのベンチマーク結果と比較したいと考えている. 他にも, 沖縄東京間などの離れた地域での分散をCassandraでどの様に行なっていくか実験していきたい. 
+
 {\bf 謝辞}\\
 うわあああああああああああああああああああああああああああああああああああああああ
 %