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 16:29:25 2010 +0900
@@ -117,7 +117,10 @@
 SEDA(Staged Event-Driven Architecture)は, Cassandraで使用されているアーキテクチャである. 処理を複数のステージに分解しタスクキューとスレッドプールを用意し処理を行う. 処理の様子を図\ref{fig:seda}に示す. 
 タスクが各ステージのタスクキューに入ると, スレッドプールにどれかのスレッドがタスクキューの中からタスクを取り出し処理を行う. 処理が終わるとそのタスクを次のステージのタスクキューに入れる. 
 
-このアーキテクチャはマルチスレッドベースなためマルチコアなPCと多数のタスクがある状況で性能を発揮することができる. しかし, あまりにもスレッドプールやタスクが多すぎると, コンテキストに切り替えに時間がかかり性能は低下する. そのため, Cassandraでは最低4コアを搭載した計算機で動作させることを推奨している. 
+このアーキテクチャはマルチスレッドベースなためマルチコアなPCと多数のタスクがある状況で性能を発揮することができる. しかし, あまりにもスレッドプールやタスクが多すぎると, コンテキストに切り替えに時間がかかり性能は低下する. 
+そのため, Cassandraでは最低4コアを搭載した計算機で動作させることを推奨している. 
+%           ^^^ 何に載っていたか引用する
+
 \begin{figure}[h]
 \begin{center}
 \includegraphics{./fig/SEDA.pdf}
@@ -250,7 +253,9 @@
 \label{fig:bench3-W}
 \end{figure}
 \subsection{複数ノードで構成したCassadraのベンチマーク}
-最後に分散しなかったCassandraと複数ノードで構成したCassandraの比較を行う. サーバーはサーバー1を5台使用して行った. 実験結果を図\ref{fig:bench4-R}と図\ref{fig:bench4-W}に示す. 
+最後に分散しなかったCassandraと複数ノードで構成したCassandraの比較を行う. 
+%     ^^^^^ 意味不明
+サーバーはサーバー1を5台使用して行った. 実験結果を図\ref{fig:bench4-R}と図\ref{fig:bench4-W}に示す. 
 
 Read/Writeともに, 今回の場合は分散を行わなかったほうが性能を引き出せてることが分る. これは, 実験に使用したデータがRead/Write共に1つだけで, 結局は同じノードにリクエストが転送されている. そのため, リクエストは1台のノードに集中する. よって, 性能が出ないのではないかと考えられる. Cassandraをただ増やすだけでは性能は得ることが出来ず, データも分散させて実験を行わないといけないことがわかった. 
 \begin{figure}[h]
@@ -269,7 +274,13 @@
 \end{figure}
 \newpage
 \section{まとめ}
-今回の実験で, Cassandraを使用するには従来の使用方法ではいけないということがわかった. Cassandraはコア数が少ない場合, ReadはMySQLより遅いがほぼ同し推移の仕方をする. Writeは，コア数が少なくてもクライアントの並列度を高く設定すれば，MySQLに勝つことがある．
+%  もっと細かく改行して。でないと、コメントを入れづらい
+
+今回の実験で, Cassandraを使用するには従来の使用方法ではいけないということがわかった. 
+%                                   ^^^^^ 明確に書く   ^^^^^^ これは論文的じゃない
+Cassandraはコア数が少ない場合, ReadはMySQLより遅いがほぼ同し推移の仕方をする. Writeは，コア数が少なくてもクライアントの並列度を高く設定すれば，MySQLに勝つことがある．
+%   勝つとか負けるとかは論文では使わない
+
 コア数が多い場合，Read・Write共に，初めはやはりMySQLの方が動作が早いが，グラフの傾きはMySQLの方が大きくCassandraはかなり緩やかである．特にCassandraのWhiteの性能は高く, MySQLを大きく上回っている．
 また, 単純にCassandraのノード数を増やしても性能は高くならない. これは, データも綺麗に分散させてあげないとデータを読み込む際に一定のノードに集中してしまい，他のノードにアクセスを分散しても結局は保持しているノードに聞きに行かないといけないことになるからである． 
 データもある程度分散させなければならないため，汎用的なHASH関数では性能が発揮できなく, そのアプリケーション専用の関数が必要だと思われる. 
@@ -277,13 +288,14 @@
 \section{今後の課題}
 今後は, Partitionerを拡張し複数のデータをノードに分散させた環境下でベンチマークを行い, その結果をCassandra単体でのベンチマーク結果と比較したいと考えている. 他にも, 沖縄東京間などの離れた地域での分散を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{LS86-1} Benchmarking Cloud Serving Systems with YCSB
+\bibitem{LS86-2} The Staged Event-Driven Architecture for Highly-Concurrent Server Applications
+\bibitem{LS86-3} SEDA : An Architecture for Well-Conditioned , Scalable Internet Services
+\bibitem{LS86-4} Bigtable : A Distributed Storege System for Structured Data
 \end{thebibliography}
 \end{adjustvboxheight} % needed only when Appendix follows
 \end{document}