🥇NewSQL = NoSQL+ACID | プロホスター

最近まで、Odnoklassniki はリアルタイムで処理された約 50 TB のデータを SQL Server に保存していました。このようなボリュームの場合、SQL DBMS を使用して、高速で信頼性が高く、さらにはデータセンターの耐障害性のあるアクセスを提供することはほとんど不可能です。通常、このような場合は NoSQL ストレージの XNUMX つが使用されますが、すべてを NoSQL に転送できるわけではありません。エンティティによっては ACID トランザクション保証が必要です。

これにより、NewSQL ストレージ、つまり NoSQL システムのフォールトトレランス、スケーラビリティ、パフォーマンスを提供しながら、同時に従来のシステムでおなじみの ACID 保証を維持する DBMS を使用するようになりました。この新しいクラスの実用的な産業システムはほとんどないため、私たちはこのようなシステムを独自に実装し、商用運用を開始しました。

それがどのように機能し、何が起こったのか - カットの下をお読みください。

現在、Odnoklassniki の月間視聴者数は 70 万人を超えています。私たちは私たちはトップXNUMXに入っています世界最大のソーシャルネットワークであり、ユーザーが最も多くの時間を費やしているサイト 8000 に入っています。 OK インフラストラクチャは、フロントあたり 1 秒あたり XNUMX 万件を超える HTTP リクエストという非常に高い負荷を処理します。 XNUMX 台を超えるサーバーフリートの一部は、モスクワの XNUMX つのデータセンターに互いに近接して配置されているため、それらの間のネットワーク遅延は XNUMX ミリ秒未満です。

私たちは 2010 年から Cassandra を使用しており、バージョン 0.6 から始めています。現在、数十のクラスターが稼働しています。最速のクラスターは 4 秒あたり 260 万以上のオペレーションを処理し、最大のクラスターは XNUMX TB を保存します。

ただし、これらはすべてストレージに使用される通常の NoSQL クラスターです。調整が弱いデータ。私たちは、Odnoklassniki の設立以来使用されてきた主要な一貫性のあるストレージである Microsoft SQL Server を置き換えたいと考えていました。ストレージは 300 台を超える SQL Server Standard Edition マシンで構成され、50 TB のデータ (ビジネスエンティティ) が含まれていました。このデータは ACID トランザクションの一部として変更されるため、高い一貫性.

SQL Server ノード間でデータを分散するには、垂直方向と水平方向の両方を使用しました。パーティショニング (シャーディング)。これまで、私たちは単純なデータシャーディングスキームを使用していました。各エンティティは、エンティティ ID の関数であるトークンに関連付けられていました。同じトークンを持つエンティティは同じ SQL サーバー上に配置されました。マスターと詳細の関係は、メインレコードと子レコードのトークンが常に一致し、同じサーバー上に配置されるように実装されました。ソーシャルネットワークでは、ほとんどすべてのレコードがユーザーに代わって生成されます。これは、XNUMX つの機能サブシステム内のすべてのユーザーデータが XNUMX つのサーバーに保存されることを意味します。つまり、ビジネストランザクションには、ほとんどの場合、XNUMX つの SQL サーバーのテーブルが含まれるため、ローカル ACID トランザクションを使用することで、データの一貫性を確保することが可能になりました。遅くて信頼性が低い分散型 ACID トランザクション。

シャーディングと SQL の高速化のおかげで:

シャーディング時にエンティティ ID が別のサーバーに配置される可能性があるため、外部キー制約は使用しません。
DBMS CPU にさらなる負荷がかかるため、ストアドプロシージャとトリガーは使用しません。
上記のすべてとディスクからのランダムな読み取りが多いため、JOIN は使用しません。
トランザクションの外では、Read Uncommitted 分離レベルを使用してデッドロックを軽減します。
当社は短いトランザクションのみを実行します (平均して 100 ミリ秒未満)。
デッドロックが多数発生するため、複数行の UPDATE および DELETE は使用しません。一度に XNUMX つのレコードのみを更新します。
私たちは常にインデックスに対してのみクエリを実行します。私たちにとって、フルテーブルスキャンプランを使用したクエリは、データベースに過負荷がかかり、データベースが失敗することを意味します。

