Errors in Database Systems, Eventual Consistency, and the CAP Theorem _2
Michael Stonebraker
April 5, 2010
http://cacm.acm.org/blogs/blog-cacm/83396-errors-in-database-systems-eventual-consistency-and-the-cap-theorem/fulltext
First, note that errors 1 and 2 will cause problems with any high availability scheme. In these two scenarios, there is no way to keep going; i.e., availability is impossible to achieve. Also, replica consistency is meaningless; the current DBMS state is simply wrong. Error 7 will only be recoverable if a local transaction is only committed after the assurance that the transaction has been received by another WAN-connected cluster. Few application builders are willing to accept this kind of latency. Hence, eventual consistency cannot be guaranteed, because a transaction may be completely lost if a disaster occurs at a local cluster before the transaction has been successfully forwarded elsewhere. Put differently, the application designer chooses to suffer data loss when a rare event (such as a disaster) occurs, because the performance penalty for avoiding it is too high.
最初に指摘しておきたいのは、error 1 と 2 が、あらゆる高可用性スキームであっても、問題を引き起こす点だ。 この 2つのシナリオにおいては、運用を継続する方法が無く、可用性を達成することが不可能になる。それと同様に、レプリカ･コンシステンシーは無意味になり、最新の DBMS ステートは、単に不正確なものとなる。 Error 7 の回復は可能だが、対象となるトランザクションが、WAN で接続された他のクラスタに受け入れられたという保証の後に、ローカル･トランザクションがコミットされていることが条件となる。この種のレイテンシーを受け入れようとするアプリケーション･ビルダーは、ほとんど居ない。 それ故に、イベンチュアル･コンシステンシーは保証されない。 その理由は、トランザクションの他所への転送が成功する前に、ローカル･クラスタに大災害が起こる場合に、トランザクションが完全に失われる可能性があるからだ。 言い換えると、パフォーマンスのペナルティーがあまりにも高いため、アプリケーション･デザイナーは、（大惨事のような）稀な出来事が起こる際に、データの喪失を受け入れるという選択とる。
As such, errors 1, 2, and 7 are examples of cases for which the CAP theorem simply does not apply. Any real system must be prepared to deal with recovery in these cases. The CAP theorem cannot be appealed to for guidance.
このように、CAP theorem が単純に適用されないケースの例として、error 1、2、7がある。 しかし、現実のシステムでは、このような場合にリカバリを取り扱うための、用意を整えているに違いない。 そして、CAP theorem にガイダンスを求めることはできない。
Let us now turn to cases where the CAP theorem might apply. Consider error 6 where a LAN partitions. In my experience, this is exceedingly rare, especially if one replicates the LAN (as Tandem did). Considering local failures (3, 4, 5, and 6), the overwhelming majority cause a single node to fail, which is a degenerate case of a network partition that is easily survived by lots of algorithms. Hence, in my opinion, one is much better off giving up P rather than sacrificing C. (In a LAN environment, I think one should choose CA rather than AP). Newer SQL OLTP systems (e.g., VoltDB and NimbusDB) appear to do exactly this.
ここで、CAP theorem の適用が可能なケースに、話題を切り替えよう。LAN パーティションにおける、error 6 について考えてほしい。 私の経験において、とりわけ Tandem がそうしたように、LAN がリプリケートされている場合には、このような状況に陥るのはきわめて稀である。 ローカルな失敗（3、4、5、6）を考慮に入れると、シングル･ノードを失敗させる要因は、きわめて多数になる。 それらは、ネットワーク･パーティションが劣化したケースであり、各種のアルゴリズムにより容易に生き残らせることが可能である。 それ故に、私の意見としては、C を犠牲にするよりも、P を断念する方が適切な選択となる（LAN 環境では、AP よりも CA を選択すべきと考える）。 最近の SQL OLTP システム（たとえば VoltDB やNimbusDB）では、こうした処理が正確に行われると思われる。
Next, consider error 8, a partition in a WAN network. There is enough redundancy engineered into today’s WANs that a partition is quite rare. My experience is that local failures and application errors are way more likely. Moreover, the most likely WAN failure is to separate a small portion of the network from the majority. In this case, the majority can continue with straightforward algorithms, and only the small portion must block. Hence, it seems unwise to give up consistency all the time in exchange for availability of a small subset of the nodes in a fairly rare scenario.
次に、WAN パーティションにおける error 8 を考えてみよう。 今日の WAN には、充分な冗長性があるので、その障害はきわめて稀なものとなる。 私の経験においては、ローカルでの障害と、アプリケーション･エラーの確率の方がずっと高い。 さらに言えば、最も確率の高い WAN 障害は、ネットワークの小さなかたまりを、その他の大部分から分離してしまうことである。 この場合、大部分の方は簡単なアルゴリズムを用いて継続され、小さい部分だけがブロックされるはずだ。 それ故に、ノード上の小さなサブ･セットの可用性と引き換えに、常にコンシステンシーを断念することは、かなり稀なシナリオであり、賢明ではないと思われる。
Lastly, consider a slowdown either in the OS, the DBMS, or the network manager. This may be caused by skew in load, buffer pool issues, or innumerable other reasons. The only decision one can make in these scenarios is to “fail” the offending component; i.e., turn the slow response time into a failure of one of the cases mentioned earlier. In my opinion, this is almost always a bad thing to do. One simply pushes the problem somewhere else and adds a noticeable processing load to deal with the subsequent recovery. Also, such problems invariably occur under a heavy load–dealing with this by subtracting hardware is going in the wrong direction.
最後に、 OS／DBMS／ネットワーク･マネージャのスローダウンについても考えてみよう。 それらは、負荷による歪みや、バッファプールの問題、そして数え切れない程の理由により引き起こされるだろう。 これらのシナリオにおいて可能な唯一の判断は、不適切なコンポーネントを "fail" にすることだ。 つまり、反応が遅いという状況を、以前に言及した失敗のケースに置き換えることである。私の意見として、それを行うことは、大半のケースに置いて、良くないことになる。 つまり、問題を他所に押し出すことになり、また、継続してリカバリを行う際に注意すべき、処理の負荷を増大することにつながる。さらに、この種の問題は、重い負荷のもとで一様に引き起こされる。 つまり、ハードウェアを間引いて処理することは、間違った方向の選択となる。
Obviously, one should write software that can deal with load spikes without failing; for example, by shedding load or operating in a degraded mode. Also, good monitoring software will help identify such problems early, since the real solution is to add more capacity. Lastly, self-reconfiguring software that can absorb additional resources quickly is obviously a good idea.
明らかなことは、ピークを持つ負荷を、失敗せずに取り扱うソフトウエアを記述すべきである。 たとえば、負荷を発散させるか、ディグレート･モードでの稼働により対処する。 また、現実のソリューションでは、さらに多くのキャパシティが加えられるはずなので、適切なモニタリング･ソフトウェアの利用が、こうした問題の早期の識別に役立つだろう。 最後になるが、追加のリソースを迅速に吸収できる、何度でもセルフ･コンフィグレーションが可能なソフトウェアは、明らかに良いアイデアである。
In summary, one should not throw out the C so quickly, since there are real error scenarios where CAP does not apply and it seems like a bad tradeoff in many of the other situations.
簡単にまとめると、CAP が適用されない場所に本質的なエラー･シナリをがあるため、早急に C を諦めるべきではない。 そして、それは、大半の状況において、不適切なトレードオフになると思われる。
References
[1] Eric Brewer, “Towards Robust Distributed Systems,” http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf
[2] Jim Gray, “Why Do Computers Stop and What Can be Done About It,” Tandem Computers Technical Report 85.7, Cupertino, Ca., 1985. http://www.hpl.hp.com/techreports/tandem/TR-85.7.pdf
Disclosure: In addition to being an adjunct professor at the Massachusetts Institute of Technology, Michael Stonebraker is associated with four startups that are either producers or consumers of database technology.
ーーーーー
＜関連＞
Database System エラーと Eventual Consistency と CAP Theorem_1
Stonebraker と CAP Theorem と Databases – by James Hamilton
イベンチュアル･コンシステンシーはお好き？
かなり気になる、NoSQL 関連のポスト : Cassandra や CAP Theorem など
Google 的 クラウド連携の ABC ?
