• Conflict-free Replicated Data Typeとも

  • コンフリクトせず、複製可能なデータ

  • 分散環境においてCAP定理AvailabilityPartition-toleranceの両立を実現する

  • ネットワーク上に異なるバージョンのデータ(レプリカ)を存在させる

  • データへの操作を可換なものだけに限定する

    • 足し算など
    • 操作列がすべて到達すれば、すべてのノードのレプリカは収束する→Strong Eventual Consistency!
  • Local firstなソフトウェアを実現する

  • CmRDT (Operation-Based CRDT)

    • 操作を送り合う
      • atSource (prepare): ローカルレプリカのみで実行される。操作と現在の状態を調べ、操作を表現するためのメッセージを生成する
      • downstream (effect): リモートで適用される
    • 操作が可換である必要がある
    • 操作列がすべて到達しないと収束しないので、操作が確実に&一度だけ伝わるような信頼性の高いメッセージング機構が必要
  • CvRDT (State-Based CRDT)

  • 全体はのトリプルから構成される - : Join Semilatticeなステート - : Mutatorの集合。Mutator は、状態を受け取り、新しい状態を返す - Mutatorはインフレーションするように定義される。(monotonic semilattice構造) が成立する - Mutator: 例えばカウンタならinc(), dec()など - : クエリ関数の集合。

    • Join Semilatticeなレプリカ自体を送りあい、マージ
    • マージするときに、コンフリクトしているかどうか判定するために論理時計が使われている?(kekeho)
      • LWW Registerとか、一部のCvRDTはそうっぽいな(kekeho)
  • アプリケーション

  • CRDTはNon-adversarial(非敵対的)なシナリオで有効

  • 発展形としてδ-CRDTというのもあるらしい

解説

実装

アプリケーションで使われているCRDT

注意

  • CRDTsは書き込みをConflict-freeにしているだけで、読み込みは”annoying”であることが指摘されている
    • Early Read(Potato Ferrari Problem): 2P-Setのショッピングカートに、ポテトとフェラーリを入れる。その後フェラーリを外し、チェックアウトする。フェラーリを外すより先にチェックアウトが走ると、どっちも買うことになる。全てのDeleteが到着したかどうか、カートは知る由もない。
    • Keep CALM and CRDT on: 読み取りクエリもmonotonicにするには…という話が整理されている

その他

A comprehensive study of CRDTsのまとめ