これらの手順により、SQL サーバーからほぼ最大のパフォーマンスを引き出すことができました。しかし、問題はますます多くなりました。それらを見てみましょう。

SQL に関する問題

自己記述のシャーディングを使用したため、新しいシャードの追加は管理者が手動で行いました。この間ずっと、スケーラブルなデータレプリカはリクエストを処理していませんでした。
テーブル内のレコード数が増えると、挿入と変更の速度が低下します。既存のテーブルにインデックスを追加する場合、速度は一定の割合で低下します。インデックスの作成と再作成にはダウンタイムが発生します。
実稼働環境で SQL Server 用の Windows を少量使用すると、インフラストラクチャ管理が困難になります

しかし、主な問題は

耐障害性

従来の SQL サーバーはフォールトトレランスが不十分です。データベースサーバーが 20 台しかなく、64 年に 200 回障害が発生するとします。この間、サイトは XNUMX 分間ダウンしますが、これは許容範囲です。サーバーが XNUMX 台ある場合、サイトは XNUMX 週間に XNUMX 回ダウンします。また、サーバーが XNUMX 台ある場合、サイトは毎週稼働するわけではありません。これは問題です。

SQL サーバーのフォールトトレランスを向上させるにはどうすればよいでしょうか? ウィキペディアは私たちに構築を勧めています高可用性クラスター: コンポーネントのいずれかに障害が発生した場合に備えて、バックアップが存在します。

これには、多数の重複、光ファイバー、共有ストレージなどの高価な機器が必要です。また、予備を含めても確実に機能しません。スイッチングの約 10% は、メインノードの背後にある電車のように、バックアップノードの障害で終了します。

しかし、このような高可用性クラスターの主な欠点は、クラスターが配置されているデータセンターに障害が発生した場合に可用性がゼロになることです。オドノクラスニキには XNUMX つのデータセンターがあり、そのうちの XNUMX つで完全な障害が発生した場合でも運用を確保する必要があります。

このために使用できるのは、マルチマスター SQL Server に組み込まれたレプリケーション。このソリューションは、ソフトウェアのコストがかかるためはるかに高価であり、同期レプリケーションでは予測できないトランザクション遅延が発生し、非同期レプリケーションではレプリケーション適用の遅延 (その結果、変更が失われる) という、レプリケーションに関するよく知られた問題に悩まされています。暗黙の手動による競合解決このオプションは当社には完全に適用されなくなります。

これらすべての問題には抜本的な解決策が必要であり、私たちはそれらを詳細に分析し始めました。ここでは、SQL Server が主に行うこと、つまりトランザクションについて理解する必要があります。

簡単な取引

応用 SQL プログラマの観点から、アルバムに写真を追加するという最も単純なトランザクションを考えてみましょう。アルバムと写真は別のプレートに保管されます。アルバムには公開フォトカウンターがあります。このようなトランザクションは次のステップに分割されます。

アルバムをキーでロックします。
写真テーブルにエントリを作成します。
写真に公開ステータスがある場合は、アルバムに公開写真カウンターを追加し、レコードを更新してトランザクションをコミットします。

または疑似コードで:

TX.start("Albums", id);
Album album = albums.lock(id);
Photo photo = photos.create(…);

if (photo.status == PUBLIC ) {
    album.incPublicPhotosCount();
}
album.update();

TX.commit();

ビジネストランザクションの最も一般的なシナリオは、データベースからアプリケーションサーバーのメモリにデータを読み取り、何かを変更し、新しい値をデータベースに保存することです。通常、このようなトランザクションでは、いくつかのエンティティやいくつかのテーブルを更新します。

トランザクションの実行時に、別のシステムからの同じデータの変更が同時に発生する可能性があります。たとえば、スパム対策は、ユーザーが何らかの形で疑わしいため、ユーザーの写真はすべて公開すべきではなく、モデレートのために送信する必要があると判断する場合があります。これは、photo.status を別の値に変更し、対応するカウンタをオフにすることを意味します。明らかに、この操作がアプリケーションのアトミック性と競合する変更の分離の保証なしに行われる場合は、次のようになります。 ACIDの場合、結果は必要なものではなくなります。写真カウンターに間違った値が表示されるか、すべての写真がモデレートのために送信されるわけではありません。

