用語の間違いはご容赦ください。特に、リレーショナルデータベースの用語を使用しています。
CouchDBやCassandraなど、他の多くのプロジェクトとともに、多数の永続的なKey-Valueストアがあります。
それらに対する典型的な議論は、それらが複数の行またはテーブルにわたるアトミックトランザクションを一般的に許可しないということです。一般的なアプローチでこの問題を解決できるのではないかと思います。
たとえば、一連の銀行口座の状況を考えてみましょう。ある銀行口座から別の銀行口座にお金を移動するにはどうすればよいですか？各銀行口座が行である場合、同じトランザクションの一部として2つの行を更新し、一方の値を減らし、もう一方の値を増やします。
明らかなアプローチの1つは、トランザクションを説明する別のテーブルを用意することです。次に、ある銀行口座から別の銀行口座にお金を移動するには、このテーブルに新しい行を挿入するだけです。2つの銀行口座のいずれの現在の残高も保存せず、代わりにトランザクションテーブルの適切な行をすべて合計することに依存します。ただし、これは非常に手間がかかることは容易に想像できます。銀行には1日に数百万のトランザクションがあり、個々の銀行口座には数千の「トランザクション」が関連付けられている場合があります。
基になるデータが最後に取得してから変更された場合、多数の（すべて？）Key-Valueストアがアクションを「ロールバック」します。おそらく、これを使用してアトミックトランザクションをシミュレートし、特定のフィールドがロックされていることを示すことができます。このアプローチには明らかな問題がいくつかあります。
他のアイデアはありますか？私のアプローチが単に間違っていて、新しい考え方に頭を悩ませていない可能性は十分にあります。