I love eventual consistency but…
http://perspectives.mvdirona.com/2010/02/24/ILoveEventualConsistencyBut.aspx
I love eventual consistency but there are some applications that are much easier to implement with strong consistency. Many like eventual consistency because it allows us to scale-out nearly without bound but it does come with a cost in programming model complexity. For example, assume your program needs to assign work order numbers uniquely and without gaps in the sequence. Eventual consistency makes this type of application difficult to write.
私はイベンチュアル･コンシステンシーが好きだが、ストロング･コンシステンシーを用いて実装する方が、ずっと容易なアプリケーションもある。 多くの人々がイベンチュアル･コンシステンシーを好む理由は、ほとんど無限のスケールアウトを実現する点にあるが、複雑なプログラミング･モデルというコストを伴なう。たとえば、プログラムに対して、ユニークな処理順序を割り当て、そのシーケンスからギャップを排除する必要があると想定してほしい。この種のアプリケーションを、イベンチュアル･コンシステンシーを用いて書くことは難しくなる。
Applications built upon eventually consistent stores have to be prepared to deal with update anomalies like lost updates. For example, assume there is an update at time T1 where a given attribute is set to 2. Later, at time T2, the same attribute is set to a value of 3. What will the value of this attribute be at a subsequent time T3? Unfortunately, the answer is we’re not sure. If T1 and T2 are well separated in time, it will almost certainly be 3. But it might be 2. And it is conceivable that it could be some value other than 2 or 3 even if there have been no subsequent updates. Coding to eventual consistency is not the easiest thing in the world. For many applications its fine and, with care, most applications can be written correctly on an eventually consistent model. But it is often more difficult.
イベンチュアル･コンシステンシーなデータ･ストア上に構築されたアプリケーションに対しては、失われたアップデートとも言える、変則的なアップデートを取り扱うための準備が必要だ。 たとえば、前提となる属性が２にセットされている状況で、時刻（T1）にアップデートすると想定する。その後に、時刻（T2）で、同じ属性値を３にセットする。この場合、時刻（T3）における属性値はどうなるだろうか？残念なことに、明確な答えは無い。もし T1 と T2 の間が長ければ、ほとんどのケースにおいて値は ３になるだろう。しかし、2 の場合もある。 そして、次のアップデートが無かったとしても、２と 3 以外の値になることすら想像できる。 イベンチュアル･コンシステンシーのコーディングは、この世で最も容易なものというわけではない。ただし、注意深く行えば、それは多くのアプリケーションにとって適したものとなる。 また、大半のアプリケーションは、イベンチュアル･コンシステント･モデルを用いて、正確に記述することができる。ただし、それは多くのケースで、難しいものとなる。
What I’ve learned over the years is that strong consistency, if done well, can scale to very high levels. The trick is implementing it well. The naïve approach to achieve full consistency is to route all updates through a single master server but clearly this won’t scale. Instead divide the update space into a large number of partitions, each with its own master. That scales but there is still a tension between the number of partitions and the cost of maintaining many partitions and avoiding hot spots. The obvious way to avoid hot spots is to use a large number of partitions but this increases partition management overhead. The right answer is to be able to dynamically repartition to maintain a sufficient number of partitions and to be able to adapt to load increases on any single server by further spreading the update load.
この数年の間に、私たちが学んできたことはストロング･コンシステンシーであり、上手くやれば、高度なレベルでスケールを確保できた。 つまり、その実装において、トリックが機能していたことになる。 この、フル･コンシステンシーを達成するナイーブなアプローチは、シングル･マスタ･サーバーを介して全てのアップデートを送信するが、スケーラブルでないことは明らかである。それに代えて、アップデート･スペースを多数のパーティションに分割する方式では、それぞれが自身のマスターを持つことになる。この場合には、スケールがが達成されるが、依然として多数のパーティション間における調整が必要であり、それらを維持するためのコストが生じるため、論点を避けているといわざるを得ない。この方式を、多数のパーティションに対して用いると、パーティション管理におけるオーバーヘッドが増大する。正解は、必要とされるパーティション数を維持するために、動的に再パーティションする能力を持つことである。また、アップデートの負荷を拡散させることで、シングル･サーバー上の増大する負荷に順応する能力も必要となる。
There are many approaches to support dynamic hot sport management. One is to divide the workload into 10 to 100x more partitions than expected servers and make these fixed-sized partitions be the unit of migration. Servers with hot partitions will end up serving less partitions while servers with cold partitions will manage more. The other class of approaches, is to dynamically repartition. Start with large partitions and divide hot partitions to multiple smaller partitions to spread the load over multiple servers.
ダイナミックなホット･スポットをサポートするための、数多くのアプローチが存在する。 ひとつの方式は、予想されるサーバー数に対して、10～100 倍のパーティションに負荷を分散し、その固定したパーティション･サイズをマイグレーションの単位とする。この場合、サーバーが使用するパーティション数は、相対的に少ないパーティションとなり、より多くの、非可動のパーティションを管理することになる。 別のレベルで考えるアプローチは、動力な再パーティションとなる。大きなパーティションから始めるが、複数のサーバーに負荷を分散するために、稼働中のパーティションを、さらに小さいパーティションに分割していく。
There are many variants of these techniques with different advantages and disadvantages. The constant is that full consistency is more affordable than many think. Clearly, eventual consistency remains a very good thing for workloads that don’t need full consistency and for workloads where the overhead of the above techniques is determined to be unaffordable. Both higher consistency models are quite useful.
そこには、数多くの派生テクノロジーがあり、それぞれがメリットとディメリットを持っている。 なにが定数かといえば、あれこれ考えるよりも、フル･コンシステンシーの方が安上がりな点である。 明らかなことは、フル･コンシステンシーを必要としない負荷において、イベンチュアル･コンシステンシーが適正を維持していることである。また、前述の方式におけるオーバーヘッドが高くつくと判断される場合にも、同じことが言える。いずれにしても、高度なコンシステンシー･モデルは、きわめて有用である。
This morning SimpleDB announced support for two new features that make it much easier to write many classes of applications: 1) consistent Reads, 2) Conditional put and delete. Consistent reads allows applications that need full consistency to be easily written against SimpleDB. So, for example, if you wanted to implement an inventory management system that didn’t lose parts in the warehouse, doesn’t sell components twice, or place multiple orders, it would now be trivial to write this application against SimpleDB using the consistent read support. Consistent read is implemented as an optional Boolean flag on SimpleDB GetAttributes or select statements. Absence of the flag continues to deliver the familiar eventually consistent behavior with which many of you are very familiar with. If the flag is present and set, you get strong consistency.
今朝（2010/2/24）のことだが、 SimpleDB の2つの新機能についてアナウンスがあった。それらは、1) Consistent Reads と、2) Conditional Put/Delete を、あらゆる規模のアプリケーションで容易にさせるものである。Consistent Read を用いることで、フル･コンシステンシーを必要とする SimpleDB 対応のアプリケーションが、容易に記述できるようになる。たとえば、ウェアハウス内で部品を管理し、受発注における重複を避けるための、在庫管理システムを実装する場合、Consistent Rread サポートを用いる SimpleDB に対して、そのアプリケーションを記述することは簡単である。 この Consistent Read は、SimpleDB GetAttributes の Boolean フラグ、もしくは選択されたステートメントとして実装される。そのフラグが存在しない場合には、これまでに慣れ親しんできた、イベンチュアル･コンシステントな振る舞いが継続される。 そして、フラグが存在し、設定されている場合には、ストロング･コンシステンシーが得られることになる。
SimpleDB conditional PutAttributes and DeleteAttributes are a related feature that makes it much easier to write applications where the new value of an attribute are functionally related to the old value. Conditional update support allows a programmer to read the value of an attribute, operate upon it, and then write it back only if the value hasn’t changed in the interim which would render the planned update invalid. For example, say you were implementing a counter (+1). If the value of the counter at time T0 was 0, and subsequently an increment was applied at time T1 and another at increment was applied at time T2, what is the value of the counter? Using eventual consistency and, for simplicity, assuming no concurrent updates, the resulting value is probably is 2. Unfortunately, the value might be 1. With conditional updates, it will be 2. Again, conditional puts and deletes are just another great tool to help write correct SimpleDB applications quickly and efficiently.
SimpleDB で条件を管理する PutAttributes と DeleteAttributes は、何らかの属性値が古い値と機能的に関連する場合の、アプリケーション記述を容易にするための機能である。Conditional Update のサポートにより、プログラマーは属性値を読み取り、その処理を行い、書き戻しを行う。ただし、それが可能になるのは、こうした一連の操作が行われる間に、所定のアップデートを無効にするような、値の変更が無い場合に限られる。たとえば、カウンターとして（＋１）を実装しているとしよう。 そのとき、時刻（T0）のカウンター値が０で、時刻（T1）でインクリメントが行われ、時刻（T2）でもインクリメントが行われたとすると、そのカウンター値は何になるだろう？ 単純に考えて、イベンチュアル･コンシステンシーを用いるなら、そしてコンカレントなアップデートが無いなら、おそらく値は ２になる。 しかし、その値が１の場合もあるかもしれない。 Conditional updates なら、その値は 2になる。 もう一度だけ確認するが、Conditional puts / deletes は、SimpleDB アプリケーションの迅速かつ効果的な記述を支援する、もうひとつの強力なツールである。
For more information on consistent reads and conditional put and delete, see SimpleDB Consistency Enhancements.
Consistent Reads と Conditional Put / Ddelete の詳細については、SimpleDB Consistency Enhancements を参照してほしい。
These two SimpleDB features have been in the works for some time and so it is exciting to see them announced and available today. It’s great to now be able to talk about these features publically. If you are interested in giving them a try, you can for free. There is no charge for SimpleDB use for database sizes under 1GB (and silly close to free above that level). Go for it.
SimpleDB においては、この２つの機能が推進されてきたが、ようやく今日、発表することができた。 この機能について、パブリックに話せることは素晴らしいことだ。 もし、それらの機能を使ってみようという興味があるなら、自由に試すことができる。 SimpleDB での 1GB 以下の 利用は無償だ（そして、多少オーバーしても、ただ同然の対価だ）。ぜひ、試してほしい。
＜関連＞
Wikipedia：一貫性モデル
Cassandra 分散データベースでの削除とは？
Twitter が Cassandra を選んだ理由 — MyNoSQL
Digg が Cassandra を採用する理由 by John Quinn
