BASE特性

Last updated Unknown Edit Source

• NoSQL

  NoSQL

  [データベース]の講義 定義が広い/曖昧? 1998: RDBMSからを除外したを指す用語として定義された 2009: [リレーショナルデータベース]]以外の[[データベース]を指す用語として定義された のための新しい世代の を持つ 強み データ容量が大きい（大量のデータを扱える） ...

  1/3/2023

  の場合などに適用される
  • CAP定理

    CAP定理

    [データベース]の講義 CAP特性 C: Consistency A: Availability P: Partition Tolerance...

    1/3/2023

    で、AとPを保持している状態

• リレーショナルデータベースのACID特性

  ACID特性

  の講義 Atomicity 、中途半端にならない これがないと、多様なエラーケースが存在するから大変 Consistency は処理後も保持されている Isolation 、並列実行は直列実行と同じ結果(等価)を保証 ...

  1/3/2023

  の反対? (ネーミングが天才)

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

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

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

  • 強い一貫性が求められる場合（ACID特性

    ACID特性

    の講義 Atomicity 、中途半端にならない これがないと、多様なエラーケースが存在するから大変 Consistency は処理後も保持されている Isolation 、並列実行は直列実行と同じ結果(等価)を保証 ...

    1/3/2023

    とか)は、 = writeをされた瞬間以降のreadは絶対更新されている
  • Eventual Consisencyだと、そうはならない
  • writeのあとにreadの値が更新されるまでにラグがあってもOK

• “Quorum”: NoSQL

  NoSQL

  [データベース]の講義 定義が広い/曖昧? 1998: RDBMSからを除外したを指す用語として定義された 2009: [リレーショナルデータベース]]以外の[[データベース]を指す用語として定義された のための新しい世代の を持つ 強み データ容量が大きい（大量のデータを扱える） ...

  1/3/2023

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