NoSQL(Key/Value store)の一覧と機能の比較表
表の見方
○ 有り
☓ 無し
| 名前 | 主要アルゴリズム | 開発言語 | WebAPI | Key専用サーバー | Key専用サーバーの冗長性 | Valueサーバーの冗長性 | 処理速度のスケーラビリティ限界点 | 容量のスケーラビリティ | ライセンス |
|---|---|---|---|---|---|---|---|---|---|
| LevelDB | Skip list | C/C++? | 調査中 | 調査中 | 調査中 | 調査中 | |||
| okuyama | 調査中 | Java | 調査中 | 調査中 | 調査中 | 調査中 | |||
| EHCache | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | |
| Redis(Jedis) | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | |
| Mongodb | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | |
| Apache Cassandra | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | |
| GREE Flare | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | |
| Tokyo Cabinet | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | |
| Kyoto Cabinet | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | |
| Tokyo Tyrant | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | |
| Kyoto Tycoon | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | |
| Hibari | 調査中 | C | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | |
| Dynamo | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | |
| Voldemort | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | |
| Riak | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | |
| babuDB https://code.google.com/p/babudb/ | 調査中 | Java/C++ | |||||||
| memcached | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | |
| Berkeley DB | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 | 調査中 |
以下RDBMS
| 名前 | 主要アルゴリズム | 開発言語 | WebAPI | Key専用サーバー | Key専用サーバーの冗長性 | Valueサーバーの冗長性 | 処理速度のスケーラビリティ限界点 | 容量のスケーラビリティ | ライセンス |
|---|---|---|---|---|---|---|---|---|---|
| MySQL | Hash table + Btree? | C/C++ | 調査中 | 調査中 | 調査中 | 調査中 | GPL もしくは コマーシャルライセンス | ||
| PostgreSQL | Hash table + Btree? | C/C++ | 調査中 | 調査中 | 調査中 | 調査中 | BSD License | ||
| SQLite3 | C | 調査中 | 調査中 | 調査中 | 調査中 | public domain? |
PearPCではなくQEMUを使おう！
昔、PowerPCエミュレーターとしてはPearPCが注目されていたがリリースされているバイナリがあまりに残念で使えないのでQEMUを使うのがベストだと思った。
- WindowsならばQmenu Manager 7.0
- Linuxならばvirt-managerの類とQEMUのパッケージいろいろ。
これだけで良い。
Qemu Manager 7.0でPowerPC Debian GNU/Linuxを動かす手順
- PowerPC Debian GNU/Linux squeezeをダウンロードする。（wheezyは何か不具合があって途中で止まったりとうまく動かない。）
- QEMUのブートはCDを最初にしておく
- CD-ROMドライブにsqueezeのイメージを設定する。
- CPUの設定は32bit PowerPC G4（探すのが大変だが）とする。
- QEMUのMain DisplayをWindowにする。
- QEMUを起動したら通常のDebian GNU/Linuxと同じようにインストール。
- QUIKはインストールする。逆にできない場合は設定を疑うこと。
問題
- X Window systemがとてつもなく遅い上に色が変。
NoSQL(KVS)のベンチマーク指針
Key型
- Register size Static Int
- Non Register size Static Int(static binary)
- Dynamic size Int(dynamic binary)
- Static size String
- Dynamic size String
検索方法の種類
ベンチマークの種類
- 単一サーバー
- 3台サーバー分散
- 10台サーバー分散
- 50台サーバー分散
- xxx台サーバー分散
アプリを作る際の方法論ではなく手順論
方法論は色々あると思うが、手順のみということで手順論を示していこうと思う。この手順に沿っていないと人的リソースの出入りでアプリ開発のノウハウが散逸してしまうのでそれを防止するためである。今のこのエントリーではまだとりあえずの私見としての草稿段階である。しかし、手順についての有用な手法を持っていない人には役に立つであろう。
１．コーディング規約を決める。
例：
・オブジェクト指向で作る。『インターフェース』と『共通の機能は基底クラス』、『派生クラス』の分離を行なっておくこと。
・実装を変える際は正常に動いているものは残しておいて、別のクラスに実装して入れ替える。（すなわちストラテジーパターン）
・状態遷移はアクセプタFSMをベースにする。
・エラー処理の方法「VM言語の場合は処理速度的に例外でエラーを返した方が良い。Native言語の場合はアーキテクチャに寄るが、C++の場合は処理速度的には基本的に戻り値でエラーを返す。」
・ビジネスロジック部（アプリ固有の状態遷移部）とライブラリ部（アプリで使用する機能、その他共通する機能群）の分け方を明確にする。
・ビジネスロジックの実装はストラテジーパターンで簡単に入れ替えが出来るようにしておく。
・コメントは〜〜のように書くなど（英語か？日本語か？）doxygenやjavadocスタイルに準拠させるか？など 特にifやswitchなどの条件分岐の理由をコメントで残しておくとソースコードがぐっと見やすくなる。
２．簡単な仕様書をドキュメントとして残す、書いておく
例：
・テスト環境、本番環境、コーディング環境などの作り方、設定方法などのノウハウ。（これら３つの事を丁寧、親切に記していないとかなりのタイムロスが起こる事がある。）
・必要な機能と実装優先度
・ユーザー側からの操作の詳細
・エラーが起こった際のチェックする所やエラー原因の特定方法、ログファイルのパス名など
・コード内の構造やソースコードファイルの説明など
・Subversionやgitなどのコード共有場所など
・アプリに使用する機能のついての所感や多数のソリューションがある中での採用理由、メリットデメリットなど
以下３〜５は必要に応じて横断的に行う。
３．テストケースの実装
・要するにTest Driven Developmentである。正しいテストケースの無いプロジェクトは人的リソースの出入りによって炎上する。
・フルスクラッチの場合このテストケースを作る際にインターフェースとエラーチェックの機能を実装する事が多い。
４．機能の実装
・要するにライブラリ作りである。ライブラリを作り終わったら前に作ったテストケースを用いてテストして不具合やバグが無くなるまでしっかり作ろう
６．ユーザー視点からのテスト
ユーザーが使う視点から実際にアプリを起動させて動作確認をしよう！動作確認リストをこの時に作ったほうが良い。（３・４・５のうちに色々あって２で作ったユーザー視点での動作確認リストは時代遅れになっている可能性が高いから）
エンドユーザーにテストしてもらって色々と改善箇所を洗い出そう。
７．ユーザー用、開発者用のマニュアルを作ろう
・マニュアルがなければどんなに高機能なアプリでも意味もワケも分からない無用の長物に成り果ててしまうでしょう。
・ユーザー側は画面の画像と矢印などを使って懇切丁寧に
・開発者側は別の言語や開発環境を使っている人が見ても分かるように書いておく。既知のバグリストと決定稿の仕様書もつけておく。
・６のエンドユーザーのテスト結果を元に厳密な仕様書とテストケースを作る。必要があれば３〜５に戻って改修、作り直し
８．厳密なテストケースを通過したらリリース
７で洗いだした厳密なテストケースを通過したらリリース可能なクオリティーになっているのであとはリリースを待つだけ！
Debian 7.1 BD imageのダウンロード方法
ブルーレイ版でびあんを作ってみたかったのでDebian 7.1 BDimageをjigdoでダウンロードしてみた。
jigdoの使い方*1は間違っていないはずなのに何故かダウンロード出来ない。その理由は、BDimageは日本のミラーサーバー http://ftp.jp.debian.org/debian/ にはBDに必要な素材が用意されてないのでダウンロード出来ないからだ。
よって本家から取り寄せなければならない。jigdoファイルのURLを http://cdimage.debian.org/debian-cd/7.1.0/amd64/jigdo-bd/ よりリンクをコピペしてきて設定。
debianMirrorサーバー、nonusMirrorサーバーはすべて本家のURL http://ftp.debian.org/debian/ に設定すれば問題なく処理が済むのでDebianのブルーレイisoイメージが欲しい人は試してみてほしい。
jigdo-lite-settings.txt
jigdo='http://cdimage.debian.org/debian-cd/7.1.0/amd64/jigdo-bd/debian-7.1.0-amd64-BD-1.jigdo' debianMirror='http://ftp.debian.org/debian/' nonusMirror='' tmpDir='.' jigdoOpts='--cache jigdo-file-cache.db' wgetOpts='--passive-ftp --dot-style=mega --continue --timeout=30' scanMenu=''
