先週の金曜日に恵比寿で行われたBPStudyに参加してきた。
今回はサイボウズラボのkazuho氏を講師に招いて「パフォーマンスとスケーラビリティのためのデータベースアーキテクチャ」ということで、データストレージ（RDBMS/KVS）の動向、incline/pacificを利用したデータベースのシャーディングデモなどを聞かせていただいた。
メモ書き程度で申し訳ないですがざっくりと。
“Happy Optimization”
パフォーマンスチューニングに関する話。
パフォーマンスを測定するにはプロファイラ使うべき（当たり前）、「30%はやくなったよ」はダメ。ずっと続けてしまう。コストを投入して回収することを考えるべき。
処理速度は上限があるはず。MIPS、バンド幅（帯域）、アクセスタイム（レイテンシ）
「理論値の70%に到達したよ」は良いパターン。理論値が解ることで事前に処理限界がわかる。
MySQLの話
某つぶやきサイトのデータ構造を例にあげて色々考える。ベンチマークハードウェアの処理限界は2600QPSのはず（3GHz P4）。
予測方法
mysql_timelineはプッシュモデルの値、OS内部はIPCのコストがボトルネック、I/O waitの間に他の処理を加えられる。
性能向上のためのアプローチは、例えば、命令数が足りない→SIMD使う、バンド幅が足りない→圧縮する、アクセスタイムが遅い→グループコミット（個々のトランザクションのレイテンシの隠蔽）。
グループコミットはPostgreSQLでも処理性能改善に寄与している手法。
lock free algorithmを採用したい。何故か？ロックで遅くなる→可能な限りロックしないで頑張る。
Scaling(資料)
ストレージ、ネットワーク、レイテンシについてのスケーリングの話。
ムーアの法則、半導体の集積度が18ヶ月で倍になる。処理性能も。ファンの法則、フラッシュメモリの容量、12ヶ月で倍になる。 ハードディスク（容量の増加率忘れた。89年40MB→2009年2TBとか）。WAN回線。99年、56kbps-128kbps, 09年、1.5Mbps-100Mbps。
HDDのアクセス性能は20年で倍にしかなってない、これからもほとんど向上しないと思われる。WAN回線レイテンシ、東京→SFで光の速度で55msecかかる、物理的な制約。
例えばHDDランダムリードで0.5BG/sec出すには2000台必要。
HDDにアクセスするソフトウェアは、RDBMS、ファイルストレージなど永続化が必要なものにはHDDのようなものが必要。
SSDにしたら解決可能。ただし、価格がネック。
CPU intensiveな処理もある、XMLのパースなど。
「スケールアウト」、2000年代のトレンド。ソフトウェア製品はスケールアップ、サービスはスケールアウトの方向になってる。
スケールアウトのソフトウェア技術、MapReduce/Hadoop, KVS, MessageQueueなど。
規模の拡大 vs ムーアの法則
例えば、mixiのユーザ数が1000倍になったりしない。データ量の増加が一定であれば、ハードウェア性能が追いついて、いつかスケールアップの時代が来る。
データベースのスケールアウト
RDBMSのパーティショニング、テーブルスペース、データベースリンクにより分割。RDBMS捨てちゃえよ→KVSへ
RDBMSパーティショニングの問題。 事前の分割設計が難しい。特定のサーバが過負荷になったり、サーバ間の負荷が均等にならなかったり。
KVSの問題点。 Consistencyモデルが弱い、トランザクションがない（ことが多い）
CAP定理とは？Consistency, Availability, Partition-tolerance。同時に満たせるのはこのうち2つのみ。
Incline & Pacificの目指すもの RDBMSと分散KVSのいいとこどり。Inclineはノード間のデータ同期に専念、PacificはRDBMSのShardに専念、ORマッパつかうかSQL書くかは自由。
RDB sharding eventual consistency→非同期で更新→スケールする→同期を作り込むのが大変。
Incline 同期を作り込むのが大変なので書いた(?)。データベーストリガを利用する。トリガの生成は定義ファイルから。シャーディング方式はrangeベースがいいです。ハッシュはダメ。
Pacific mysqld_jumpstartというユーティリティを提供。daemontools使ってサービス開始してくれる。primary, slave両方セットアップします。バックアップスクリプトもインストールします。動作中のサービスでレンジの分割を自動的にやってくれる。
A better cached RDBMSスケールしない→スケールするキャッシュが欲しい、incline/pacific使えばRDBMSスケールする！→でもSQLは遅い。
mycached MySQLのテーブルにmemcached protocolでアクセスできる→ただしprimary keyにでのgetのみ書き込みはSQLでやってね。レスポンス形式はmemcache native, json, messagepackが使える。
シングルスレッドでイベント駆動している。getは軽いので他の接続はブロックしても大丈夫。ベンチマーク結果は8万QPS(4core opteron)
ウェブアプリケーションはストレージやデータベースの負荷が読みづらいという特性があると思う。そこをシャーディングで解決しようという技術。
シャーディングの方法、ほぼオンラインでの分割（10秒くらい止まるらしい）は、頭では考えつくものの、なかなか実施しづらい。incline/pacificはその辺りを解りやすくまとめたソフトウェアパッケージという印象。
memcacheプロトコルを利用したサーバソフトウェアはたくさんある（memcached, repcached, flareなど）が、MySQLのテーブルに対して適用したのは斬新。
クライアント側でも定義ファイルをincline/pacificのコンフィグをparseしてデータベースに接続する必要があり、汎用的とは言えないが、コンフィグの共有さえ出来れば他の言語でも同様のアプローチが取れるはず。で、python版のPyShardManagerが早速ローンチした！
内容が深くて追いかけるのが大変でした。情熱を感じられる勉強会でした。
[ad#text_wide]
