ベンチマークの単位
ベンチマーク試験って色々ありますね。
性能?スループット?果たして何が良ければいいのか。
単位もたくさんありますね...。
そもそも何向け?CPU?ディスクI/O?
スループット(Throughput):単位時間当たりの処理能力
MB/s(Mega Byte Per Second):バイト。ネットワーク性能など。
IOPS(I/O Per Second):IO回数。ディスク性能など。
OPS(Object Per Second):オブジェクト。この前どこかで見た...。
FLOPS(Floating-point Operations Per Second):浮動小数点演算。スパコン、GPUなど
MIPS(Million Instructions Per Second):命令。CPU性能など
レイテンシ(Latency):データの転送要求などのリクエストを発してから、リクエストの結果が返ってくるまでにかかる遅延時間
SPEC(specificationの略):性能一般。本来の意味は仕様書。
CDH3u0からCDH3u1のバージョンによる機能の追加
CDH3u0-> CDH3u1の機能追加の差分まとめ
・Snappy 圧縮の導入
・Debian Lenny やSqueezeをサポート
・DNのディスク障害をうまく(?)扱う
・NNの安定性が増した
・Fair SchedulerのACLを追加
・Fuse-DFSの安定性と性能が改善した
・HBaseのパッケージのアップデート(0.90.3)
・Hiveのパッケージのアップデート(0.7.1)
・Pigのパッケージのアップデート(0.8.1)
・Sqoopのパッケージのアップデート(1.3.0)
・Flumeのパッケージのアップデート(0.9.4)
・OozieのE-mail機能や日付フォーマットが追加
・HueからPig,Flume,HBaseでHueのコマンドラインシェルを使うためのHue Shellを追加
参考:
https://ccp.cloudera.com/display/CDHDOC/CDH3+Release+History
NoSQLとRDBMSはどう違うのか
DB初心者がNoSQLとRDBMSの違いを調べてみた。
NoSQL=Not only SQL
RDBMS=Relational DataBase Managiment System
NoSQLのメリットは「性能」、「拡張性」、「非構造化データを扱えること」、「大規模データを扱える」だという。
・性能
RDBMSは更新時などには行単位のロックをかけなければならない。もし大規模なデータを扱うとなれば、サーバ台数を増やしてスケールアウトすることも必要となるが、一度ロックがかかるとその行にはアクセスできなくなるわけなので、スケールアウトした利点が生かせない場合がある。
一方NoSQLのキーバリューストアなどはロック単位が小さいため、分散処理に向く。例えば列志向の分散処理データストアのHBaseなどは典型例だろう。
・拡張性
これはRDBMSの欠点か。性能問題が出てきた場合、RDBMSでは制約が多く、性能改善を図るのが難しい(?)場合があるらしい。
・非構造化データを扱える
そもそもデータの持ち方が違う。
RDBMSは行でデータを管理する。また、行のスキーマ構造を設計段階で決める必要がある。そのスキーマは厳しく管理されていて、多くの制約がある。ただし、この制約があるからこそSQLを用いたビューや結合処理を実行することが可能になる。
NoSQLの代表的な例であるキーバリューストア(たとえばHBase)ではキー:値というシンプルな構造である。ハッシュのようなものを想像すると近いらしい。
・大規模データを扱える
RDBMSは大規模データを扱う場合、検索処理が重くなったりするので、indexを作ることがある。POSなどのビッグデータを扱う場合、このindexを作るのにも量が多すぎると更新処理のたびにindexを付け替える必要が出てくる。
他にもトランザクションの扱いが異なるなど、NoSQLとRDBMSは対になる特徴がある。RDBMSは一貫性を重視するため、トランザクション終了後は値が確定している。
一方NoSQLは値が未確定な期間が存在するなど、使い勝手を重視していることから犠牲にしている部分もある。
参考:
日経BP ITPro記事など
http://itpro.nikkeibp.co.jp/article/COLUMN/20121005/427842/?ST=bigdata&P=1
http://itpro.nikkeibp.co.jp/article/COLUMN/20120828/418821/?ST=bigdata&P=1
http://www.atmarkit.co.jp/flinux/rensai/noSQL/noSQL_05/05_1.html
C++のユニットテスト
JavaだとJUnitなどが知られているが、C/C++では何があるんだろうか。
観点はいくつかあるみたいだが、どうやらCUnit/CppUnitはTDD(Test Driven Development)を行うにはテスト速度が遅い点でよくないらしい。
開発者が失敗作と言っており、別プロジェクトCppUnitLiteが作成されている。
他にもCutterやGoogle Test、Boostフレームワークを用いるものなど多数あるようだ。
Cutterは日本語ドキュメントが充実している。Windows,Linux,Mac OSにも対応している。
Google TestはMockオブジェクト(スタブのようなもの?)を導入可能など、機能面が充実しているようだ。
Boostはテストとは関係ないが、数学ライブラリや統計に必要なランダム関数(メルセンヌ・ツイスター)などが充実しているらしい。個人的に使ってみたい。
基本的な使い方としては、まずconfigureからmakeして、ヘッダファイルなどでテストのライブラリをインクルードする。ソースファイルのコンパイル時に-Lオプションでリンカを貼る。ソースファイル用のmakefileを一度作ってしまえば後はAssert、文字列比較を始めとするテストをがしがし書いていけばいいようだ。
まずはCutterあたりを使ってみるか…。
参考:
・http://k4zmblog.dtiblog.com/blog-entry-338.html
・http://cutter.sourceforge.net/index.html.ja
・http://opencv.jp/googletestdocs/primer.html
・http://d.hatena.ne.jp/tt_clown/20120214/cpp_test_framework