Skip to content

Instantly share code, notes, and snippets.

@shu-yusa

shu-yusa/fukabori-fm-8-note.md

Created December 28, 2020 06:58
Show Gist options
  • Save shu-yusa/3ccbacefe3273ef0c533d8ff81bce2e3 to your computer and use it in GitHub Desktop.
Save shu-yusa/3ccbacefe3273ef0c533d8ff81bce2e3 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
fukabori-fm-8-note.md

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の簡潔な解説

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment