H-Storeのプレゼン資料

Fault&Tolerant,Distributed,Transac3ons,for,Partitioned,OLTP,Databasesを読んでのメモ。H-Storeプロエジェクトが、まだまだ色々活動しているのを知らなかった。Publications « H-Storeに、ドキュメント群がある。今回のメモは、そのなかのひとつ。

• Dtxn は、OLTPに特化した用途の中で、フォールトトレラントな分散データベースを構築するためのフレームワーク。
  • OLTP向けデータベースに、再利用可能な基盤を提供。
  • 並列制御に投機的実行を用いる。
  • キャッシュベースアプローチを用いて、ライブマイグレーションを提供

以下は、上記の詳細について。

OLTP向けデータベースに、再利用可能な基盤を提供。

• データベースをパーティション分割して、それぞれのパーティションに対して、クラスタを構成する。
• それぞれのクラスタでは、レプリカ？の管理も行う。
• 各パーティションをまたがるようなトランザクションに対しては、コーディネーターが管理を行う。
  • トランザクションは、ラウンド(rounds)から構成される。ラウンドは、断片(fragments)から構成される。
  • ラウンドは、トランザクションのアクション単位だと思う。で、分散なので、各パーティションに対するアクションとしてfragmentをもっている。
• H-storeの特徴
  • メインメモリ上にデータを格納
  • シングルスレッドでの実行(無駄なロックを外したい。以前読んだ論文で既存RDBMSのボトルネック調査に基づいているはず。)
  • ストアドプロシージャを前提とした最適化
  • MySQLのストレージエンジンを利用
  • 伝統的なSQLを提供

並列制御に投機的実行を用いる

• ロックベースのトランザクション並行制御は、CPUボトルネックのの30%-40%を占める。
  • ロックとundoログをやらない。
• 並列制御を行う理由
  • disk 起因での処理停止->メモリ上にデータを持っていることで対処
  • user 起因での処理停止->ストアドプロシージャとすることで対処
  • マルチコアの有効利用->パーティションごとにCPUをひとつ割り当てる
  • 長期間実行されるトランザククション対策->そもそも長期間トランザクションはない。
• 案
  • ひとつのパーティションでは、ある時に高々１つのラウンドしか実行しない。
  • シンプルでわかりやすい。
• 分散の場合はどうか
  • OLTPのベンチマークモデルでは、通常トランザクションは、パーティション内に閉じる
  • 11%程度が複数パーティションを必要とする。
    • 単純な案:ブロック
      • トランザクションが終わるまで、ほかは待たせる
      • トランザクションを一元管理して、順序性を担保するコーディネータが必要。
      • ただし、この案だと実質的にはトランザクションが終わって、調整に必要なプロトコルをやり取りしている間まで待つことになりもったいない。
    • そこで：２フェーズロック
      • 待ち時間であっても、衝突しないでトランザクションの実行可能
      • 重たい。
      • デッドロックへの対処について、要検討
    • なので：投機的実行
      • ロック無しでできる。
      • トランザクションのグローバルな順序性保証が必要。
      • アボートしたときに、連鎖してアボート処理が必要。
      • といっても、複数のパーティションから読み込んで、それら二つから結果をだすような複数ラウンドなトランザクションだとまたないとならない。
• 結果
  • 投機的実行方式のほうが、ロック方式より早い（ただし、複数パーティションをまたがるトランザクションの率が半分以下の場合。）
  • ただまあ、おもったより、高速化して無いようにも思う。
  • ブロッキングは、ロッキングに比べて格段に遅い。
• TPC-C
  • 投機的 > 1.1xブロッキング > 1.8xロックという感じか。

ライブマイグレーション

• これまでのやり方。
  • コピー元停止とコピーと再起動：時間かかる
  • 起動したままコピー->キャッチアップ->コピー元停止->キャッチアップ停止->フェールオーバ->warm cache
    • warm cacheとはなんぞや？と調べると、Warm cache and Cold cache hint.. | Oracle Communityに説明有り。とりあえず、メモリ上にあることを言うらしいが、本当かな？まあ、この文脈ではディスクに保存ていうことはないから、間違ってないと思う。
  • 仮想マシン間同期:最近こういったアプローチ流行ってる気はする。
  • 提案：Dtxnの場合
    • とりあえず、マイグレーションを完了させる。
    • copy on write的に必要になったら、問い合せて情報を移動。
    • とりあえずの負荷が無い。部分マイグレーションができたりする。
    • ただし、ストレージとの一貫性が要求される？よくわからない。
    • select x, y, zをリライトして、select *とすることで、マイグレーションの効率化を行う、これは面白い着眼点だ。
    • この手法は、他に比べるとほとんどスループットに影響しない、マイグレーションにフォーカスして、この結果出すのは渋いなあ。