XNUMX つのトランザクション内でさまざまなビジネスエンティティを操作する、同様のコードが多数、Odnoklassniki の存在全体にわたって記述されてきました。から NoSQL への移行の経験に基づく結果整合性最大の課題 (および時間の投資) は、データの一貫性を維持するためのコードの開発にあることを私たちは知っています。したがって、新しいストレージの主な要件は、アプリケーションロジックの実際の ACID トランザクションをプロビジョニングすることであると考えました。

その他の、同様に重要な要件は次のとおりです。

データセンターに障害が発生した場合、新しいストレージへの読み取りと書き込みの両方が利用可能でなければなりません。
現在の開発スピードを維持します。つまり、新しいリポジトリを使用する場合、コードの量はほぼ同じである必要があり、リポジトリに何も追加したり、競合を解決したり、セカンダリインデックスを維持したりするためのアルゴリズムを開発する必要はありません。
新しいストレージの速度は、データの読み取り時とトランザクション処理時の両方で非常に高速である必要がありました。つまり、学術的に厳密で普遍的ではあるが、たとえば次のような遅いソリューションは事実上適用できませんでした。 XNUMXフェーズコミット.
自動オンザフライスケーリング。
特殊なハードウェアを購入する必要がなく、通常の安価なサーバーを使用します。
自社開発者によるストレージ開発の可能性。言い換えれば、独自のソリューションまたはオープンソースのソリューション、できれば Java が優先されました。

決断、決断

考えられる解決策を分析した結果、次の XNUMX つのアーキテクチャの選択肢が考えられました。

XNUMX つ目は、任意の SQL サーバーを使用して、必要なフォールトトレランス、スケーリングメカニズム、フェールオーバークラスター、競合解決、および信頼性が高く高速な分散型 ACID トランザクションを実装することです。私たちは、このオプションは非常に簡単ではなく、労働集約的であると評価しました。

XNUMX 番目のオプションは、スケーリング、フェールオーバークラスター、競合解決が実装された既製の NoSQL ストレージを使用し、トランザクションと SQL を自分で実装することです。一見すると、ACID トランザクションはもちろんのこと、SQL を実装する作業さえも、何年もかかる作業のように見えます。しかしその後、私たちが実際に使用している SQL 機能セットは ANSI SQL とはかけ離れていることに気づきました。カサンドラ CQL ANSI SQLからは程遠いです。 CQL をさらに詳しく見てみると、それが私たちが必要としていたものに非常に近いことがわかりました。

カサンドラとCQL

では、Cassandra の何が興味深いのでしょうか。どのような機能があるのでしょうか?

まず、ここではさまざまなデータ型をサポートするテーブルを作成でき、主キーに対して SELECT または UPDATE を実行できます。

CREATE TABLE photos (id bigint KEY, owner bigint,…);
SELECT * FROM photos WHERE id=?;
UPDATE photos SET … WHERE id=?;

レプリカのデータの一貫性を確保するために、Cassandra は次を使用します。クォーラムアプローチ。最も単純なケースでは、これは、同じ行の XNUMX つのレプリカがクラスターの異なるノードに配置されている場合、ノードの大部分 (つまり XNUMX つのうち XNUMX つ) がこの書き込み操作の成功を確認した場合、書き込みは成功したとみなされることを意味します。。読み取り時に大部分のノードがポーリングされて確認された場合、行データは一貫しているとみなされます。したがって、XNUMX つのレプリカを使用すると、XNUMX つのノードに障害が発生した場合でも、完全かつ瞬時のデータ整合性が保証されます。このアプローチにより、さらに信頼性の高いスキームを実装することができました。つまり、常に XNUMX つのレプリカすべてにリクエストを送信し、最も速い XNUMX つのレプリカからの応答を待ちます。この場合、XNUMX 番目のレプリカの遅い応答は破棄されます。応答が遅いノードには、ブレーキ、JVM でのガベージコレクション、Linux カーネルでの直接メモリ再利用、ハードウェア障害、ネットワークからの切断などの重大な問題が発生する可能性があります。ただし、これはクライアントの操作やデータにはまったく影響しません。

