一貫したバックエンドとUX：何が問題になるのでしょうか？-CSSチュートリアル-php.cn

前の記事では、（最終的な一貫性とは対照的に）強い一貫性について説明します。この記事はシリーズの第2部であり、強い一貫性の欠如により、優れたエンドユーザーエクスペリエンスを提供することがどのように困難になるか、それがどのように深刻なエンジニアリングのオーバーヘッドにつながる可能性があるか、そしてそれがあなたを攻撃に対して脆弱にする方法を説明します。このセクションは、さまざまなデータベースの例外を説明し、いくつかの例のシナリオを使用し、どのタイプのデータベースが各例外を受けやすいかを簡単に説明するため、長くなります。

ユーザーエクスペリエンスは、あらゆるアプリケーションの成功の原因であり、一貫性のないバックエンドに依存することで、優れたエクスペリエンスを提供するという課題が高まります。さらに重要なことは、一貫性のないデータに加えてアプリケーションロジックを構築すると、脆弱性につながる可能性があります。 1つの論文は、このタイプの攻撃を「Acidrain」と呼んでいます。彼らは、最も人気のある自己ホストの電子商取引アプリケーションの12の12を調査し、少なくとも22の可能な深刻な攻撃を発見しました。 1つのウェブサイトはビットコインウォレットサービスで、これらの攻撃のためにシャットダウンする必要がありました。 100％酸ではない分散データベースを選択すると、問題があります。前の例が説明しているように、エンジニアは、誤解、不明確に定義された用語、および急進的なマーケティングのために、特定のデータベースによって提供される保証を決定することは困難です。

なんと困っていますか？アプリケーションは、アカウントの残高エラー、受信していないユーザーの報酬、トランザクションの実行、故障したメッセージ、または応答アプリケーションルールの違反などの問題が発生する場合があります。分散データベースが必要な理由とそれらが難しい理由についての簡単な紹介については、最初の投稿またはこの素晴らしいビデオの説明をご覧ください。要するに、分散データベースは、スケーラビリティ、遅延、可用性のために、複数の場所にデータのコピーを保持するデータベースです。

これらの4つの潜在的な問題（およびその他）をカバーし、ゲーム開発の例で説明します。ゲーム開発は複雑であり、これらの開発者は、実際の生活の深刻な問題に非常によく似た多くの問題に直面しています。ゲームには、トレーディングシステム、メッセージシステム、条件を満たす必要がある報酬などがあります。ゲーマーは、物事がうまくいかないか、間違っているかどうかを覚えています。ゲームでは、ユーザーエクスペリエンスが非常に重要であるため、ゲーム開発者はしばしば、システムが過失に耐えるように大きなプレッシャーに直面します。

準備ができて？最初の潜在的な問題に飛び込みましょう！

1。古い読書

古い読み取りとは、古いデータを返す読み取りを指します。つまり、返された値は最新の書き込みに基づいて更新されていません。レプリカでスケールアップする従来のデータベースを含む多くの分散データベース（これらのデータベースの仕組みを理解するためにパート1を読んでください）は、古い読み物の問題を経験します。

エンドユーザーへの影響

まず、古い読み取りはエンドユーザーに影響します。そして、これは単一の影響ではありません。

イライラする経験と不公平な利点

ゲーム内の2人のユーザーが金貨のある宝箱に遭遇すると想像してください。最初のユーザーは1つのデータベースサーバーからデータを受信し、2番目のユーザーは2番目のデータベースサーバーに接続します。一連のイベントは次のとおりです。

ユーザー1（データベースサーバー1を介して）は、宝箱を見て開き、金貨を取り除きます。
ユーザー2（データベースサーバー2を介して）は、完全な宝箱を見て、それを開き、失敗します。
ユーザー2はまだ完全な宝箱を見ており、なぜ失敗するのか理解していません。

これは小さな問題のように思えるかもしれませんが、結果は2番目のプレイヤーエクスペリエンスがイライラすることです。彼は不利な立場にあるだけでなく、ゲーム内の状況をよく見ているが、そうではないようです。次に、古い測定値に対して行動を起こしているプレイヤーの例を見てみましょう！

