BASE特性

Last updated Unknown Edit Source

• NoSQLの場合などに適用される

  • CAP定理で、AとPを保持している状態

• リレーショナルデータベースのACID特性の反対? (ネーミングが天才)

• システムの一部が落ちても、全体が動き続ける

• システムのデータが常に変化する 結果整合性)

• 最終的に一貫性が保証されればOK (ゆるい一貫性)

  • 強い一貫性が求められる場合（ACID特性とか)は、 = writeをされた瞬間以降のreadは絶対更新されている
  • Eventual Consisencyだと、そうはならない
  • writeのあとにreadの値が更新されるまでにラグがあってもOK

• “Quorum”: NoSQL等で、分散システムで処理の整合性を保つ技術

  • Write-Write [競合]や、Read-Write競合(間違ったデータが読まれる)を回避したい
  • 複数のレプリカを同時にread/writeしてあげれば、安全になりやすい
    • 具体的には
      • Write-Write競合回避: w > n/2
      • Read-Write競合回避: r> n-2
      • (n: 全体のレプリカ数, w:同時にwriteするレプリカ数, r: 同時にreadするレプリカ数)
    • などの条件がある