bpstudy#25に参加しました

 Posted on September 25, 2009  |  Toshiaki Baba

BPStudy#25に参加しました。 いつものとおりメモ。

MySQLのはなし

奥さん@サイボウズラボ

Happy Optimization

重要なこと

  • プロファイラを使う
  • Oprofileなどなど
  • 局所的な最適化よりも前に考えておくことがある
  • 投入したコストを回収できないと意味がない
  • 「物理限界の○○%」(MIPS、帯域など)を目標にする→ゴールが明確 物理限界＝ゴール(の目標値算出に使える)
  • 一般的にはIPCがネックになることが多い
  • ソケットだと 100k transaction/sec 程度
  • CPUクロックなどから限界値を算出する
  • サーバ側でがんばるか、がんばらないかは考えましょう
  • C10Kの問題はあるわけで。。。 限界を越えよう
  • SIMD(SSE)
  • Instruction per secが足りないならベクタ演算する
  • 圧縮する
  • I/Oの帯域が足りないなら圧縮転送
  • グループコミット
  • I/Oの帯域が足りないならまとめて書き込む(バッファリング)
  • ロック回避

Scaling

Scale?

  • CPU, Memory
  • ムーアの法則→半導体の集積度が18ヶ月で倍
  • Flash Memory
  • ファンの法則→容量が12ヶ月で倍
  • HDD
  • 容量がだいたい12ヶ月で倍
  • レイテンシ(ランダムアクセスの速度)は20年で倍くらい★
  • Network
  • 帯域がだいたい12ヶ月で倍
  • レイテンシは光の速度(日本～サンフランシスコで55msec)を越えない★ ★あまり伸びないものもある！

4Gbpsってどのくらい？

  • Networkで4GbpsのI/O→ 数千円(単純なSW)
  • HDDで4GbpsのI/O→ 20,000台くらい必要
  • →HDDがネックなのは明らか！

なぜスケールアウト？

2000年台から・・・

  • ソフトウェア製品からサービスになった
  • マスメディアからコミュニケーションツールになった
  • 多人数間の疎なソーシャルグラフが主になった →スケールアウトしやすい課題が増えてきた

Scaleout

  • RDB Sharding
  • MapReduce/Hadoop
  • KVS
  • KumoFS,,,
  • Message Queue
  • ActiveMQ, AMQP, Q4M,,, → HTTP / AP / Storage の3層構造になる データ容量増加(限界あり) x ムーアの法則(続く) → いずれ(また)スケールアップになる！

Incline & Pacific

大規模webサービスの課題

DBのスケールアウト＝RDBMSのパーティショニング

  1. まずはアプリケーションごとのパーティショニング
  2. 次はユーザごとのパーティショニング(ファーミング) RDBMSパーティショニングの問題点・・・
  • 事前の分割設計が難しい
  • 負荷のバランシング
  • データのバランシング
  • 再配置が難しい →KVSでは解決できている・・・が、機能が少ない 分散KVSの弱点は・・・
  • レンジクエリ(範囲指定)がない
  • トランザクションがない
  • リレーションがない
  • セカンダリインデックスがない →開発コスト増につながる。。。

CAP定理

Consistency(一貫性)、Availability(可用性), Partition-tolerance(分割耐性)のうち、同時に満たせるのは2つ RDBMSと分散KVSのいいとこどりをしたい！→Incline&Pacific Incline = ノード間のデータ同期を実現 Pacific = RDBMSのShardを実現

Clevver Way to Scale-out a Web Application

RDB Sharding

shardingをする上で、非正規化は必須 →リレーションを活用できない →おなじ処理をいろいろなところに実施する必要がある可能性があり 実現方法は・・・

  • eventual consistency
  • 高速
  • データが壊れやすい
  • 2-phase commit
  • 遅い
  • データは壊れにくい

Range-based sharding

range-basedがいい。

  • range queryが使える
  • 負荷のコントロールがしやすい(重いものだけ分割ができる)

Incline

ゴール

  • 複雑なupdateを解決
  • メンテナンスしやすくしよう →RDBMSのTriggerを活用して解決
  • 自サーバにあるデータはtriggerで更新
  • 他サーバにあるデータへは、trigger→自サーバのQueue→データがあるサーバを更新
  • 他サーバにあるデータがさらに別のサーバを更新する場合は、trigger→自サーバのQueue→データがあるサーバを更新→データがあるサーバのQueue・・・・となる 使いどころ
  • ACIDが必要な場合→XAで分散トランザクション
  • ACIDが必要ない場合→Inclineでスケールさせる ちなみに、設定ファイルはjson。

Pacific

Range-based shardingを実現するツール mysqld_jumpstart: mysqlのsetup tool

  • daemontoolsに登録
  • primary / slaveを作れる
  • バックアップスクリプトができる
  • XtraBackupで無停止でホットバックアップ pacific_divide
  • fail-safe
  • 分割前のテーブルに書き込みにいかない
  • ミソ：DBユーザを新たに作る。古いDBユーザの書き込み権限を外して、新しく作るので安全
  • ユーザ影響が少ない
  • eventual consistencyであればread lockほぼなし
  • consistencyモード(?)であればread lockがいるが、だいたい10秒以内 分割のときにはQueueが詰まる？→詰まる。Queueから取り出して他サーバへ転送するプログラムが止まるので、再立ち上げする。

DMIx::SharedManager

  • O/Rマッパー?
  • Range shardなDBに問い合わせをうまいことしてくれるらしい

キューの順序一貫性

  • Queueが「自分のもつキューについて」順序をコントロールする。
  • Queueから転送された先は関知しない
  • サーバBのキューに 1.B→A→C という転送が発生するメッセージ 2.B→C という転送が発生するメッセージ が登録されている場合、Cに対する操作の順序はどっちが先になるかわからない

Mycached

MySQLがmemcachedプロトコルを話せるようにする拡張(getしかできない)。 クエリパーサー・オプティマイザをパスしてデータを取得する。

  • レスポンスはjson, msgpack, 独自形式
  • Picoev(I/Oイベント駆動ライブラリ)を利用
  • MySQLの内部構造は多数スレッドによる並行アクセスに向いていない(らしい) 速い。一応。。。。

ヒトコト

shardingは難しい・・・のがうまいことなってくれるとすばらしい。 期待してしまいますね。 しかしデモがすごかった。すげー。すげー。

Event 

See also