耐久性のある読み取りは、繰り返し書くことにつながります

ゲーム内のキャラクターが店でシールドや剣を購入しようとしていることを想像してください。複数の場所にデータが含まれており、インテリジェントシステムが一貫性を提供しない場合、1つのノードには他のノードよりも古いデータが含まれます。この場合、ユーザーはアイテムを購入し（最初のノードに連絡）、インベントリを確認し（2番目のノードに連絡してください）、アイテムが存在しないことを確認できます。ユーザーは混乱している可能性があり、トランザクションが成功していないと考える場合があります。この場合、ほとんどの人は何をしますか？まあ、彼らはもう一度アイテムを買おうとします。 2番目のノードが追いつくと、ユーザーはコピーを購入し、コピーが追いつくと、彼は突然、自分がお金を使い果たし、各アイテムの2つの部分を持っていることに気付きます。彼は私たちのゲームが壊れていると考えています。

この場合、ユーザーは自分が費やしたくないリソースを費やします。このようなデータベースの上にメールクライアントを書くと、ユーザーは電子メールを送信してからブラウザを更新しようとする可能性がありますが、送信した電子メールを取得できないため、再度送信されます。優れたユーザーエクスペリエンスを提供し、そのようなシステムの上に安全な取引（銀行取引など）を実装することは非常に困難です。

開発者への影響

エンコーディングするときは、常に何か（まだ）存在し、それに応じてエンコードすることを期待する必要があります。読み取りが最終的に一貫しており、ユーザーはアプリケーションに問題がある可能性が高い場合、障害コードを書くことが非常に困難になります。読み取りが最終的に一貫している場合、これらの質問はそれらを調査する前に消えます。基本的に、あなたは幽霊を追いかけることになります。開発者は、通常、問題に気付くのに時間がかかるため、最終的に一貫したデータベースまたは配布方法を選択することがよくあります。その後、アプリケーションに問題が発生したら、従来のデータベースの上に創造的なソリューション（1、2）を作成して、古い読み取りを修正しようとします。そのようなガイドがたくさんあり、Cassandraのようなデータベースがこれらの問題が現実であり、あなたが思っているよりも頻繁に生産システムに問題を引き起こすことを示すいくつかの一貫性機能を実装しているという事実があります。一貫性のために構築されていないシステムの上に構築されたカスタムソリューションは、複雑で脆弱です。箱から強い一貫性を提供するデータベースがあるのに、なぜ誰かがそのようなトラブルを経験するのでしょうか？

この例外を示すデータベース

プライマリ読み取りレプリケーションを使用する従来のデータベース（PostgreSQL、MySQL、SQL Serverなど）は、通常、古い読み取り問題が発生します。多くの新しい分散データベースも、古い読み取りに対する保護なしに、最終的に、または言い換えれば、最終的に一貫しています。これは、これが拡大に必要であるという開発者コミュニティに対する強い信念によるものです。これが最も有名なデータベースが始まった方法ですが、ユーザーがこの例外に対処するのに苦労していることを認識し、それを回避するための追加の措置を提供しています。効率的で一貫性を提供するように設計されていない古いデータベースまたはデータベース（Cassandra、CouchDB、DynamoDBなど）は、最終的にデフォルトで一貫しています。 RIAKなどの他のアプローチも最終的に一貫していますが、時代遅れの値の可能性を減らすために紛争解決システムを実装することにより、異なるパスが取られます。ただし、紛争解決は絶対確実ではないため、これはデータセキュリティを保証するものではありません。

2。紛失した書き込み

分散データベースの分野では、執筆が同時に発生するときに重要な選択を行う必要があります。 1つのオプション（安全なオプション）は、すべてのデータベースノードがこれらの書き込みの順序に同意することを確認することです。これは、同期クロック（特定のハードウェアが必要です）またはCalvinのようなクロックに依存しないインテリジェントアルゴリズムを必要とするため、些細なこととはほど遠いものです。 2番目の安全性の低いオプションは、各ノードがローカルで書き込みできるようにし、後で競合の処理方法を決定することです。データベースに2番目のオプションを選択すると、書き込みが失われる場合があります。

エンドユーザーへの影響

