aws memo

AWS関連の備忘録 (※本ブログの内容は個人的見解であり、所属組織及び企業の意見を代弁するものではありません。１年以上古いエントリは疑ってかかってください)

訳：ACID vs BASE

NoSQL RDS 訳 Architecture

ACID vs. BASE: The Shifting pH of Database Transaction Processing | Articles | DATAVERSITY

http://www.dataversity.net/archives/9488

====

化学において、pHは水溶性の液体aqueousの塩基度(basicity)と酸性度(acidity)の関係を計測する方法である。pHは最も酸性度が高い0から、最もアルカリ度が高い14の間で計測される。77°F(25℃)の純水はpH7で、中性である。データエンジニアは化学者からこの比喩を賢く借用して、上記意味を持たない略語を作った。未だにこれは、トランザクション処理の信頼性を議論する際に、データベースシステムで起きている事の代表的なものである。

この便利な比喩を拡張するために、pHの考えを見てみよう(first look)。1909にCarlsberg研究所で働いていた　Søren Peder Lauritz Sørensen が最初にこの概念を作ったため、この考えは新しくない。(H)は水素原子を表している。(p)はフランス語でpuissance、ドイツ語でpotenz、ラテン語でpondusかpotentiaから来たなど多く(considerable)の異論があるが、すべてpotentialかpowerを意味する。このように、pHは水素エネルギーのpower/potentialか水素原子の活動度を表現する。酸性の溶剤(solution)はより活発で、アルカリ性の溶剤は少ない。データベースのトランザクション処理においては、水素原子はシステムを流れるデータである。(p)はトランザクションがきちんと(reliably)処理していることを保証する属性である。

ACIDとは？

データ専門家に尋ねると、彼らはおそらくACID(Atomicity, Consistency, Isolation, Durability)の略について説明するだろう。この概念は数十年存在し続けており、近年もいまだに全てのデータベースが実現に向けて奮闘している基本的なベンチマークである。適切な(in place)ACID要件が無いシステムは、信頼性が疑わしい。

Jim Greyが1970年代に初めてこの考えを発案し、その後1981年6月に " The Transaction Concept: Virtues and Limitations (トランザクションの概念：)"という草分け的な論文を発表した。この論文では、Atomicity(不可分性)、Consistency(一貫性)、Durability(永続性)についてのみ述べている。Isolation(独立性)は後に追加された。この論文は、トランザクションレベルに集中して、 契約や「システム状態の遷移」数として定義した。Bruce Lindsay et al. が1979年に書いた「Notes on Distributed Databases」は、Greyの研究に基づいて、一貫性を実現するための原理と、データベースレプリケーションの主な基準を定めた。1983年には、Andreas ReuterとTheo Härderが「Princeples of Transaction-Oriented Database Recovery」を発表し、正式にACIDという言葉を作った。20年後、ACIDは以下の意味を持っている。

多くの特定のデータベースの実際のACID要件や定義があるが、RDBMS界では、ACIDは難しく、ACIDが無いと信頼性は信頼できない(uncertain)。ACIDのpH値は、だいたい酢(0)やビネガー(2)と似て低い。データとその制約は極めて(exceedingly)活発である。そして、システム制約としてACIDを使っているデータベース内のいかなる瞬間でも、全データ(水素原子)は、制約を満たしているかという制約チェックの配下にある。この要求は、ここ数年のソーシャルネットワーク以前の、小さく、水平スケールの、スキーマ駆動の、平準化された、リレーショナル界でうまく機能していた。非構造化データ、ビックデータ、非リレーショナルデータ構造、分散システム、evetual consistencyは一般的(commonplace)になりつつあり、新しい略語と新しいpHを必要としている。

CAP定理

