ACID トランザクションが Apache Cassandra に登場: これが私たちが興奮する理由です

An extraordinary computer science breakthrough called Accord is bringing globally available, general-purpose ACID transactions to the next Cassandra release

まずはいいところを出しましょう。 ACID トランザクションがApache Cassandra に導入されます。

Cassandra と同じように動作する、グローバルに利用可能な汎用トランザクション。これは、細字や古い技術の適用によるトリックではありません。

これは、Apple とミシガン大学のチームによるAccordと呼ばれる驚異的なコンピューター サイエンスのブレークスルーによるものです。 Cassandra が新しいユースケースを開くことで、データの考え方を変えるのに役立ちます。

これは、Cassandra プロジェクトとその機能の詳細に詳しくない人にとって何を意味するかを示しています。アプリケーションを本番環境にどれだけ迅速に投入できるかほど重要なことはありません。しかし、Cassandra のスケール、回復力、伝説的なマルチデータ センター サポートを金融取引などに活用したい開発者は、アプリに複雑な回避策を多数コーディングする必要がありました。たとえば Oracle を使用することとのトレードオフは重大でした。

アコードで？トレードオフはありません。 Cassandra は、トランザクションのサポートをデータベースに移行し、コードの複雑さを大幅に軽減しながら、Cassandra を素晴らしいものにしたすべての機能をサポートするようになりました。

観察者の目

データベース システムには、データを確実に格納し、クエリを実行できるなど、不可欠な機能があります。データの変更を管理することは、必ずしもデータベースの機能ではありません。多くの NoSQL システムの場合、変更管理の負担はユーザーに委ねられています。データ変更のオブザーバーは、排他性の重要性を割り当てる人です。

ポイントは、与えられたデータを蓄積することだとします。その場合、オブザーバーは、データが受信され、永続的に保存されたことを認識している必要があります。たとえば、すべてのデータ ポイントが一意で累積的な株式ティッカー データです。排他性は必要ありません。

より機密性の高い操作では、データ変更のオブザーバーは、データベースを使用する唯一のプロセスであると感じる必要があります。これは、「分離」と呼ばれるコンピューター サイエンスの概念です。それは、ACID (原子性、一貫性、分離、耐久性) の「私」です。

古典的な例は、ある銀行口座からお金が引き落とされ、別の銀行口座に追加される銀行送金です。正確にその順序で行われます。観察プロセスには、矛盾や驚きにつながる可能性のある変更を行う他のプロセスを回避するための排他性が必要です。

驚きには、0 ドルを下回った口座からの送金を誤って許可することが含まれます。

分離は、一度に 1 つのプロセスだけが変更できることを保証し、2 つのプロセスが同じデータを求めて競合している場合、そのうちの 1 つは他のプロセスが完了するまで待機する必要があります。

あなたの怠惰を受け入れる

開発者は、信頼できるシステムを迅速に使用する必要があります。 ACID トランザクションは、ほぼ 50 年間、データベース システム内の信頼のゴールド スタンダードでした。開発者は要件に基づいてトレードオフを検討し、ACID トランザクションをサポートしていないシステムで作業するようになることがあります。

NoSQL システムのトレードオフ バイアスは、歴史的に、トランザクションを犠牲にしてスケールと稼働時間に傾く傾向がありました。

Cassandra に ACID トランザクションを導入することは、トレードオフを減らすことにありました。 Cassandra は、最悪のシナリオでもアップタイムを維持しながら線形スケーリングを行うことで、すでに確固たる評判を得ています。

Cassandra は、インターネットが提供できるものに対応できるデータベースが必要な場合に選択されてきました。当然のことながら、トランザクションの必要性は、開発者にとってトレードオフの対立の原因となっています。

コンセンサスを得ることができますか?

分散システムでは、大規模なクラスター内の各メンバー ノードが独立して動作するか、他のノードと連携する必要があります。 「ねえ、私たち全員が何かに同意する必要がある」トランザクションでは、コンピューター科学者はこれをコンセンサスと呼び、これらのプロトコルの開発は継続的な改善領域です.

Paxos は、 「軽量トランザクション」のために 2013 年に Cassandra によって採用された、確立されたコンセンサス プロトコルです。

単一のパーティション データ変更がトランザクション内で分離されることが保証されるため、軽量ですが、複数のテーブルまたはパーティションはオプションではありません。さらに、Paxos はコンセンサスを得るために複数回のラウンド トリップを必要とするため、アプリケーションで軽量トランザクションをいつ使用するかについて、多くの余分な待ち時間と詳細情報が作成されます。

Paxos に代わる次世代としてRaftプロトコルが開発され、Etcd、CockroachDB、DynamoDB などのいくつかのシステムがそれを採用しました。選出されたリーダーを作成することで、往復を減らしました。

このアプローチにおける Cassandra の欠点は、リーダーが複数のデータ センターにまたがらないことです。そのため、複数のリーダーが必要になります ( Spanner を参照)。

選出されたリーダーを持つことは、Cassandra の「何も共有しない」という原則にも違反し、障害の処理に関する新しい要件を重ねることになります。

ノードがダウンした場合、新しいリーダーを選出する必要があります。

他のデータベース (FaunaDB や FoundationDB など) は、 Calvin の論文で説明されているように、単一のグローバル リーダーに縮小することでマルチリーダーの問題を解決しようとする道をたどりました。

これらは要件が異なる他のデータベース用に構築されたため、これらのケースで使用されたアプローチは、Cassandra が障害モードで期待する基準を満たしていませんでした。