ゲーム内の2つの取引を考慮すると、11個の金貨から始めて2つのアイテムを購入します。最初に、5枚の金貨用の剣を購入し、次に5枚の金貨用のシールドを購入し、両方のトランザクションが分散データベースの異なるノードに向けられます。各ノードは値を読み取り、この場合、両方のノードでまだ11です。どちらのノードも、複製を知らないため、結果（11-5）として6を記述することを決定します。 2番目のトランザクションでは、最初のトランザクションが書かれた値を見ていないため、プレイヤーは最終的に10コインではなく合計5つのコインで剣とシールドを購入します。ユーザーにとっては良いことですが、システムには悪いです！この動作を改善するために、分散データベースにはいくつかの戦略があります。一部の戦略は他のデータベースよりも優れています。

解決戦略には、「Last Write Win」（LWW）または「Longestバージョンの歴史」（LVH）の勝利が含まれます。 LWWは長い間Cassandraのポリシーでしたが、違った設定を行わないと、デフォルトの動作です。

前の例にLWW紛争解決を適用すると、プレイヤーにはまだ6つの金貨が残っていますが、1つのアイテムのみが購入されます。データベースが在庫に存在すると識別していなくても、アプリが2番目のアイテムの購入を確認したため、ユーザーエクスペリエンスが悪いことです。

予測不可能なセキュリティ

ご想像のとおり、このようなシステムの上にセキュリティルールを書くことは安全ではありません。多くのアプリケーションは、ユーザーがリソースにアクセスできるかどうかを判断するために、バックエンドからの複雑なセキュリティルール（または可能な限り直接）に依存しています。これらのルールが、確かに更新されていない古いデータに基づいている場合、どうすれば違反がないことを保証できますか？ PAASアプリケーションのユーザーが管理者に電話して、「このパブリックグループをプライベートにして、内部データのために再利用できるようにすることができますか？」と尋ねます。管理者はアクションを適用し、それが完了したことを彼に伝えます。ただし、管理者とユーザーはさまざまなノード上にある可能性があるため、ユーザーは技術的にまだ公開されているグループに機密データの追加を開始する場合があります。

開発者への影響

ユーザーの問題のデバッグは、書き込みが失われると悪夢になります。彼があなたのアプリでデータを失ったと報告しているユーザーが、返信する時間を得るのに1日かかったと想像してみてください。問題がデータベースによって引き起こされているか、アプリケーションロジックの故障によって引き起こされているかどうかをどのように確認しますか？ FaunadbやDatomicなどのデータ履歴を追跡できるデータベースでは、過去に戻ってデータがどのように操作されたかを確認できます。ただし、これらのデータベースのいずれも、欠落した書き込みの影響を受けるものではなく、実際にそのような例外の影響を受けやすいデータベースには、通常、時間rewind機能がありません。

簡単に紛失したデータベース

競合回避の代わりに競合解決を使用するすべてのデータベースは、書き込みを失います。 Cassandraとdynamodbは、最後の書き込み勝利（LWW）をデフォルトとして使用します。 Mongodbは以前はLWWを使用していましたが、それ以来放棄しました。 MySQLなどの従来のデータベースのマスターマスター配布方法は、異なる紛争解決戦略を提供します。一貫性のために構築されていない多くの分散データベースは、書き込みを失います。 Riakの最も簡単な紛争解決はLWWを搭載していますが、よりスマートなシステムも可能にします。しかし、スマートシステムを使用しても、競合を解決する明白な方法がない場合があります。 RiakとCouchDBは、クライアントまたはアプリケーションに正しい書き込みを選択する責任を引き渡し、保持するバージョンを手動で選択できるようにします。

分布は複雑であるため、ほとんどのデータベースは不完全なアルゴリズムを使用しているため、ノードがクラッシュまたはネットワークパーティションが表示されると、欠落した書き込みが多くのデータベースでしばしば発生します。 MongoDB（Write（書き込みはノードに行く）を配布していない）があっても、書き込み直後にノードがクラッシュするまれな場合に、書き込み競合が発生する可能性があります。

3。逸脱を書きます

