fukabori.fm #8

8. AWS Aurora、GCP Spannerへ辿り着くまでのDBの進化

• 70年代 メモリが高価(1MB 100万円)でハードディスクが比較的安価(100MB 数十万円)の時代

  • バッファに乗り切らないデータをハードディスクに書き戻さないといけない。しかし復旧時にもトランザクションに矛盾を起こしてはいけないという課題があった。
  • 80年代にIBMがARIESを作り、その後の標準的な実装となった.
  • ARIESではログの仕方、バッファプールの仕方、リカバリの仕方は密結合になる。ARIESはSteal/No-forceの組み合わせでログを取る。
    • Steal: トランザクションをコミットする前にディスクにフラッシュすることを許容する。リカバリの際には、未コミットだけどフラッシュされたトランザクションはundoする
      • 未コミットの永続化されたデータをundoするためにundoログが必要。
    • No-steal: 未コミットのトランザクションをディスクへフラッシュするのを許容しない。
    • Force: トランザクションをコミットする前に変更されたページのフラッシュを要求する。
    • No-force: コミット時点でのディスクへのフラッシュを強制しない。まだフラッシュしていなくてもトランザクションをコミットしてよい。
      • 永続化されていないトランザクションを復元しないといけいないため、redoログが必要。
    • 参考スライド: https://www.slideshare.net/kumagi/ss-64459138

• マルチコアの時代、メモリの低価格化

  • 新しいアーキテクチャが探求されたが、インメモリdbは主流にはならなかった
  • 新しい時代の課題: writeが増えた時のトランザクション性能が伸びない。パーティショニングなどで対応してきた。

• AWS Aurora

  • Auroraはundoの情報をログのなかに含めず、redoログをクラウドに保存する。undo情報をディスクに書き込まない。ページの復旧の一貫性はクラウドが担当する。
  • マルチマスターも部分的にサポートする。リージョンごとにマスターが設定できる。

• Google Spanner

  • 分散キーバリューストアに近いアーキテクチャ
  • 数千行単位で区切って、そこに対するマスターがスパンサーバーとして受け持つ
  • 各スパンは3多重でpaxosで一貫性を保つ
  • 生まれからマルチマスター。スパンが増えればマスターも増える
  • 局所性が効くなら有効性は特に高いかも

• Paxosの簡潔な解説