Cassandra は、大規模な分散システムの実行の一部として障害を想定しています。 1 つ以上のノードがオフラインになることで、パフォーマンスが急速に低下したり、可用性の問題が発生したりすることはありません。別のアプローチが必要でした。

我々は合意に達したか？

Cassandra プロジェクトに何が受け入れられるかについて、非常に意見が分かれる場合があります。私たちの基準は、分散システムがどのように実行されるべきかについての核となる信念に忠実であることです。 1 つまたは複数のデータセンターで複数のノードを運用している間は、パフォーマンスとスケーリングを常に維持する必要があります。私たちは非常に要求が厳しい場合がありますが、これが非常に多くの組織が Cassandra を選択する理由です。

コンセンサス プロトコルの以前の繰り返しは、問題のさまざまな部分を解決しましたが、それぞれが Cassandra の値の一部に違反するトレードオフを提示しました。次の大きな突破口は、前回の論文から 2 論文離れたところにあると言われています。この場合、論文はアコードであり、トレードオフを排除するために大きなスワイプが必要でした.

Accord は、以前のコンセンサス プロトコルでは解決されなかった 2 つの問題に対処します。最初の新しいメカニズムはリオーダー バッファです。

コモディティ ハードウェアが使用されていると仮定すると、ノード間のクロックの違いは避けられません。リオーダー バッファーは、ノード間の遅延に加えて、ノード間の違いを測定します。各レプリカはこの情報を使用して、各ノードからのデータを正しく並べ替え、違いを説明し、タイムスタンプ プロトコルで 1 つのラウンドトリップ コンセンサスを保証します。

もう 1 つのメカニズムは高速パスの有権者です。障害モードでは、再開する前に新しいリーダーを選択するときに遅延が発生する可能性があります。高速パスの有権者は、Cassandra の既存の機能といくつかの新しい実装を使用して、Cassandra が許容するのと同じレベルの障害でクォーラムへのリーダーレス高速パスを維持します。詳細については、 提案書を参照してください。

それはどのように機能しますか?

最大の影響は開発者の生産性にあるため、実際にどのようになるか見てみましょう。前述の次の銀行口座振替の例を考えてみましょう。

1 つ目は、Cassandra クエリ言語 (CQL) で見られる新しい構文です。トランザクションは、 BEGIN TRANSACTIONおよびCOMMIT TRANSACTION宣言に含まれています。トランザクション マーカー内のすべての処理は、他のプロセスから分離されてアトミックに行われます。この例では、アリスの口座からボブに $20 を送金します。それ以上に古典的なものはありません！

セクション A では、既存のレコードからデータを選択し、結果をタプル (1 つの変数に格納された複数の項目) に割り当てることができます。 SELECT句に含まれる列の数に応じて、タプルに 1 つ以上の値を格納できます。これらの値は、データを変更する前に条件をテストするためにセクション B で使用されます。

この場合、ボブに送金する前に、アリスの口座に $20 があるかどうかをテストします。その場合、 UPDATE Alice の口座残高を 20 ドル減らし、Bob の口座残高を 20 ドル増やします。アリスの資産が 20 ドル未満の場合、変更は行われません。

監視プロセスからわかるように、舞台裏では排他的に実行されるデータベース コマンドのシリアル化されたセットがあります。 1 つ以上のデータ センター間で、コンセンサスを得るために必要なトランザクションは 1 ラウンド トリップだけでした。また、いずれかのノードがオフラインの場合でも、少なくともクォーラムのレプリカが利用可能であれば、アクションは引き続き実行されます。

これはまさに Cassandra が好んで行う方法ですが、グローバルに利用可能なトランザクションでゲームを強化しただけです。

次は何ですか

Accord とそれに伴うすべての作業はまだ進行中であり、次の Cassandra リリースに含まれる予定です。これはすべてオープン ソースであるため、待ちきれない人は、Cassandra リポジトリからcep-15-accordブランチのコピーを複製して、独自のコピーを作成できます。

残りの皆さんのために、リリース時期が近づくにつれて、使用およびテストできるビルドを用意します。これは Cassandra のゲーム チェンジャーとなるでしょう。

私が最も関心を持っているのは、Cassandra に期待される速度と回復力で実行されるグローバルに利用可能なトランザクションでどのようなユース ケースが見つかるかについて、コミュニティから聞くことです。最後のリレーショナル データベース ワークロードを手放す時がついに来ましたか?

また、Apache Software Foundation Slack やプロジェクト メーリング リストなど、すべてのチャンネルでフィードバックをお待ちしております。オープン ソース プロジェクトの機能は、ユーザーのニーズを満たすために常に進化しています。そのため、将来のApache Cassandraを形作る上で、あなたは重要な役割を担っています。

このエキサイティングな新機能が進化するにつれて、より多くのユースケースと情報にご期待ください。これについては、3 月 14 日に開催されるCassandra Forwardデジタル サミットでいくつかの講演が行われることが予想されます。

パトリック・マクファディン、DataStax

Patrick McFadin は、O'Reilly の著書「Managing Cloud Native Data on Kubernetes」の共著者です。彼は現在、DataStax で開発者関係の仕事をしており、Apache Cassandra プロジェクトへの貢献者として働いています。 Patrick は Apache Cassandra のチーフ エバンジェリスト (彼は新しく作成された Cassandra コミッターでもあります!) および DataStax のコンサルタントとして働いており、本番環境で最大のデプロイメントのいくつかを構築するのに素晴らしい時間を過ごしました。