XNUMX つのノードに接続し、XNUMX つのノードから応答を受け取るアプローチをといいます。投機: 追加のレプリカのリクエストは、「落ちる」前でも送信されます。

Cassandra のもう XNUMX つの利点は、バッチログです。これは、行った変更のバッチが完全に適用されるか、まったく適用されないかを確認するメカニズムです。これにより、ACID の A (原子性) をすぐに解くことができます。

Cassandra のトランザクションに最も近いものは、いわゆる「軽量トランザクション」。しかし、それらは「本当の」ACID トランザクションからはほど遠いものです。実際、これは次のことを行う機会です。 CAS 強力な Paxos プロトコルを使用したコンセンサスを使用して、XNUMX つのレコードのみのデータを対象とします。したがって、そのようなトランザクションの速度は遅くなります。

カサンドラに欠けていたもの

そのため、実際の ACID トランザクションを Cassandra に実装する必要がありました。これを使用すると、従来の DBMS の他の XNUMX つの便利な機能、つまり、主キーだけでなくデータ選択を実行できる一貫した高速インデックスと、単調自動インクリメント ID の定期的なジェネレーターを簡単に実装できます。

円錐

こうして新しいDBMSが誕生しました円錐、次の XNUMX 種類のサーバーノードで構成されます。

ストレージ – (ほぼ) 標準的な Cassandra サーバーで、ローカルディスクにデータを保存します。データの負荷と量が増加すると、その量は簡単に数十、数百に拡張できます。
トランザクションコーディネーター - トランザクションの実行を保証します。
クライアントは、ビジネス操作を実装し、トランザクションを開始するアプリケーションサーバーです。そのようなクライアントは何千も存在する可能性があります。

すべてのタイプのサーバーは共通クラスターの一部であり、内部 Cassandra メッセージプロトコルを使用して相互に通信し、ゴシップクラスター情報を交換するため。 Heartbeat を使用すると、サーバーは相互障害について学習し、単一のデータスキーマ (テーブル、その構造、レプリケーション) を維持します。パーティショニングスキーム、クラスタトポロジなど。

クライアント

標準ドライバーの代わりに、ファットクライアントモードが使用されます。このようなノードはデータを保存しませんが、リクエスト実行のコーディネーターとして機能します。つまり、クライアント自体がリクエストのコーディネーターとして機能し、ストレージレプリカにクエリを実行し、競合を解決します。これは、リモートコーディネーターとの通信が必要な標準ドライバーよりも信頼性が高く、高速であるだけでなく、リクエストの送信を制御することもできます。クライアント上で開かれているトランザクションの外側で、リクエストはリポジトリに送信されます。クライアントがトランザクションをオープンしている場合、トランザクション内のすべてのリクエストがトランザクションコーディネーターに送信されます。

C*One トランザクションコーディネーター

コーディネーターは、C*One 用に最初から実装したものです。トランザクション、ロック、およびトランザクションが適用される順序を管理します。

サービスされたトランザクションごとに、コーディネーターはタイムスタンプを生成します。後続の各トランザクションは、前のトランザクションよりも大きくなります。 Cassandra の競合解決システムはタイムスタンプ (競合する XNUMX つのレコードのうち、最新のタイムスタンプを持つ方が最新とみなされます) に基づいているため、競合は常に後続のトランザクションを優先して解決されます。したがって、私たちは実装しましたランポートの時計 - 分散システム内の競合を安価に解決する方法。

ロック

確実に分離するために、最も単純な方法であるレコードの主キーに基づく悲観的ロックを使用することにしました。つまり、トランザクションでは、まずレコードをロックし、その後で読み取り、変更、保存する必要があります。コミットが成功した後でのみ、レコードのロックが解除され、競合するトランザクションがそのレコードを使用できるようになります。

このようなロックの実装は、非分散環境では簡単です。分散システムには、主に XNUMX つのオプションがあります。クラスタに分散ロックを実装するか、同じレコードに関係するトランザクションが常に同じコーディネータによって処理されるようにトランザクションを分散するかのいずれかです。

