はじめに
昨年FoundationDB の大きなリリースがあって噂になっていました。
毎秒1400万回のライト(write)を行うNoSQLデータベースFoundationDB、ACIDの条件も満たす
一応どういうものか知っておこうと思って調べたメモです。
FoundationDBはだいたいどういうものなのか？
大雑把に
CouchDBっぽいけど、ACIDとSQLインターフェイスを備えており、CouchDBよりもスモールスタート可能でかなりスケールする順序付きKeyのKVS
- CouchDBっぽい： NoSQLで容量・性能ともに結構スケールする点が似ている（個人的な主観…）
- ACID装備： 永続化、Atomicな処理、Serializableなトランザクションレベル、結果整合性ではなく強い一貫性があります。
- SQL装備: 高速なKVSレイヤーの上にSQL Layerがあります。ANSI SQL 92のSQLが使えます。一部特殊な文法がありますが、ActiveRecordやDjangoのORMなども使えるようで実用的には十分なレベルっぽいです。
- スモールスタート可能： FREE ライセンスで6プロセスまで使えます。2〜4Coreの2台のPCに2~3プロセスずつ、みたいな構成なら無料っぽいです（たぶん）。それでどのくらい性能が出るかは後述。
- 順序付きKeyのKVS： ordered KVS とあります。
getrangegetrangekeysみたいなコマンドもある。
ライセンス/料金体系
https://foundationdb.com/pricing を参照。
$99/process/month とすると、6プロセスを超えると1サーバ当たり1.x万円増えるくらいの換算なので、1サーバ5万円/monthだとすると20〜30%くらい値段があがるというイメージです。
6プロセスを超えた分のみ課金されるのか、最初から課金されるのか不明。。。
※（10プロセスのときに、「4プロセス分の料金」なのか「10プロセス分の料金」なのか）。例を見ると後者っぽいかな。
「プロセス」という単位は正しく理解できているかわからないけど、「サーバ（Root）プロセス」の数なのかなと思います。Core数とは関係ないっぽい。
特徴
性能
KVSレイヤーとSQLレイヤーを別々に考える必要があります。
どちらにせよ、私どもの用途の範囲だと現実的な費用で十分スケールアウトで対応できます。
KVSレイヤー
- 400CoreくらいまでリニアにScaleする
- Latency： 参照系で1ms以内、更新系で5ms以内くらい？
- Start Transaction: 0.3-1ms
- Read: 0.1-1ms
- Commit: 1.5-2.5ms
- SSD engine Throughput(per core)
- read 100%: 55,000/sec
- write 100%: 20,000/sec
このデータとは別に 1440万 write/sec も達成しているようです。
FREEで使える6プロセス（コア）で動かすとすると、Write100%で12万/sec, Read100%で33万/secくらいでしょうか。
SQLレイヤー
Sysbench benchmark を read/write で 80GB、3億レコードのデータでベンチマークを取った場合、約300TPS(Transaction per sec)だったようです。これはMySQL5.5.37の約半分くらいの数字です。
このベンチマーク自体結構シビアな条件のものですが、一応この数字をベースに考えると、
FREEで使える6プロセス（コア）で動かすとすると約1800TPSということになりそうです。
システム構成上、KVSレイヤーかSQLレイヤーがボトルネックになるわけですが、ボトルネック側を増強すれば良いという考えで対応できるようです。
※話はそれますが、このような一般的なベンチマークツールが使えるということ自体が、SQLの互換性がなかなか高いということを表すのかなと思います。
運用
https://foundationdb.com/key-value-store/documentation/operations.html
今度読んで試したい。
- 知りたいこと：稼働しながら無停止でClusterの追加が可能かどうか
制限事項
FoundationDBの設計上の制限
- 5秒以上のトランザクションは実行できない
- １トランザクションで 合計10MBを超えるデータの読み書きはできない
- Keyのサイズは10KBまで。Valueのサイズは100KBまで。
- HDDを使って SSD Storage Engineを使うと性能や可用性で問題が出るだろう。
- 大きなOffsetのQueryは遅い。 O(offset)の実行時間がかかる。
現時点での制限
- Clusterサイズは 500core/process までしか検証されていない
- Databaseサイズは 100TB までしか検証されていない
- 遅いNodeがあると全体の性能が落ちるだろう
- 複数データセンターモードで動いている場合、データセンター障害はサーバ障害と捉えられるので余分なレプリケーションなどが実行される。
- システムのUpgrade（バージョンアップ）はDowntimeが発生する。（SSD Storage Engineなら数秒程度でできる）
- Readに関するロードバランスには改善の余地がある
- 例えば他のアプリケーションなどがDISKを使い果たしたら可用性が妥協される(compromised)
- CPUやネットワークが遅いと性能が劣化したり、切断されたりする。
用途
（額面通りに動くと仮定して、の話ですが）
基本的にかなり更新性能を要求されるシステムじゃないとメリットはないように感じます。
なにせ、RDS(MySQL, Postgresql)の性能・運用コスト・費用が非常に優れているので、新しいこのDBの運用ノウハウを獲得して運用するコスト、そして失敗するリスクのコストが割高に感じてしまいます。
しかし、「スモールスタートで開始して、青天井気味に書き込み性能が要求されるようなシステム」「基本KVS用途で更新が激しいけど、条件で検索もしたい」であれば挑戦する価値がありそうです。ACID特性、スケール能力、SQLやORMも使える、費用も現実的、というのはかなりすごいことです。Shardingや、頻繁な書き込みはNoSQL、それ以外はRDBMSみたいな使い分けが不要になるのも嬉しいです。
例えば、「大きく育ちそうなソーシャルゲーム案件」「IoT的なデータを収集するプラットフォーム」とかなら検討の余地がありそうです。
注意点
5秒以上のトランザクションは実行できないというのは、バッチ処理的な処理が難しいということなので、別の対策が必要になりそうですね。これは結構ネックかもしれません。
追記: 2015/2/4
SQL Layer2.1 では Read系のSQLなら5秒の制限がなくなったそうです。
SQL LayerでKVS LayerへのQueryを分割して実行するみたいです。
https://foundationdb.com/layers/sql/documentation/ReleaseNotes/2.1.0.html
※ Writeはだめ。Transaction Level は READ COMMITTED NO SNAPSHOT になるそうです。
さいごに
Amazon Auroraが今すぐ使えるなら、もう面倒だからそっちに、、、とかなりそうですが。
何か間違い等ありましたら、ご指摘いただけると幸いです。