現在のプロジェクトで noSQL ソリューションを検討していますが、これらのデータベースの多くにある「結果整合性」条項については躊躇しています。結果整合性は、レプリケーションが遅れる mySQL データベースを扱う場合とは異なりますか? 過去に遅延レプリケーションで使用した 1 つの解決策は、データの一貫性がすぐに必要な場合にマスターから読み取ることです。
しかし、リレーショナル データベースが強力なデータ整合性を主張する理由について、私は混乱しています。トランザクションを使用する必要があると思います。これにより、強い一貫性が得られます。では、mySQL のレプリケーションが遅れる可能性があると想定してアプリケーションを作成することは良い方法でしょうか?
ACID で使用される意味での一貫性とは、変更の前後ですべての制約が満たされることを意味します。システムが一貫性のないデータを読み取れないことを保証する場合、たとえば、子行が存在しない親行を参照しているデータや、トランザクションの半分が適用されているが、残りの半分はまだ適用されていません (教科書の例では、1 つの銀行口座から引き落とされていますが、受取人の銀行口座にはまだ入金されていません)。
MySQL のレプリケーションは、デフォルトでは非同期、またはせいぜい「半同期」です。確かに、どちらの場合でも遅れます。実際、マスターはトランザクションがコミットされるまでバイナリ ログに変更を書き込まないため、レプリケーション レプリカは常に少なくとも数分の 1 遅れています。その後、レプリカはバイナリ ログをダウンロードしてイベントをリレーする必要があります。
しかし、変更はまだアトミックです。部分的に変更されたデータを読み取ることはできません。コミットされた変更を読み取る (すべての制約が満たされている場合) か、変更がまだコミットされていない場合 (トランザクションが開始される前のデータの状態が表示される場合) のいずれかです。
そのため、遅延のあるレプリケーション システムで一時的に古いデータを読み取ることはできますが、一貫性のないデータを読み取ることはありません。
一方、「結果整合性」システムでは、部分的に更新されたデータを読み取る可能性があります。この場合、1 つのアカウントは引き落とされ、2 番目のアカウントはまだ入金されていません。したがって、矛盾したデータを見ることができます。
アプリケーションが完全に最新のデータを必要とする場合は、レプリカからの読み取りに注意する必要があるかもしれません。アプリケーションごとにレプリケーション ラグの許容範囲が異なります。実際、1 つのアプリケーション内でもクエリごとにラグの許容範囲が異なります。これについてプレゼンテーションを行いました: MySQL と PHP の読み取り/書き込み分割(Percona webinar 2013)
完全を期すために、CAP定理の観点から質問にも答えます。ああ、ACID の一貫性は CAP の一貫性と同じではありません。
すべての読み取りが最新の書き込みまたはエラーを受け取るという CAP 定理の一貫性 (これは、線形化可能性、別名、強整合性、またはアトミック整合性と呼ばれます) に関して、MySQL は非同期レプリケーションを使用するため、デフォルトでは強整合性ではありません。そのため、グループ内の一部のノードには最新の書き込みがあり、一部のノードにはまだ書き込みがない期間があります。
また、MySQL のバージョンが 8.0.14 以降の場合、group_replication_consistency は構成可能ですが、それでもデフォルト値は EVENTUAL です (これは構成可能ではなく、ほとんどのアプリが実行されていると思われる以前の MySQL バージョンのデフォルト値です)。詳細: https://dev.mysql.com/doc/refman/8.0/en/group-replication-configuring-consistency-guarantees.html
さらに、MySQL Cluster を使用している場合 (これは別の製品/テクノロジであり、クラスターと呼んでいるのがわかりにくいと思います)、MySQL のドキュメント自体には、最終的な整合性のみを保証すると記載されています。詳細: https://dev.mysql.com/doc/mysql-cluster-manager/1.4/en/mcm-eventual-consistency.html
したがって、これは結果整合性のあるシステムであると言っても過言ではありません。そして、非同期的に複製されるすべてのシステムは、定義上、最終的に一貫性があります。