これに対する多くの秘訣はあなたの正確な要件を見つけることです、そしてあなたはまだかなり曖昧に聞こえます。このような操作をサポートする必要がありますか?
- キーKを値Vに更新します。
- キーKのやや最近の値を調べます。
結果整合性が必要だとおっしゃいました。したがって、1回の更新を行うと、最終的にはどこにでも複製されます。ほぼ同時に2つの更新を行う場合、どちらが勝つかを気にしますか?1つのレプリカが更新が正常に完了したことを報告した場合、そのレプリカがすぐに一時的にクラッシュした場合に値が失われる可能性がありますか?または、そのレプリカが永久に破壊された場合はどうなりますか?
やや最近の精度はどれくらいですか?ネットスプリットなどがある場合、ルックアップは非常に古い結果を返すか、単に失敗する可能性があります。どちらが気になりますか?
次のようなより洗練された操作をサポートする必要がありますか...
- キーKの絶対最新値を取得しますか?
- 最新の値が現在Vである場合、キーKの値を値V'に更新しますか?
厳格な信頼性、遅延、および/または帯域幅の要件がありますか?あなたのレプリカはどれくらい離れていますか/間のネットワークはどれくらい良いですか?これは、すべての更新、さらにはすべてのルックアップでレプリカ間通信を行うことができる場合に影響します。または、ローカルレプリカがダウンしているように見える場合は、リモートレプリカへの操作をフェイルオーバーできる/フェイルオーバーする必要がある場合でも。
ここでのあなたの答えに応じて、私はあなたの要件を満たすかもしれないいくつかの異なるスキームで働きました。それらにはいくつかの可能なバリエーションがあります。
- 最も簡単なことは、アプリケーションが常にローカルレプリカと通信するようにすることです。タイムスタンプ値をレプリカし(NTP同期クロックを使用)、非同期レプリケーションの場合にのみ相互に通信します。最高のタイムスタンプがレプリケーションで優先されます。もちろん、2つの異なるレプリカ上のアプリケーションがそれぞれほぼ同時に読み取り/変更/書き込みを行う場合、変更の1つが簡単に失われる可能性があります。(実際、条件付き更新スキームがない場合、同じレプリカでのほぼ同時の変更についても同じことが言えます。)レプリカが永続的に失敗すると、最近の更新が失われる可能性があります。これは多かれ少なかれBigtableの組み込みレプリケーションが行うことです。あなたがリンクした論文では、それは「楽観的-マルチマスター」ブランチですが、いくつかの更新を失うことをあまり気にしないことで、彼らが示唆するよりも簡単になります。
- 一部のデータベースはPaxosアルゴリズムを使用しています(たとえば、ここで「インターネット規模のシングルサインオンのデータ管理」を参照してください)。より魅力的なことを可能にするために。各レプリカはそれがどれだけ遅れているかを知ることができるので、「1分以内の値を教えてください」または「絶対的な最新の値を教えてください」と言うことができます。レプリカのクォーラムがそれを受け入れるまで更新は完了したとは見なされないため、「絶対最新値を教えてください」は、別の更新が発生するまで常にその値を返します。前述の条件付き更新操作を実行して、同時ライターが互いに踏みにじるのを防ぐことができます。更新はクォーラムに同期的に複製されるため、これはその作成者によって定義された楽観的または悲観的なカテゴリにうまく適合しないようですが、最新のPaxosラウンドで投票しなかったレプリカはまだいくつかのクエリに答えることができる可能性があります。ただし、スキームは非常に複雑になる可能性があります...