この場合、データは既に SQL のローカルトランザクションのグループに分散されているため、ローカルトランザクショングループをコーディネーターに割り当てることが決定されました。0 つのコーディネーターは 9 から 10 までのトークンを使用してすべてのトランザクションを実行し、19 番目のコーディネーターは XNUMX から XNUMX までのトークンを使用して実行します。等々。その結果、各コーディネータインスタンスがトランザクショングループのマスターになります。

その後、コーディネーターのメモリ内に平凡な HashMap の形式でロックを実装できます。

コーディネーターの障害

XNUMX つのコーディネーターがトランザクションのグループに排他的にサービスを提供するため、トランザクションの XNUMX 回目の実行試行がタイムアウトになるように、コーディネーターの失敗の事実を迅速に判断することが非常に重要です。これを高速かつ信頼性の高いものにするために、完全に接続されたクォーラムハートビートプロトコルを使用しました。

各データセンターは少なくとも XNUMX つのコーディネーターノードをホストします。各コーディネーターは定期的に他のコーディネーターにハートビートメッセージを送信し、その機能と、クラスター内のどのコーディネーターから最後にどのハートビートメッセージを受信したかを通知します。

他のコーディネーターから同様の情報をハートビートメッセージの一部として受信すると、各コーディネーターは、クォーラム原理に基づいて、どのクラスターノードが機能しているか、どのクラスターノードが機能していないかを自分で判断します。つまり、ノード X がクラスター内の過半数のノードから正常な状態に関する情報を受信しているかどうかを判断します。ノード Y からメッセージを受信すると、Y は機能します。逆も同様で、多数派がノード Y からのメッセージが欠落していると報告するとすぐに、Y は拒否します。興味深いのは、クォーラムがノード X にメッセージを受信しなくなったことを通知した場合、ノード X 自体が障害が発生したとみなすことです。

ハートビートメッセージは、20 ミリ秒の周期で 50 秒あたり約 50 回という高頻度で送信されます。 Java では、ガベージコレクターによって発生する一時停止の長さが同等であるため、アプリケーションの応答を 1 ミリ秒以内に保証することは困難です。 G50 ガベージコレクターを使用してこの応答時間を達成することができました。これにより、GC の一時停止期間のターゲットを指定できます。ただし、ごくまれにコレクタの一時停止時間が 200 ミリ秒を超えることがあり、誤った障害検出が発生する可能性があります。これを防ぐために、コーディネーターは、リモートノードからの最初のハートビートメッセージが消えても、リモートノードの障害を報告せず、複数のハートビートメッセージが連続して消えた場合にのみ報告します。これが、XNUMX 年にコーディネーターノードの障害を検出した方法です。 MS。

しかし、どのノードが機能を停止したかをすぐに理解するだけでは十分ではありません。これについては何かをする必要があります。

予約

古典的なスキームには、マスターに障害が発生した場合に、次のいずれかを使用して新しい選挙を開始することが含まれます。ファッショナブルな普遍的アルゴリズム。ただし、このようなアルゴリズムには、時間の収束と選挙プロセス自体の長さに関するよく知られた問題があります。完全に接続されたネットワークでコーディネーターの置換スキームを使用することで、このような追加の遅延を回避することができました。

グループ 50 でトランザクションを実行したいとします。代替スキーム、つまり、メインコーディネーターに障害が発生した場合に、どのノードがグループ 50 でトランザクションを実行するかを事前に決定しておきましょう。私たちの目標は、データセンターに障害が発生した場合でもシステムの機能を維持することです。最初のリザーブは別のデータセンターのノードであり、XNUMX 番目のリザーブは XNUMX 番目のデータセンターのノードであると決定しましょう。このスキームは一度選択されると、クラスターのトポロジーが変更されるまで、つまり新しいノードがクラスターに入るまで変更されません (これは非常にまれに発生します)。古いマスターに障害が発生した場合に新しいアクティブマスターを選択する手順は常に次のようになります。最初のリザーブがアクティブマスターになり、機能が停止した場合は XNUMX 番目のリザーブがアクティブマスターになります。

新しいマスターをアクティブ化するには古いマスターの障害を判断するだけで十分であるため、このスキームはユニバーサルアルゴリズムよりも信頼性が高くなります。

