1

私はどちらかというと、1 つのデータベース (PostgreSQL や ElasticSearch など) を単独で使用することに慣れています。しかし、現在、私はプロトタイプアプリでミックス (PG と ES) を使用しており、ミックスに他の種類のデータベースをスローする可能性があります (例: redis)。

一部のデータを異なる方法で各データベースに永続化する必要があるとします。 コンポーネント/データベースの 1 つで障害が発生した場合、システムの一貫性をどのように維持しますか?

私が直面しているシナリオの例: PostgreSQL でのデータ更新、ElasticSearch は利用できません。この時点で、両方のデータベースを更新する必要があったため、システムに一貫性がありません。私は SQL データベースを使用しているので、トランザクションを中止するだけで、システムを以前の一貫した状態に戻すことができます。

しかし、システムの一貫性を保つ最善の方法は何でしょうか?

  • 値がすべてのデータベースで保持されていることを毎回確認しますか?
  • 故障時は元の状態に戻す？しかし、一部の NoSQL データベースにはトランザクション/ACID メカニズムがないため、以前の状態に簡単に戻すことはできません。

さらに、複数のデータベースを同期しておく必要がある場合、データベースを同期に戻すことができるように、ある種の「バージョン」メタデータ (タイムスタンプまたは自家製のインクリメント バージョン番号) を追加するなどの良い方法はありますか? （組み込みのCouchDBについては話していません！）

さらに、データベースはすべてアトミックに更新されるわけではないため、一部の部分が短期間矛盾します。アプリのビジネスにもよると思いますが、私が発生した問題やその修正方法について何か考えている人はいますか？それは難しいにちがいないし、多くの構成に依存していると思います (おそらく、実際の利点はほとんどありません)。

これは一般的なアーキテクチャの問題であると思いますが、この件に関する情報を見つけるのに苦労しています。

4

2 に答える 2

4
  1. 物事をシンプルに保ちます。
  2. 検索エンジンは遅れることがあり、遅れることがあります。あなたはそれと戦うかもしれません。あなたはそれを受け入れるかもしれません。それは結構です、そしてほとんどの場合それは受け入れられます。
  3. データを混ぜないでください。セッションに Redis を使用する場合 - 良い。データベース A のデータを B に保存しないでください。その逆も同様です。
  4. Super Important Business Data™® には、ACID と強整合性を備えた適切なデータベースを選択してください。
  5. 繰り返しますが、データを混在させないでください。
于 2014-02-20T15:52:51.280 に答える
2

1 つの製品で複数のデータベース テクノロジを使用することは、気楽な決断ではありません。使用するテクノロジーが増えるほど、開発、展開、保守、および管理においてプロジェクトが複雑になります。また、すべてのデータベース テクノロジが個々の障害点になります。つまり、妥協が必要になる場合でも、1 つのテクノロジーに固執する方が賢明な場合が多いということです。

しかし、複数の DBMS を使用する正当な (!) 理由がある場合は、それらをできるだけ分離するようにしてください。複数のデータベースにまたがる関連データを配置することは避けてください。可能であれば、動作するために複数の DBMS を必要とする機能はありません (できれば、DBMS の障害は、それを使用する機能にのみ影響します)。冗長なデータを 2 つの異なる DBMS に格納することも避ける必要があります。

複数の DBMS にまたがる冗長性と関係が避けられない場合は、1 つのシステムを信頼できる唯一の情報源(一貫性に関して最も信頼できるものであることが望ましい) にすることを決定する必要があります。システム間に不整合がある場合は、データを SSOT と同期することで解決する必要があります。

于 2014-02-19T18:25:01.770 に答える