書き込みバイアスは、データベースベンダーがスナップショットの一貫性を呼び出す保証タイプで起こる可能性があります。スナップショットの一貫性では、トランザクションがトランザクションの開始時に撮影されたスナップショットから読み取られます。スナップショットの一貫性は、多くの例外を防ぎます。実際、多くの人々は、紙（PDF）がそうではないことを証明するように見えるまで、それが完全に安全であると考えています。したがって、開発者がいくつかの保証が十分ではない理由を理解するのに苦労していることは驚くことではありません。

スナップショットの一貫性で機能しないものを議論する前に、最初にどの作品を話し合いましょう。それぞれの活力が4つの心で構成されている騎士と魔術師の間に戦いがあるとします。

キャラクターが攻撃されると、トランザクションは、削除されたハートの数を計算する関数です。

 <code>damageCharacter(character, damage) { character.hearts = character.hearts - damage character.dead = isCharacterDead(character) }</code>

ログイン後にコピー

そして、各攻撃の後、別のISCharacterDead関数も実行され、キャラクターが心を持っているかどうかを確認します。

 <code>isCharacterDead(character) { if (character.hearts </code>

ログイン後にコピー

簡単な場合、騎士の攻撃は魔術師から3つの心を取り除き、魔術師の呪文は騎士から4つの心を取り除き、自分の健康を4つに取り戻します。あるトランザクションが次々と実行される場合、2つのトランザクションはほとんどのデータベースで正しく動作します。

しかし、ナイトの攻撃である3回目のトランザクションを追加した場合、それはメイジの呪文と同時に実行されますか？

騎士は死んでいますか、魔術師はまだ生きていますか？

この混乱に対処するために、スナップショットの一貫性システムは、しばしば「First Committer Wins」と呼ばれるルールを実装します。トランザクションは、別のトランザクションが同じ行に書き込まれていない場合にのみ終了できます。そうしないと、ロールバックされます。この例では、両方のトランザクションが同じライン（魔術師の健康価値）に書き込もうとするため、命を奪う呪文のみが機能し、ナイトの2番目の攻撃がロールバックされます。最終結果は、前の例と同じです：死んだ騎士と完全な健康の魔術師。

ただし、MySQLやInnoDBなどの一部のデータベースでは、Snapshot Isolationの一部として「最初のコミッター勝利」を考慮していません。この場合、私たちは紛失した書き込みを持っています：魔術師は今死んでいますが、彼は騎士の攻撃が有効になる前に人生から健康ポイントを得るべきです。（不明確な用語とゆるい説明について言及しましたよね？）

「First Committer Wins」ルールを含むスナップショットの一貫性は、長い間良い解決策と考えられてきたため、驚くことではありません。これは依然としてPostgreSQL、Oracle、およびSQL Serverの方法ですが、それらはすべて異なる名前を持っています。 PostgreSQLはこの保証を「繰り返し可能」と呼び、Oracleはそれを「シリアル化可能」と呼びます（定義では間違っています）、SQL Serverはそれを「スナップショット分離」と呼びます。人々がこの用語の森で迷子になるのも不思議ではありません。期待どおりに機能しない例を見てみましょう！

エンドユーザーへの影響

次の戦いは2つの軍隊の間で行われ、軍隊のすべての性格が死んだ場合、1つの軍隊が死んでいると見なされます。

 isarmydead（陸軍）{
  if（すべてのキャラクターが死んでいる）{trueを返す}
  else {return false}
}

ログイン後にコピー

各攻撃の後、次の関数がキャラクターが死ぬかどうかを決定し、上記の関数を実行して軍隊が死ぬかどうかを確認します。

 damagearmycharacter（陸軍、性格、損傷）{
  character.hearts = character.hearts-ダメージ
  character.dead = ischaracterdead（文字）
  ArmyDead = isarmydead（Army）
  if（Army.Dead！= ArmyDead）{
    Army.Dead = ArmyDead
  }
}

ログイン後にコピー

まず、キャラクターの心臓は、それがかかる損傷によって減少します。次に、各キャラクターに健康がないかどうかを確認することにより、陸軍が死んでいることを確認します。次に、陸軍の状態が変わった場合、陸軍の「死」ブールンを更新します。

3つの魔法がそれぞれ1回攻撃され、3つの「生命吸引」が重要になりました。スナップショットはトランザクションの開始時に行われ、すべてのトランザクションが同時に開始されるため、スナップショットは同じです。各トランザクションには、すべての騎士がまだ完全な健康状態を持っているデータのコピーがあります。

最初の「人生を吸収する」トランザクションがどのように解決されたかを見てみましょう。このトランザクションでは、Mage1がKnight1を攻撃し、Knightは4つの健康ポイントを失い、攻撃者はすべての健康ポイントを回復します。この問題は、ナイツ軍が死んでいないことを決定しました。なぜなら、2人の騎士がまだ完全な健康状態を持ち、1人の騎士が死亡したスナップショットしか見えなかったからです。他の2つのトランザクションは他の魔術師と騎士に作用しますが、同様の方法で実行されます。これらの各トランザクションには、最初はデータのコピーに3人の生きている騎士があり、1人の騎士のみが死んでいると見られています。したがって、すべての問題は、騎士団の軍隊がまだ生きていると判断します。

すべてのトランザクションが完了すると、騎士団はどれも生きていませんが、陸軍が死んでいるかどうかを示しているブール値は、まだ虚偽に設定されています。なぜ？スナップショットをとるとき、騎士は死んでいないからです。したがって、各取引は自分の騎士が死ぬのを見ていますが、陸軍の他の騎士団を知りません。これは私たちのシステムの例外ですが（書き込みバイアスと呼ばれます）、それぞれが異なる役割に書き込み、陸軍への書き込みが変わったことがないため、書き込みは合格しました。素晴らしい、私たちは今ゴーストアーミーを持っています！

開発者への影響

データ品質

ユーザーが一意の名前を持っていることを確認したい場合はどうなりますか？ユーザーが作成するトランザクションは、名前が存在するかどうかを確認します。存在しない場合は、その名前を使用して新しいユーザーに書き込みます。ただし、2人のユーザーが同じ名前で登録しようとする場合、ユーザーが異なる行に書かれているため、競合がないため、スナップショットは何も気付かないでしょう。これで、システム上に同じ名前の2人のユーザーがいます。

他の多くの例外の例は、バイアスを書き込むために表示される場合があります。興味があれば、Martin Kleppmanの本デザインデータ集約型アプリケーションでは、これをより詳細に説明しています。

ロールバックを避けるために、さまざまな方法でコードを作成します

さて、攻撃が軍隊における特定の役割をターゲットにしていない別のアプローチを考えてみましょう。この場合、データベースは、最初にどのナイトを攻撃するかを選択する責任があります。

 Damagearmy（軍隊、損害）{
  文字= getFirsThealthyCharacter（ナイト）
  character.hearts = character.hearts-ダメージ
  character.dead = ischaracterdead（文字）
  // ...
}

ログイン後にコピー

前の例のように並行して複数の攻撃を実行すると、GetFirsThealthyCharacterは常に同じ騎士をターゲットにします。これにより、複数のトランザクションが同じ行に書き込まれます。これは、「最初の提出者Wins」ルールによってブロックされ、他の2つの攻撃をロールバックします。例外を防ぎますが、開発者はこれらの問題を理解し、それらの周りに創造的にコードを書く必要があります。しかし、データベースがあなたのためにこれを箱から出してしまうなら、それは簡単ではないでしょうか？

逸脱を記述する傾向があるデータベース

シリアル化ではなくスナップショットの分離を提供するデータベースは、書き込みバイアスを発生させる可能性があります。データベースとその分離レベルの概要については、この記事を参照してください。

4。注文の執筆

失われた書き込みや古い読み取りを避けるために、分散データベースの目標はいわゆる「強い一貫性」です。データベースは、グローバルな順序（安全な選択）に同意することを選択するか、競合を解決することを決定することができると述べました（失われた書き込みをもたらす選択）。グローバルな秩序を決定する場合、剣と盾は並行して購入されますが、最終結果はまるで剣を購入してからシールドを購入したかのように振る舞うはずです。これは、データベース操作を線形化できるため、一般に「線形化」として知られています。線形化は、データセキュリティを確保するためのゴールドスタンダードです。

さまざまなベンダーが異なる分離レベルを提供していますが、ここで比較できます。よく表示される1つの用語は、シリアル化です。これは、強力な一貫性（または線形化）のわずかに厳格なバージョンです。シリアル化はすでに非常に強力であり、ほとんどの例外をカバーしていますが、書き込みの並べ替えによって引き起こされる非常にわずかな例外の余地を残しています。この場合、データベースは、トランザクションがコミットされていても、注文を自由に切り替えることができます。簡単に言えば、線形化はシリアル化の順序と保証されています。データベースにこの保証された順序がない場合、アプリケーションはオーダーオーダーワタリの影響を受けやすくなります。

エンドユーザーへの影響

対話の並べ替え

エラーのために誰かが2番目のメッセージを送信した場合、会話は混乱する方法でソートすることができます。

ユーザー操作は並べ替えます

プレーヤーには11個の金貨があり、所有している金貨の量を積極的にチェックせずに重要性の順にアイテムを購入する場合、データベースはこれらの発注書を再注文できます。彼が十分なお金を持っていなければ、彼は最初に最も低いアイテムを買うことができたでしょう。

この場合、十分な金があることを確認するためのデータベースチェックがあります。銀行がゼロを下回っているときに当座貸越の料金を請求するのと同じように、ゼロ以下の口座を持っているのに十分なお金がないと想像してください。 3つのアイテムすべてを購入するのに十分なお金があることを確認するために、1つのアイテムをすばやく販売できます。ただし、残高を増やすように設計された販売は、トランザクションリストの終わりまで並べ替えられる場合があります。これが銀行である場合、あなたはおそらくあなたが決して負担してはならない費用を負担するでしょう。

予測不可能なセキュリティ

セキュリティ設定を構成した後、ユーザーはこれらの設定が今後のすべてのアクションに適用されることを期待していますが、ユーザーが異なるチャネルを通じて互いに話し合うと問題が発生する可能性があります。私たちが議論した例を覚えておいてください、管理者はグループをプライベートにしたいユーザーと話し、それに機密データを追加します。これはシリアル化可能性を提供するデータベースで発生する可能性がありますが、この状況の時間枠は小さくなりますが、これは、ユーザーの操作の後まで管理者の操作が完了しない可能性があるために発生する可能性があります。ユーザーがさまざまなチャネルを通信し、データベースがリアルタイムでソートされることを期待すると、事態が悪くなります。

この例外は、ロードバランスのためにユーザーが別のノードにリダイレクトされた場合にも発生します。この場合、2つの連続した操作が異なるノードで終了し、並べ替えられる場合があります。少女が視聴許可が限られているFacebookグループに両親を追加し、春休みの写真を投稿すると、これらの画像は引き続き両親のフィードに表示される場合があります。

別の例では、自動化された取引ボットには、最高の購入価格、支出制限、焦点を当てる株のリストなどの設定があります。ユーザーがボットが購入する株式のリストを変更してから支出の制限を変更すると、トランザクションが再注文され、ボットが古い株式の新しく割り当てられた予算を使用した場合、彼は満足しません。

開発者への影響

脆弱性

一部の脆弱性は、トランザクションの潜在的な逆転に依存しています。ゲーマーが1,000個の金貨を持っているとトロフィーを受け取ると想像してください。彼は本当にこのトロフィーを望んでいます。このゲームでは、金貨の複数のコンテナ（ストレージやキャリー（在庫）などの複数のコンテナを追加することで、プレイヤーが持っている金貨の数が計算されます。プレイヤーがストレージと在庫の間ですぐにお金を交換すると、実際にシステムをcheすることができます。

次の図では、2番目のプレーヤーは、ストレージとインベントリ間の資金の譲渡が異なるトランザクションで発生するようにするために犯罪パートナーとして機能し、それにより、これらのトランザクションが異なるノードにルーティングされる可能性を高めます。現実世界のより深刻な例は、サードパーティのアカウントを使用してお金を譲渡する銀行です。銀行は、さまざまな取引が異なるノードに送られ、ソートするのに十分な時間がないため、誰かがローンの資格があるかどうかを誤って計算する場合があります。

オーダーオーバーライティングが発生しやすいデータベース

線形化を提供しないデータベースは、書き込みバイアスを経験する場合があります。データベースが線形化を提供する概要については、この記事を参照してください。ネタバレ：多くはありません。

一貫性が制限されている場合、すべての例外が返される場合があります

最終的に議論される強い一貫性の緩和の1つは、特定の範囲内にのみであることを確認することです。典型的なスコープは、データセンター領域、パーティション、ノード、コレクション、または行です。これらのタイプの境界を強力な一貫性に課すデータベースの上でプログラミングをしている場合は、誤ってパンドラの箱を再び開かないように、これらの境界を覚えておく必要があります。

以下は一貫性の例ですが、1つのセット内にあることが保証されています。次の例には、3つのセットが含まれています。1つはプレーヤー用です。1つは鍛冶屋用（つまり、プレイヤーのアイテムを修理する鍛冶屋）、もう1つはアイテム用です。各プレイヤーと各鍛冶屋には、アイテムコレクションのアイテムを指すIDリストがあります。

2人のプレーヤー（たとえば、BrechtからRobertまで）の間でシールドを交換したい場合、あなたはまだコレクションにいるのですべてが問題ないので、あなたのトランザクションはまだ保証された一貫性の範囲内にあります。しかし、ロバートの剣が鍛冶屋で修理され、彼がそれを取り戻したかったらどうでしょうか？その後、トランザクションは2つのセット、つまり鍛冶屋のセットとプレイヤーのセットにまたがっており、キャンセルされることが保証されています。この制限は通常、MongoDBなどのドキュメントデータベースにあります。次に、制限に関する創造的なソリューションを見つけるためにプログラミング方法を変更する必要があります。たとえば、アイテムの場所をアイテム自体にエンコードできます。

もちろん、実際のゲームは複雑です。アイテムをプレイヤーが所有できるように、フロアにアイテムをドロップしたり、市場に配置したりできるようにすることもできますが、必ずしもプレーヤーの在庫にあるわけではありません。物事がより複雑になると、これらの回避策はテクノロジーの深さを大幅に増加させ、データベースの保証された範囲内にとどまるようにコーディングする方法を変更します。

結論は

データベースの動作が期待と一致しないときに発生する可能性のあるさまざまな問題の例を見てきました。一目見たときは些細な状況に見えるかもしれませんが、それらはすべて、特にシステムが拡大されている場合、開発者の生産性に大きな影響を与えます。さらに重要なことは、予測不可能なセキュリティの脆弱性に対してあなたを脆弱にしておくことができます。

一貫性のいくつかのレベルについて説明しましたが、これらの例を見たので、それらをまとめてみましょう。

また、これらの正しさのそれぞれに境界がある場合があることを忘れないでください。

最後に、いくつかの例外と一貫性の保証しか言及していないことを認識してください。実際にはそれ以上あります。興味のある読者には、Martin Kleppmanの設計データ集約型アプリケーションを強くお勧めします。

制限なしで強力な一貫性データベースを選択している限り、私たちはもはや気にする必要がない時代に住んでいます。 Calvin（Faunadb）やSpanner（Google Spanner、FoundationDB）などの新しいアプローチの出現のおかげで、それぞれの場合に期待どおりに非常に低いレイテンシを提供し、動作できるマルチレジオンの分散データベースがあります。それでは、なぜあなたはまだ自分自身を足で撃って、これらの保証を提供しないデータベースを選択する危険を冒すのでしょうか？

このシリーズの次の記事では、開発者エクスペリエンスへの影響について説明します。一貫性が重要であると開発者に納得させるのが難しいのはなぜですか？ネタバレ：ほとんどの人は、必要性を確認するために直接体験する必要があります。しかし、それについて考えてみてください：「エラーがある場合、アプリケーションエラー、またはデータエラーですか？どうやって知っていますか？」データベースの制限がエラーまたはユーザーエクスペリエンスの不良として現れたら、データベースの制限に対処する必要があります。これにより、拡張できない非効率的な接着コードにつながる可能性があります。もちろん、それまでにあなたはたくさんのお金を投資していて、それが手遅れであることに気づきました。