しかし、クライアントはどのマスターが現在動作しているかをどうやって理解するのでしょうか? 50 ミリ秒以内に何千ものクライアントに情報を送信することは不可能です。このマスターが機能していないことをまだ認識していないクライアントがトランザクションを開くリクエストを送信すると、リクエストがタイムアウトになる状況が発生する可能性があります。これを防ぐために、クライアントは投機的にトランザクションを開くリクエストをグループマスターとその両方のリザーブに同時に送信しますが、その時点でアクティブなマスターであるマスターのみがこのリクエストに応答します。クライアントは、トランザクション内のその後のすべての通信をアクティブなマスターとのみ行います。

バックアップマスターは、受信した自分のものではないトランザクションのリクエストを未生成のトランザクションのキューに入れ、しばらくの間保存されます。アクティブなマスターが停止すると、新しいマスターはそのキューからトランザクションを開くリクエストを処理し、クライアントに応答します。クライアントがすでに古いマスターとのトランザクションを開始している場合、XNUMX 番目の応答は無視されます (そして当然のことながら、そのようなトランザクションは完了せず、クライアントによって繰り返されます)。

トランザクションの仕組み

クライアントがコーディネーターに、これこれの主キーを持つこれこれのエンティティのトランザクションを開くリクエストを送信したとします。コーディネーターはこのエンティティをロックし、メモリ内のロックテーブルに置きます。必要に応じて、コーディネーターはこのエンティティをストレージから読み取り、結果のデータをコーディネーターのメモリ内のトランザクション状態に保存します。

クライアントがトランザクション内のデータを変更したい場合、エンティティを変更するリクエストをコーディネーターに送信し、コーディネーターは新しいデータをメモリ内のトランザクションステータステーブルに配置します。これで録音が完了します。ストレージへの録音は行われません。

クライアントがアクティブなトランザクションの一部として独自の変更データを要求すると、コーディネーターは次のように動作します。

ID がすでにトランザクション内にある場合、データはメモリから取得されます。
メモリ内に ID がない場合は、欠落しているデータがストレージノードから読み取られ、既にメモリ内にあるデータと結合され、結果がクライアントに渡されます。

したがって、クライアントは自身の変更を読み取ることができますが、これらの変更はコーディネーターのメモリにのみ保存され、まだ Cassandra ノードには存在しないため、他のクライアントには表示されません。

クライアントがコミットを送信すると、サービスのメモリにあった状態がコーディネーターによってログに記録されたバッチに保存され、ログに記録されたバッチとして Cassandra ストレージに送信されます。ストアは、このパッケージがアトミックに (完全に) 適用されることを保証するために必要なすべてを実行し、コーディネーターに応答を返します。コーディネーターはロックを解放し、クライアントへのトランザクションの成功を確認します。

ロールバックするには、コーディネーターはトランザクション状態によって占有されているメモリを解放するだけで済みます。

上記の改善の結果として、ACID 原則を実装しました。

原子性。これは、トランザクションがシステムに部分的に記録されないこと、つまりサブオペレーションがすべて完了するか、何も完了しないかのどちらかであることを保証します。私たちは、Cassandra のログに記録されたバッチを通じてこの原則を遵守しています。
一貫性。定義上、成功した各トランザクションは有効な結果のみを記録します。トランザクションを開いて操作の一部を実行した後、結果が無効であることが判明した場合は、ロールバックが実行されます。
分離。トランザクションが実行されるとき、同時トランザクションがその結果に影響を与えるべきではありません。競合するトランザクションは、コーディネーターの悲観的ロックを使用して分離されます。トランザクション外の読み取りの場合、分離原則は Read Committed レベルで観察されます。
安定性。システムのブラックアウトやハードウェア障害など、下位レベルの問題に関係なく、正常に完了したトランザクションによって行われた変更は、操作が再開されたときにも保持される必要があります。

インデックスによる読み取り

簡単な表を見てみましょう。

CREATE TABLE photos (
id bigint primary key,
owner bigint,
modified timestamp,
…)

