CockroachDBにおける並行性モデル: シリアライズ可能なスナップショット分離の層を剥がす

CockroachDBは、分散ノード間で一貫性を維持するためにSerializable Snapshot Isolationを使用しています。タイムスタンプの順序付け、書き込みインテント、巧妙な競合処理を活用して、トランザクションが直列に実行されたかのように振る舞うことを保証します。まるでデータのタイムトラベルのようです！

舞台裏の仕組み：タイムスタンプの順序付け

CockroachDBのSSI実装の中心には、タイムスタンプの順序付けがあります。これは、デリカウンターで各トランザクションにユニークなチケットを渡すようなもので、冷肉の代わりにデータの一貫性を提供しています。

その仕組みは次のとおりです：

• 各トランザクションは開始時にスタートタイムスタンプを取得します。
• 読み取り操作はこのタイムスタンプを使用して、データベースの一貫したスナップショットを確認します。
• 書き込み操作は、適用準備が整ったときにコミットタイムスタンプを割り当てられます。

さらに、CockroachDBはHLC（ハイブリッド論理クロック）という巧妙なトリックを使用して、これらのタイムスタンプをノード間で同期させます。まるでデータベースのためのグローバルメトロノームのように、全員が同じビートで踊っていることを保証します。

HLC：データベース領域のタイムロード

HLCは物理時間と論理カウンターを組み合わせています。次のような構造です：

type HLC struct {
    PhysicalTime int64
    LogicalTime  int32
}

この便利な構造により、CockroachDBはクラスタ全体でイベントの全順序を維持することができ、物理クロックがわずかにずれていても問題ありません。まるでドクター・フーのタイムロードがトランザクションを管理しているかのようです！

書き込みインテント：データベース操作の「立ち入り禁止」サイン

次に、書き込みインテントについて説明します。これらは、トランザクションがデータを変更しようとするときにCockroachDBがデータ項目に掲げる「立ち入り禁止」サインのようなものです。要点は次のとおりです：

• トランザクションが書き込みを行いたいとき、まず書き込みインテントを配置します。
• 他のトランザクションはこれらのインテントを見て、注意して進むべきかを判断します。
• 元のトランザクションがコミットされると、インテントは実際の書き込みになります。
• 中止された場合、インテントはまるで何もなかったかのようにクリーンアップされます。

これは、最後のピザのスライスに「予約」をかけるようなもので、より正式なルールがあり、食べ物の争いの可能性が少ないです。

書き込みインテントの構造

CockroachDBの書き込みインテントは通常次のようなものを含みます：

type WriteIntent struct {
    Key           []byte
    Txn           *Transaction
    Value         []byte
    CommitTimestamp hlc.Timestamp
}

この構造により、他のトランザクションは誰が何をしているのかを知り、待つべきか安全に進むべきかを判断できます。

競合の処理：トランザクションが衝突するとき

では、2つのトランザクションが同じデータを変更しようとした場合はどうなるでしょうか？ここで、CockroachDBはいくつかのトリックを使って競合を処理します：

1. Wound-Wait

CockroachDBは、wound-waitアルゴリズムのバリエーションを使用します。これは、トランザクションに対する「年齢優先」の礼儀正しいバージョンのようなものです：

• 古いトランザクションが若いトランザクションと競合する場合、若いトランザクションは「傷つけられ」、中止して再試行しなければなりません。
• 若いトランザクションが古いトランザクションと競合する場合、若いトランザクションは礼儀正しく待ちます。

これにより、デッドロックを防ぎ、長時間実行されるトランザクションが短いトランザクションの洪水によって飢えないようにします。

2. トランザクションのプッシュ

時には、中止する代わりに、トランザクションが他のトランザクションを「プッシュ」することができます。これは、誰かにトイレで急いでもらうように頼むようなもので、うまくいくこともあれば、うまくいかないこともあります。

func pushTransaction(pusher, pushee *Transaction) error {
    if pusher.Priority > pushee.Priority {
        // 他のトランザクションのタイムスタンプを前に進める
        pushee.Timestamp = maxTimestamp(pushee.Timestamp, pusher.Timestamp)
        return nil
    }
    return ErrConflict
}

3. バックオフと再試行

