Binary file shoshi-paper.pdf has changed

--- a/shoshi-paper.tex	Mon Aug 23 17:34:52 2010 +0900
+++ b/shoshi-paper.tex	Tue Aug 24 15:58:55 2010 +0900
@@ -70,7 +70,8 @@
 \subsection{Yahoo! Cloud Serving Benchmark}
 数のデータベース（Sherpa,BitTable,Azure）などがあるが, 実際にはどのデータベースを使用すればよいか確かではない. この研究では, 異なるデータベースの性能を比較する共通なフレームワークを開発する．\cite{YCSB}
 \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の意味は異なる. 
@@ -120,7 +121,9 @@
 SEDA(Staged Event-Driven Architecture)は, Cassandraで使用されているアーキテクチャである. 処理を複数のステージに分解しタスクキューとスレッドプールを用意し処理を行う. 処理の様子を図\ref{fig:seda}に示す. 
 タスクが各ステージのタスクキューに入ると, スレッドプールにどれかのスレッドがタスクキューの中からタスクを取り出し処理を行う. 処理が終わるとそのタスクを次のステージのタスクキューに入れる. 
 
-このアーキテクチャはマルチスレッドベースなためマルチコアなPCと多数のタスクがある状況で性能を発揮することができる. しかし, あまりにもスレッドプールやタスクが多すぎると, コンテキストに切り替えに時間がかかり性能は低下する. そのため, Cassandraでは最低4コアを搭載した計算機で動作させることを推奨している. 
+このアーキテクチャはマルチスレッドベースなためマルチコアなPCと多数のタスクがある状況で性能を発揮することができる. しかし, あまりにもスレッドプールやタスクが多すぎると, コンテキストに切り替えに時間がかかり性能は低下する. 
+%           ^^^ 何に載っていたか引用する
+
 \begin{figure}[h]
 \begin{center}
 \includegraphics{./fig/SEDA.pdf}
@@ -274,15 +277,18 @@
 \newpage
 \section{まとめ}
 Cassandraは従来の使用方法では性能を発揮することが出来ずコア数が多いサーバーでクライアントの並列度が高い場合に性能を発揮する. 
-これは，ベンチマークの結果を考察すると，コア数が少ない場合ReadはMySQLより遅いがほぼ同し推移の仕方をする. Writeは，コア数が少なくてもクライアントの並列度を高く設定すればMySQLより性能が出る．
-コア数が多い場合，Read・Write共に，初めはやはりMySQLの方が動作が早いが，グラフの傾きはMySQLの方が大きくCassandraは緩やかである．特にCassandraのWhiteの性能は高く, MySQLを大きく上回っている．
+これは，ベンチマークの結果を考察すると，コア数が少ない場合ReadはMySQLより遅いがほぼ同し推移の仕方をする. 
+Writeは，コア数が少なくてもクライアントの並列度を高く設定すればMySQLより性能が出る．
+コア数が多い場合，Read・Write共に，初めはやはりMySQLの方が動作が早いが，グラフの傾きはMySQLの方が大きくCassandraは緩やかである．
+特にCassandraのWhiteの性能は高く, MySQLを大きく上回っている．
 また, 単純にCassandraのノード数を増やしても性能は高くならない. これは, データも綺麗に分散させてあげないとデータを読み込む際に一定のノードに集中してしまい，他のノードにアクセスを分散しても結局は保持しているノードに聞きに行かないといけないことになるからである． 
 データもある程度分散させなければならないため，汎用的なhash関数では性能が発揮できなく, そのアプリケーション専用の関数が必要だと思われる. 
 格納されるデータを決めるのにStrategyというものがあり, それを利用することで実装できると思われる．
 \section{今後の課題}
 今後は, Strategyを拡張し複数のデータをノードに分散させた環境下でベンチマークを行い, その結果をCassandra単体でのベンチマーク結果と比較したいと考えている.
 
-%
+% 本文で引用しない限り、参考文献には挙げないものなんだよ
+
 \begin{adjustvboxheight} % needed only when Appendix follows
 \begin{thebibliography}{99}
 \bibitem{YCSB} Benchmarking Cloud Serving Systems with YCSB