これには、ID (主キー)、所有者、および変更日が含まれます。非常に簡単なリクエストを行う必要があります。「最後の日」の変更日を持つ所有者のデータを選択します。

SELECT *
WHERE owner=?
AND modified>?

このようなクエリを迅速に処理するには、従来の SQL DBMS では列 (所有者、変更済み) ごとにインデックスを構築する必要があります。 ACID 保証があるため、これを非常に簡単に行うことができます。

C*One のインデックス

レコード ID が主キーである写真を含むソーステーブルがあります。

インデックスの場合、C*One は元のテーブルのコピーである新しいテーブルを作成します。キーはインデックス式と同じであり、ソーステーブルのレコードの主キーも含まれます。

これで、「最終日の所有者」のクエリを別のテーブルからの選択として書き直すことができます。

SELECT * FROM i1_test
WHERE owner=?
AND modified>?

ソーステーブル写真とインデックステーブル i1 のデータの一貫性は、コーディネーターによって自動的に維持されます。データスキーマのみに基づいて、変更を受信すると、コーディネーターは変更を生成し、メインテーブルだけでなくコピーにも変更を保存します。インデックステーブルに対して追加のアクションは実行されず、ログは読み取られず、ロックも使用されません。つまり、インデックスを追加してもリソースはほとんど消費されず、変更の適用速度には実質的に影響がありません。

ACID を使用すると、SQL のようなインデックスを実装できました。これらは一貫性があり、スケーラブルで、高速で、構成可能であり、CQL クエリ言語に組み込まれています。インデックスをサポートするためにアプリケーションコードを変更する必要はありません。すべては SQL と同じくらい簡単です。そして最も重要なことは、インデックスは元のトランザクションテーブルへの変更の実行速度に影響を与えないことです。

どうしたの

当社はXNUMX年前にC*Oneを開発し、商用運用を開始しました。

最終的に何が得られたのでしょうか？ソーシャルネットワークで最も重要な種類のデータの 20 つである写真処理およびストレージサブシステムの例を使用して、これを評価してみましょう。私たちは写真の本体について話しているのではなく、あらゆる種類のメタ情報について話しています。現在、Odnoklassniki にはそのようなレコードが約 80 億件あり、システムは 8 秒あたり XNUMX 万件の読み取りリクエストを処理し、データ変更に関連する XNUMX 秒あたり最大 XNUMX 件の ACID トランザクションを処理します。

レプリケーション係数 = 1 (ただし RAID 10) で SQL を使用した場合、写真のメタ情報は、Microsoft SQL Server を実行する 32 台のマシン (+ 11 個のバックアップ) からなる高可用性クラスターに保存されました。バックアップを保存するために 10 台のサーバーも割り当てられました。合計50台の高級車。同時に、システムは予備なしで定格負荷で動作しました。

新しいシステムに移行した後、レプリケーション係数 = 3、つまり各データセンターにコピーを受け取りました。このシステムは、63 台の Cassandra ストレージノードと 6 台のコーディネーターマシン、合計 69 台のサーバーで構成されています。ただし、これらのマシンははるかに安価で、総コストは SQL システムのコストの約 30% です。同時に、負荷は 30% に維持されます。

C*One の導入により、レイテンシーも減少しました。SQL では、書き込み操作に約 4,5 ミリ秒かかりました。 C*One の場合 - 約 1,6 ミリ秒。トランザクション期間は平均 40 ミリ秒未満、コミットは 2 ミリ秒で完了し、読み取りおよび書き込み期間は平均 2 ミリ秒です。 99 パーセンタイル - わずか 3 ～ 3,1 ミリ秒、タイムアウト数は 100 分の XNUMX に減少 - すべては推測が広く使用されたためです。

現在、ほとんどの SQL Server ノードは廃止されており、新しい製品は C*One のみを使用して開発されています。 C*One をクラウドで動作するように調整しましたワンクラウドこれにより、新しいクラスターの展開を高速化し、構成を簡素化し、運用を自動化することが可能になりました。ソースコードがなければ、これを行うことははるかに困難で面倒になります。

現在、他のストレージ施設をクラウドに移行することに取り組んでいますが、それはまったく別の話です。

出所： habr.com

NewSQL = NoSQL+ACID