すべてが失敗した場合、CockroachDBは一歩下がって再試行することを恐れません。これは指数バックオフ戦略を使用しており、「最初に成功しなかった場合、少し待って再試行する」という意味です。

グローバルな視点：世界中での調整

では、これがグローバルに分散されたシステムでどのように機能するかを見てみましょう。CockroachDBは「レンジ」という概念を使用してデータをノード間で分割します。各レンジは、フォールトトレランスのために複数回複製されます。

魔法は分散SQLレイヤーで起こります：

• 単一のレンジにのみ触れるトランザクションは、ローカルで解決できます。
• マルチレンジトランザクションは、2フェーズコミットプロトコルを使用して一貫性を確保します。
• システムは、各レンジの読み取りおよび書き込みトラフィックを管理するためにリースホルダーを使用します。

これは、データパケットのための高度に調整された航空管制官のチームを持つようなものです。

パフォーマンスの考慮事項：一貫性の代償

「これはすべて素晴らしいが、パフォーマンスはどうなのか？」と考えるかもしれません。そして、それは正しい質問です。SSIは無料ではありません。いくつかのトレードオフがあります：

• 読み取り操作は、進行中の書き込みが完了するのを待つ必要があるかもしれません。
• 書き込みスキューの異常は防止されますが、再試行の可能性があります。
• スナップショット読み取りのためにデータの履歴バージョンを維持する必要があります。

しかし、CockroachDBにはこれらのコストを軽減するための最適化があります：

• 競合しないトランザクションのためのロックフリーの読み取り。
• ネットワークラウンドトリップを減らすためのキャッシュの巧妙な使用。
• ストレージオーバーヘッドを管理するための古いバージョンの非同期クリーンアップ。

すべてをまとめる：CockroachDBトランザクションの一日

これらの要素がどのように組み合わさっているかを確認するために、典型的なトランザクションライフサイクルを見てみましょう：

1. トランザクションが開始され、HLCからスタートタイムスタンプを受け取ります。
2. データを読み取り、開始時点の一貫したスナップショットを確認します。
3. 書き込みを行いたいとき、影響を受けるレンジに書き込みインテントを配置します。
4. 競合が発生した場合、必要に応じて待機、プッシュ、または再試行します。
5. コミットの準備が整ったら、複数のレンジが関与している場合は2フェーズコミットを行います。
6. コミットが成功すると、書き込みインテントは実際の書き込みに解決されます。
7. 他のトランザクションは、スナップショットで変更を確認できます。

これは、データが一貫して正確であることを保証するための慎重に振り付けられたダンスのようなものです。

まとめ：CockroachDBにおけるSSIの美しさ

CockroachDBのSerializable Snapshot Isolationは、データベースエンジニアの創意工夫の証です。タイムスタンプの順序付け、書き込みインテント、洗練された競合処理を組み合わせて、分散システムで強力な一貫性の保証を提供します。

課題はありますが、特に書き込みスキューのような異常を防ぐSSIの利点は、最高レベルのデータ整合性を求めるアプリケーションにとって強力な選択肢となります。

次回、CockroachDBを使用して、グローバルに分散されたアプリケーションが一貫性を維持していることに驚嘆するとき、タイムスタンプ、インテント、競合解決の複雑なダンスが舞台裏で行われていることを思い出してください。それは魔法ではなく、非常に巧妙なエンジニアリングです。

「分散システムでは、一貫性は与えられるものではありません。それは慎重な設計と細部への絶え間ない注意によって得られるものです。」 - おそらく賢明なデータベースエンジニア

考えるための材料

まとめとして、考えてみるべきいくつかの質問を紹介します：

• SSIは、さらに大規模なシステムに対応するためにどのように進化するでしょうか？
• 分散データベースの限界を押し広げるとき、どのような新しい課題が生じるでしょうか？
• 将来のデータベース設計において、一貫性、可用性、パーティション耐性のトレードオフをどのようにバランスさせることができるでしょうか？

分散データベースの世界は常に進化しており、CockroachDBのSSI実装はこの継続的な物語の中の一つの魅力的な章に過ぎません。探求を続け、質問を続け、次の章を書くのはあなたかもしれません！