Stonebraker on CAP Theorem and Databases
http://perspectives.mvdirona.com/2010/04/07/StonebrakerOnCAPTheoremAndDatabases.aspx
Mike Stonebraker published an excellent blog posting yesterday at the CACM site : Errors in Database Systems, Eventual Consistency, and the CAP Theorem . In this article, Mike challenges the application of Eric Brewer’s CAP Theorem by the NoSQL database community. Many of the high-scale NoSQL system implementers have argued that the CAP theorem forces them to go with an eventual consistent model.
昨日（4/5）のことだが、Mike Stonebraker が CACM site : Errors in Database Systems, Eventual Consistency, and the CAP Theorem という素晴らしいブログをポストした。この記事で Mike は、データベース･コミュニティによる、Eric Brewer の CAP Theorem の適用についてチャレンジしている。数多くの ハイ･スケール NoSQL システムの実装者たちが主張しているのは、それらの新しいテクノロジジーにフォーカスする CAP theorem は、イベンチュアル･コンシステント･モデルにも注目すべきというものだ。
Mike challenges this assertion pointing that some common database errors are not avoided by eventual consistency and CAP really doesn’t apply in these cases. If you have an application error, administrative error, or database implementation bug that losses data, then it is simply gone unless you have an offline copy. This, by the way, is why I’m a big fan of deferred delete. This is a technique where deleted items are marked as deleted but not garbage collected until some days or preferably weeks later. Deferred delete is not full protection but it has saves my butt more than once and I’m a believer. See On Designing and Deploying Internet-Scale Services for more detail.
Mike は、いくつかの共通するデータベース･エラーが、イベンチュアル･コンシステンシーでは回避されず、また、そのようなケースには CAP を適用できないという、こうした主張にチャレンジしている。 もし、アプリケーション･エラーや、アドミニストレーション･エラー、あるいはデータベース実装のバグによりデータが失われても、オフラインのコピーを持っていなければ、それらは簡単に消えてしまう。 ついでながら、私が遅延デリートの大ファンである理由も、ここにある。このテクニックでは、削除されたアイテムは ｢削除｣ というマークが付けられるだけであり、設定に応じて数日から数週の期間、ガベージ･コレクションの対象にならない。 遅延デリートは完全なプロテクションにはならないが、一度ならずも手がかりを保持してくれたので、私は信者になっている。さらなる詳細については、On Designing and Deploying Internet-Scale Services を参照してほしい。
CAP and the application of eventual consistency doesn’t directly protect us against application or database implementation errors. And, in the case of a large scale disaster where the cluster is lost entirely, again, neither eventual consistency nor CAP offer a solution. Mike also notes that network partitions are fairly rare. I could quibble a bit on this one. Network partitions should be rare but net gear continues to cause more issues than it should. Networking configuration errors, black holes, dropped packets, and brownouts, remain a popular discussion point in post mortems industry-wide. I see this improving over the next 5 years but we have a long way to go. In Networking: the Last Bastion of Mainframe Computing , I argue that net gear is still operating on the mainframe business model: large, vertically integrated and expensive equipment, deployed in pairs. When it comes to redundancy at scale, 2 is a poor choice.
CAP およびイベンチュアル･コンシステンシーの適用が、アプリケーションやデータベースの実装エラーから、私たちのデータを守ることはない。 そして、クラスタ全体が失われるような大災害などのケースでは、イベンチュアル･コンシステンシーも CAP も、ソリューションを提供できないことを確認しておこう。 さらに Mike は、ネットワーク･パーティションが問題となるケースが、かなり稀だが存在すると指摘している。ここで、ちょっとツッコミを入れてみたいと思う。 ネットワーク･パーティションの問題は稀にあるはずだが、ネットワーク･ギアは予想以上に問題を起こし続けるはずだ。 ネットワークの設定エラーや、ブラックホール、パケットの欠落、電力の供給不足などが、産業界の全体におよぶ欠陥として、幅広く議論され続けている。 今後の 5年間で、それらが改善されると確信するが、その行程は長い。 Networking: Last Bastion of Mainframe Computing における私の主張は、いまだにネット･ギアは、メインフレーム･ビジネス･モデルのもとで運用されているというものだ。つまり、ペアとしてディプロイされる、大規模垂直型の統合と、高価な装置に理由がある。 スケールの冗長性の話になると、ペアという選択肢は貧弱なものとなる。
Mike’s article questions whether eventual consistency is really the right answer for these workloads. I made some similar points in “I love eventual consistency but… ” In that posting, I argued that many applications are much easier to implement with full consistency and full consistency can be practically implemented at high scale. In fact, Amazon SimpleDB recently announced support for full consistency. Apps needed full consistency are now easier to write and, where only eventual consistency is needed, its available as well.
Mike の論旨における問い掛けは、こうしたワークロードに対して、ほんとうにイベンチュアル･コンシステンシーが、適切な回答になるかというものだ。 私は ” I love eventual consistency but… ” で同様の指摘をした。 あのポストでは、数多くのアプリケーションをフル･コンシステンシーで実装することは容易であり、とりわけ、大規模スケールにおいて実装が可能だと主張した。 現実に、Amazon SimpleDB では、フル･コンシステンシーをサポートすると、最近になって発表した。 フル･コンシステンシーを必要とするアプリケーションの記述は容易になっており、また、イベンチュアル･コンシステンシーだけが必要な場合でも、その利用は簡単になっている。
Don’t throw full consistency out too early. For many applications, it is both affordable and helps reduce application implementation errors.
あまりも早く、フル･コンシステンシーを投げ出してはいけない。 それは、数多くのアプリケーションにとって、経済的なものであり、また、アプリケーション実装におけるエラーを減らすものである。
–jrh
Thanks to Deepak Singh for pointing me to this article.
James Hamilton
e: jrh@mvdirona.com
w: http://www.mvdirona.com
b: http://blog.mvdirona.com / http://perspectives.mvdirona.com
ーーーーーー
コンシステント･モデルも、ケース-by-ケースでということなんでしょうね。 Mike Stonebraker さんのブログも面白そうですね。 ーーー A.C.
ーーーーー
＜関連＞
Database System エラーと Eventual Consistency と CAP Theorem _1
Database System エラーと Eventual Consistency と CAP Theorem _2
イベンチュアル･コンシステンシーはお好き？
Google 的 クラウド連携の ABC ?
Cassandra 分散データベースでの削除とは？
Twitter が Cassandra を選んだ理由 — MyNoSQL
Digg が Cassandra を採用する理由 by John Quinn