2000年に、Eric Brewerが発表したACMシンポジウムの基調講演で、分散コンピューティングの原則とCAP定理が生まれた。PCとインターネットとソーシャルメディアが動けばよくファイルの一貫性さえあればよい、と思っている多くの人はそれらの定理を聞いたことがなく、気にもしていなかった。Brewerの定理とも知られているCAP定理は、2002年にMITの SethGilbertとNancy Lynchの研究で改訂された。この定理の主義(tenet)の中心には、分散システムのアプリケーションにおける設計・実装・デプロイの成功のために必要な３つのシステム要求から成り立っている。これらは、Consistency(一貫性)、Availability(可用性)、Partition Tolerance (分断耐性)もしくはCAPという

  • Consistency(一貫性)は、システムの操作が完全に行われるか行われないかを意味する。システムは、ルールに則ったプログラムの通りに信頼性ある動作をしているか？クラスタの全ノードが全データを参照できるか？この考え方はACIDと同じである。
  • Availability(可用性) は、 そのままの意味である。要求を受けた時にサービスやシステムが使えるかどうか？各リクエストは障害に関係なくレスポンスを受け取れるか？
  • Partition Tolerance(分断耐性) は、データ喪失の状態やシステム障害の状態でも、システムが動作を続けられるかという事実を表す。あるノードの故障がシステム全体の障害にならないようにすべきである。

 

これらはCAP定理の3つの側面の簡単な定義である。多くの論文の中で、多くの出典、分析、実世界のアプリケーションの理論で実際に起こっている複雑な問題について議論されている。

理論を表現する一番の理由は、分散システムは３つの機能のうち2つしか保証できない、ということを指摘することである。この判断を無視することは、同時に3つの要素に満たせないという破滅的な結果をもたらす(To ignore such a decision could have catastrophic results that include the possibility of all three elements falling apart simultaneously. )。

データベースの信頼性におけるCAP定理の制約は、新しい大規模、分散、非リレーショナルなシステムにとってとても大きい。これらシステムは、可用性と分断耐性を必要としているが、一貫性とACIDを我慢している。「丘のために走る(Run for the hills)」は適切な言い回しだ。

BASEの紹介とBOW

分散システム界にとって幸運なことに、エンジニアは賢い。GoogleのBig TableやAmazon のDynamoやFacebookのCassandraのような超大規模データシステムが一貫性のロスをいかに少なくして、システムの信頼性を維持しているか？簡単ではないが、その答えは、化学やpHの問題である、BASE (Basically Available, Soft state, Eventual Consistency)である。BASEが信頼性についての最優先の要件であるシステムでは、データ(H)の活動/ポテンシャル(p)が変わる。pHスケールにて、BASEシステムは、石鹸水(12)やGreat Salt Lake(10)かもしれない。数億のトランザクションがすぐに発生しないと言ってはいないが、変わりつつある。これらの束縛は異なるルールで異なるときに発生する。ACIDシステムでは、データがシューッと鳴って泡立ち、永久に活動しているが、BASEシステムでは、泡は風呂の水のように居続けるが、ACIDの活動要件と同じではない。その理由は、

Basically Available：システムがCAP定理におけるいかなるリクエストにも応答するというデータの可用性を保証しないという制約である。しかし、その応答は、「障害」を含んでいたり、データが一貫性がとれていないもしくは状態が変わっているかもしれない。これは、銀行口座がチェックを完了するのを待つのに似ている。

Soft State：システムの状態は常に変わるので、「eventual consistency」に変わるべき。このようなシステム状態は常に「ソフト」である。

Eventual Consistency：システムは、入力の受信を止めればいつかは一貫性を持つ。すぐに、もしくはしばらくしてデータはすべての場所に伝播する。しかし、システムは入力を受信し続け、各トランザクションが次のトランザクションに移る際に一貫性をチェックしない。Werner Vorgelの記事 "Eventually COnsistent - Revisited"はこの話題をより詳細にカバーしている。

結論 - 前に進む -

データベースのトランザクション処理の新しいpHは、コストに効果的なレベルで水平にスケールできるようになる。各トランザクションのすべての瞬間の変更で一貫性のチェックを、文字通り数兆のトランザクションが発生するシステムで実施することは膨大な(gargantuan)コストがかかる。計算の要求は天文学的になっている。Yahoo!やGoogleやTwitterやAmazonによって与えられるEventual Consistencyが、可用性と分断耐性の必要性とともに、世界中の顧客との継続的なやり取りを可能にし、コストを削減しながら、システムは動き続け、顧客を幸福にしている。もちろんいつでも完全な一貫性あると良いが、Dan Pritchettが "BASE: An Acid Alternative"で述べているように、トレードオフが存在し、Eventual Consistencyはソーシャルネットワーク、クラウドコンピューティング、その他ビッグデータといったデータが急増するシステムを効率的に開発することを可能にしている。