HighLoad++、Mikhail Tyulenev (MongoDB): 因果関係の一貫性: 理論から実践まで

次回の HighLoad++ カンファレンスは、6 年 7 月 2020 日と XNUMX 日にサンクトペテルブルクで開催されます。
詳細とチケット リンク。 HighLoad++ シベリア 2019。ホール「クラスノヤルスク」。 25月12日、00時。 論文や プレゼンテーション.

実際の要件が理論と矛盾し、商用製品にとって重要な側面が考慮されていない場合があります。 この講演では、商用製品の要件に基づいた学術研究に基づいて、因果整合性コンポーネントを作成するためのさまざまなアプローチを選択し、組み合わせるプロセスについて説明します。 リスナーは、論理クロック、依存関係の追跡、システム セキュリティ、クロック同期に対する既存の理論的アプローチ、および MongoDB が特定のソリューションに落ち着いた理由について学びます。

ミハイル・チュレネフ（以下、MT）： – 因果関係の一貫性について話します。これは、MongoDB で取り組んだ機能です。 私は分散システムのグループで働いており、それを実行したのは約 XNUMX 年前です。

この機能はかなり詳しく研究されてきたため、その過程で多くの学術研究に精通する必要がありました。 どの実稼働アプリケーションにもおそらく存在する非常に特殊な要件のため、実稼働データベースで必要とされる内容に適合する記事は XNUMX つもないことが判明しました。

学術研究の消費者として、私たちが学術研究から何かを準備し、便利で安全に使用できる既製の料理としてユーザーに提供できる方法について説明します。

因果関係の一貫性。 概念を定義しましょう

まず、因果的一貫性とは何かということを一般的な言葉で言いたいと思います。 登場人物は XNUMX 人です - レナードとペニー (TV シリーズ「ビッグバン セオリー」):

ペニーがヨーロッパにいて、レナードが彼女にサプライズパーティーを開きたいと考えているとします。 そして、彼女を友達リストから外し、すべての友達にフィードで「ペニーを幸せにしましょう!」と最新情報を送信する以上に良いことは思いつきません。 （彼女はヨーロッパにいますが、眠っている間、彼女はこのすべてを見ていませんし、そこにいないので見ることもできません）。 最終的に、彼女はこの投稿を削除し、フィードから削除し、アクセスを復元したため、何も気付かれず、スキャンダルもなくなりました。
これはこれで十分ですが、システムが分散されており、少し問題が発生したと仮定してみましょう。 たとえば、イベントに因果関係がない場合、この投稿が公開された後にペニーのアクセス制限が発生した可能性があります。 実際、これはビジネス機能を実行するために因果関係の一貫性が必要な場合の例です (この場合)。

実際、これらはデータベースの非常に重要なプロパティであり、サポートしている人はほとんどいません。 モデルの話に移りましょう。

一貫性モデル

データベースの整合性モデルとは正確には何ですか? これらは、クライアントがどのようなデータをどのような順序で受信できるかについて、分散システムが提供する保証の一部です。

原則として、すべての整合性モデルは、分散システムが、たとえばラップトップ上の XNUMX つのノードで実行されるシステムとどの程度似ているかによって決まります。 これは、地理的に分散された何千もの「ノード」上で実行されるシステムがラップトップにどれほど似ているかを示しており、ラップトップではこれらすべてのプロパティが原則として自動的に実行されます。

したがって、整合性モデルは分散システムにのみ適用されます。 以前に存在し、同じ垂直スケーリングで動作していたすべてのシステムでは、このような問題は発生しませんでした。 バッファ キャッシュが XNUMX つあり、すべてが常にそこから読み取られました。

モデルストロング

実際、最初のモデルはストロング (または、よく呼ばれるライズ アビリティ ライン) です。 これは、すべての変更が発生したことが確認されると、その変更がシステムのすべてのユーザーに表示されるようにする一貫性モデルです。

これにより、データベース内のすべてのイベントのグローバルな順序が作成されます。 これは非常に強い一貫性のプロパティであり、一般に非常に高価です。 ただし、サポートは非​​常に充実しています。 非常に高価で遅いだけで、めったに使用されないだけです。 これを立ち上がり能力といいます。

Spanner では、外部一貫性と呼ばれる、別の強力なプロパティがサポートされています。 それについては少し後で話します。

因果関係

次は Causal です。これはまさに私が話したものです。 Strong と Causal の間にはさらにいくつかのサブレベルがありますが、これについては説明しませんが、それらはすべて Causal に要約されます。 これは、すべてのモデルの中で最も強力であり、ネットワークまたはパーティションが存在する場合の一貫性が最も強いため、重要なモデルです。

因果関係とは、実際には、出来事が因果関係によって接続されている状況です。 非常に多くの場合、それらはクライアントの観点から読む権利があると認識されます。 クライアントがいくつかの値を観察した場合、過去の値を見ることはできません。 彼はすでに接頭辞の読み方を見始めています。 結局のところ、すべて同じことになります。
整合性モデルとしての因果関係は、サーバー上のイベントの部分的な順序付けであり、すべてのクライアントからのイベントが同じ順序で観察されます。 この場合は、レナードとペニーです。

最終的な

XNUMX 番目のモデルは結果整合性です。 これは絶対にすべての分散システムがサポートするものであり、まったく意味のある最小限のモデルです。 これは次のことを意味します。データに何らかの変更があった場合、ある時点でそれらの変更は一貫性を持つようになります。

そのような瞬間、彼女は何も言いません。そうでなければ、彼女は外部の一貫性に変わるでしょう - それは完全に別の話になるでしょう。 それにもかかわらず、これは非常に人気のある、最も一般的なモデルです。 デフォルトでは、分散システムのすべてのユーザーが結果整合性を使用します。

いくつかの比較例を示したいと思います。

これらの矢印は何を意味するのでしょうか?

• レイテンシー。 整合性の強度が増加するにつれて、明白な理由から整合性の強度も大きくなります。より多くのレコードを作成し、クラスターに参加しているすべてのホストとノードからデータがすでに存在するという確認を取得する必要があります。 したがって、結果整合性が最も早い答えになります。原則として、結果整合性をメモリにコミットすることもでき、原理的にはこれで十分だからです。
• 可用性。 これを、ネットワークの切断、分断、または何らかの障害が発生したときにシステムが応答する能力として理解すると、一貫性モデルが低下するにつれて耐障害性が向上します。これは、XNUMX つのホストが同時に稼働していれば十分であるためです。時間によって何らかのデータが生成されます。 最終的な整合性は、データについてはまったく保証しません。データは何でも構いません。
• 異常。 同時に、当然、異常の数も増加します。 強整合性では、それらはほとんど存在しないはずですが、結果的整合性では何でも構いません。 異常が含まれている場合に、なぜ結果整合性を選択するのでしょうか?という疑問が生じます。 答えは、結果整合性モデルが適用可能であり、異常はたとえば短期間に存在するということです。 ウィザードを使用して、一貫したデータを読み取ることができます。 多くの場合、強力な整合性モデルを使用できます。 実際にはこれは機能し、多くの場合、異常の数は時間内に制限されます。

CAP定理

一貫性、可用性という言葉を見たとき、何を思い浮かべますか? そう、CAP定理です！ 今、私はこの通説を払拭したいと思っています... それは私ではありません - 素晴らしい記事と素晴らしい本を書いたマルティン・クレップマンです。

CAP 定理は、一貫性、可用性、パーティションのいずれか 2000 つを選択し、XNUMX つを選択することはできないという XNUMX 年代に定式化された原則です。 それはある原則でした。 それは数年後、ギルバートとリンチによって定理として証明されました。 その後、これがマントラとして使用され始め、システムは CA、CP、AP などに分割され始めました。

この定理は実際に次のケースで証明されました... まず、可用性は 0 から数百までの連続値ではないと考えられていました (100 - システムは「停止」、XNUMX - すぐに応答します。私たちはそのように考えることに慣れています)。ただし、アルゴリズムのプロパティとして、すべての実行でデータが返されることが保証されます。

応答時間についてはまったく言及されていません。 100 年後にデータを返すアルゴリズムがあります。これは、CAP 定理の一部であり、利用可能な非常に素晴らしいアルゴリズムです。
XNUMX 番目: これらの変更はサイズ変更可能であるにもかかわらず、同じキーの値の変更について定理が証明されました。 これは、モデルが結果整合性、強整合性 (おそらく) 異なるため、実際にはほとんど使用されていないことを意味します。

これは一体何のためにあるのでしょうか？ さらに、CAP 定理は証明されたそのままの形では実際には適用できず、めったに使用されません。 理論的な形では、何らかの形ですべてを制限します。 直感的には正しいが、一般に証明されていない特定の原理が判明しました。

因果関係の一貫性が最も強力なモデルである

現在起こっていることは、パーティションを使用することで一貫性と可用性の XNUMX つをすべて実現できるということです。 特に、因果的整合性は最も強力な整合性モデルであり、パーティション (ネットワークの中断) が存在する場合でも機能します。 それが非常に興味深い理由であり、それが私たちがそれを取り上げた理由です。

まず、アプリケーション開発者の作業が簡素化されます。 特に、サーバーからの優れたサポートの存在により、あるクライアント内で発生するすべてのレコードが別のクライアントに同じ順序で到着することが保証されます。 第二に、パーティションに耐えることができます。

MongoDB 内部キッチン

昼食であることを思い出し、キッチンに移動します。 MongoDB というデータベースを初めて聞く人のために、システムモデル、つまり MongoDB について説明します。

MongoDB (以下、「MongoDB」と呼びます) は、水平スケーリング、つまりシャーディングをサポートする分散システムです。 また、各シャード内ではデータの冗長性、つまりレプリケーションもサポートされます。

MongoDB (リレーショナル データベースではありません) のシャーディングは自動バランシングを実行します。つまり、ドキュメントの各コレクション (リレーショナル データの用語では「テーブル」) が断片に分割され、サーバーがそれらをシャード間で自動的に移動します。

クライアントのリクエストを分散するクエリ ルーターは、それが動作するクライアントです。 どのデータがどこにあるかをすでに認識しており、すべてのリクエストを正しいシャードに送信します。

もう XNUMX つの重要な点は、MongoDB は単一のマスターであるということです。 プライマリが XNUMX つあり、それに含まれるキーをサポートするレコードを取得できます。 マルチマスター書き込みはできません。

リリース 4.2 を作成しました - 新しい興味深いものがそこに登場しました。 特に、Lucene、つまり検索、つまり実行可能な Java を Mongo に直接挿入し、Elastica と同様に Lucene を介して検索を実行できるようになりました。

そして彼らは新しい製品である Charts を作成しました。これは Atlas (Mongo 独自のクラウド) でも利用できます。 無料利用枠があるので、試してみることができます。 データ視覚化、非常に直感的なチャートがとても気に入りました。

成分 因果関係

数えてみたら、このトピックに関してレスリー ランパートから出版された記事が約 230 件ありました。 さて、私の記憶に基づいて、これらの資料の一部を皆さんにお伝えします。

すべては、1970 年代に書かれたレスリー ランパートの記事から始まりました。 ご覧のとおり、このトピックに関するいくつかの研究はまだ進行中です。 現在、分散システムの開発に関連して、因果的一貫性が注目されています。

制限

どのような制限がありますか? 生産システムが課す制限は学術論文に存在する制限とは大きく異なるため、これは実際に重要なポイントの XNUMX つです。 多くの場合、それらは非常に人工的です。

• まず、すでに述べたように、「MongoDB」は単一マスターです (これにより非常に単純化されます)。
• システムは約 10 個のシャードをサポートする必要があると考えています。 この値を明示的に制限するようなアーキテクチャ上の決定を行うことはできません。
• クラウドはありますが、バイナリをダウンロードしてラップトップで実行すると、すべてがうまく動作する機会がまだあるはずだと想定しています。
• 私たちは、Research がめったに想定していないことを想定しています。それは、外部クライアントがやりたいことは何でもできるということです。 MongoDB はオープンソースです。 したがって、クライアントは非常に賢くて怒っている可能性があり、すべてを壊したいと思う可能性があります。 私たちは、ビザンチンのフェイロールが起源である可能性があると推測しています。
• 境界の外側にある外部クライアントの場合、重要な制限があります。この機能が無効になっている場合、パフォーマンスの低下は観察されません。
• もう XNUMX つの点は、一般に反学術的です。つまり、以前のバージョンと将来のバージョンの互換性です。 古いドライバーは新しい更新をサポートする必要があり、データベースは古いドライバーをサポートする必要があります。

一般に、これらすべてに制限が課せられます。

因果的一貫性のコンポーネント

次に、いくつかのコンポーネントについて説明します。 一般に因果関係の一貫性を考慮すると、ブロックを選択できます。 私たちは、特定のブロックに属する作品から選択しました。依存関係の追跡、クロックの選択、これらのクロックをどのように同期させるか、セキュリティをどのように確保するか、これが私が話す内容の大まかな概要です。

完全な依存関係の追跡

なぜ必要なのでしょうか? そのため、データがレプリケートされるとき、各レコード、各データ変更には、どの変更に依存するかについての情報が含まれます。 最初の単純な変更は、レコードを含む各メッセージに以前のメッセージに関する情報が含まれる場合です。

この例では、中括弧内の数字がレコード番号です。 値を含むこれらのレコード全体が転送されることもあれば、一部のバージョンが転送されることもあります。 肝心なのは、各変更には前の変更に関する情報が含まれているということです (明らかに、すべての変更がそれ自体の中に含まれています)。

なぜこのアプローチ (完全な追跡) を使用しないことにしたのでしょうか? 明らかに、このアプローチは非現実的であるため、ソーシャル ネットワークへの変更は、そのソーシャル ネットワークに対する以前のすべての変更に依存し、更新ごとに Facebook や VKontakte が転送されることになります。 それにもかかわらず、完全な依存関係追跡については多くの研究が行われています – これらはソーシャル ネットワーク以前のものであり、状況によっては実際に機能します。

明示的な依存関係の追跡

次のものはさらに制限されています。 ここでは情報の転送も考慮されますが、明らかに依存しているもののみです。 何が決まるかは、原則としてアプリケーションによって決定される内容に依存します。 データがレプリケートされると、クエリは以前の依存関係が満たされた場合、つまり依存関係が示された場合にのみ応答を返します。 これが、因果関係の一貫性が機能する仕組みの本質です。

彼女は、レコード 5 がレコード 1、2、3、4 に依存していることを確認しました。したがって、以前のすべての変更がすでにデータベースを通過しているときに、クライアントがペニーのアクセス決定によって行われた変更にアクセスできるようになるまで待機します。

情報が多すぎるため、作業が遅くなる可能性があるため、これも私たちには適していません。 別のアプローチもあります...

ランポートの時計

彼らはとても古いです。 Lamport Clock は、これらの依存関係が Lamport Clock と呼ばれるスカラー関数に折り畳まれることを意味します。

スカラー関数は抽象的な数値です。 それはしばしば論理時間と呼ばれます。 イベントが発生するたびに、このカウンターは増加します。 現在プロセスに認識されているカウンターが各メッセージを送信します。 プロセスが同期していない可能性があり、まったく異なる時間が発生する可能性があることは明らかです。 それにも関わらず、システムは何らかの方法でそのようなメッセージの送信によりクロックのバランスをとります。 この場合はどうなるのでしょうか?

明確にするために、その大きなシャードを XNUMX つに分割しました。友人は、コレクションの一部を含む XNUMX つのノードに存在でき、フィードは、このコレクションの一部を含む別のノードに存在できます。 彼らがどのようにしてラインから外れることができるかは明らかですか？ 最初のフィードには「複製されました」と表示され、次に「友達」と表示されます。 Friends コレクション内の Friends の依存関係も配信されるまでフィードが表示されないという何らかの保証をシステムが提供しない場合、まさに私が述べた状況が発生します。

フィードのカウンター時間が論理的にどのように増加するかがわかります。

したがって、このランポート クロックと因果関係の一貫性 (ランポート クロックで説明) の主な特性は次のとおりです。イベント A と B があり、イベント B がイベント A* に依存する場合、イベント A の LogicalTime は より小さいということになります。イベント B からの LogicalTime。

* 時々彼らは、A は B の前に起こった、つまり A は B の前に起こったとも言います。これは、一般的に起こった一連の出来事全体を部分的に順序付ける特定の関係です。

その逆は正しくありません。 これは実際には、Lamport Clock の主な欠点の XNUMX つです - 不完全な順序です。 同時のイベント、つまり、(A が B の前に起こった) も (A が B の前に起こった) も起こらないイベントについての概念があります。 例としては、レナードが同時に他の人を友達として追加することが挙げられます（レナードではなくシェルドンなど）。
これは、Lamport クロックを扱うときによく使用されるプロパティです。Lamport クロックは特に関数を調べ、そこからおそらくこれらのイベントが依存していると結論付けます。 なぜなら、一方向は正しいからです。つまり、LogicalTime A が LogicalTime B より小さい場合、B は A より前に発生することはできません。 それ以上であれば、おそらく。

ベクトルクロック

ランポート クロックを論理的に発展させたものがベクトル クロックです。 それらは、ここにある各ノードが独自の個別のクロックを含み、ベクトルとして送信されるという点で異なります。
この場合、ベクトルの 1 番目のインデックスがフィードを担当し、ベクトルの最初のインデックスがフレンド (これらの各ノード) を担当していることがわかります。 そして今、それらは増加します: 書き込み時に「フィード」のゼロインデックスが増加します - 2、3、XNUMX:

なぜベクトルクロックが優れているのでしょうか? なぜなら、どのイベントが同時に発生し、それらが異なるノードでいつ発生するかを把握できるからです。 これは、MongoDB のようなシャーディング システムにとって非常に重要です。 しかし、私たちはこれを選択しませんでした。それは素晴らしいことですし、うまく機能し、おそらく私たちに合っているでしょう...

10 個のシャードがある場合、圧縮したり別の方法を考え出したりしたとしても、10 個のコンポーネントを転送することはできません。ペイロードは依然としてこのベクトル全体の体積よりも数倍小さくなります。 したがって、私たちは歯を食いしばってこのアプローチを放棄し、別のアプローチに移りました。

スパナ TrueTime。 原子時計

スパナーについての話があるだろうと言いました。 これは XNUMX 世紀らしいクールなものです。原子時計、GPS 同期です。

どういう考えですか？ 「Spanner」は、最近人々が利用できるようになった Google システムです (SQL が追加されました)。 各トランザクションにはタイムスタンプが付いています。 時間が同期*されているため、各イベントに特定の時間を割り当てることができます。原子時計には待機時間があり、その後、別の時間が「発生」することが保証されます。

したがって、単にデータベースに書き込み、一定時間待機するだけで、イベントのシリアル化可能性が自動的に保証されます。 彼らは原理的に想像できる最も強力な一貫性モデルを持っています - それは外部一貫性です。

* これが Lampart クロックの主な問題です。分散システムではクロックは決して同期しません。 これらは分岐する可能性があり、NTP を使用しても、依然としてうまく機能しません。 「Spanner」には原子時計が搭載されており、同期はマイクロ秒単位だそうです。

なぜ選ばなかったのでしょうか？ 当社では、ユーザーが原子時計を内蔵していることを想定していません。 これらが登場すると、すべてのラップトップに組み込まれ、ある種の非常にクールな GPS 同期が行われることになります。その場合はそうです...しかし、今のところ考えられる最善のものは、アマゾン、ベース ステーションです。マニア向けです...そこで、他の時計を使用しました。 。

ハイブリッドクロック

これは実際に、MongoDB で因果関係の一貫性を確保する際にチェックされることです。 それらはどのようにハイブリッドになっているのでしょうか？ ハイブリッドはスカラー値ですが、次の XNUMX つのコンポーネントがあります。

• XNUMX つ目は Unix エポック (「コンピューター世界の始まり」から何秒が経過したか) です。
• 32 番目は何らかの増分で、これも XNUMX ビット unsigned int です。

実はそれだけです。 このアプローチがあります。時間を担当する部分は常に時計と同期しています。 更新が発生するたびに、この部分はクロックと同期され、時刻は常に多かれ少なかれ正確であることがわかり、インクリメントにより、同じ時点で発生したイベントを区別できるようになります。

これが MongoDB にとって重要な理由は何ですか? それは、特定の時点で何らかのバックアップ レストランを作成できるためです。つまり、イベントは時間によってインデックス付けされます。 これは、特定のイベントが必要な場合に重要です。 データベースの場合、イベントは一定の時間間隔で発生するデータベース内の変更です。

一番大切な理由をあなただけに教えます（誰にも言わないでください）！ これは、整理されたインデックス付きデータが MongoDB OpLog でどのように見えるかという理由からです。 OpLog は、データベース内のすべての変更を完全に含むデータ構造です。変更はまず OpLog に送られ、レプリケートされた日付またはシャードの場合は次にストレージ自体に適用されます。

これが主な理由でした。 ただし、データベースの開発には実際的な要件もあります。つまり、データベースはシンプルである必要があります。つまり、コードが少なく、書き換えやテストが必要な壊れた部分ができるだけ少ないことです。 私たちの oplog がハイブリッド クロックによってインデックス付けされていたという事実は非常に役立ち、正しい選択をすることができました。 それは本当に功を奏し、どういうわけか魔法のように最初のプロトタイプが完成しました。 とてもかっこよかったです！

クロック同期

科学文献にはいくつかの同期方法が記載されています。 XNUMX つの異なるシャードがある場合の同期について話しています。 レプリカ セットが XNUMX つある場合は、同期の必要はありません。これは「単一マスター」です。 すべての変更がそこに入る OpLog があります。この場合、すべてはすでに「Oplog」自体で順番に並べられています。 ただし、XNUMX つの異なるシャードがある場合は、時間の同期が重要になります。 ここで、ベクトル クロックがさらに役に立ちました。 しかし、私たちにはそれらがありません。

XNUMX つ目は「Heartbeats」です。 単位時間ごとに発生するいくつかの信号を交換することが可能です。 しかし、ハートビートが遅すぎるため、クライアントにレイテンシーを提供できません。

本当の時間というのは、もちろん素晴らしいものです。 しかし、繰り返しますが、これはおそらく未来のことです...Atlas ではすでに実行できますが、高速な「Amazon」時刻同期装置がすでに存在します。 しかし、誰もが利用できるわけではありません。

うわさ話は、すべてのメッセージに時間が含まれる場合です。 これは私たちが使用しているものとほぼ同じです。 ノード間のすべてのメッセージ、ドライバー、データ ノード ルーターなど、MongoDB のすべてはある種の要素、つまり動作するクロックを含むデータベース コンポーネントです。 どこにいてもハイブリッドな時間の意味が伝わってきます。 64ビット？ これにより、これが可能になります。

すべてはどのように連携して機能するのでしょうか?

ここでは、少しわかりやすくするために、レプリカ セットを XNUMX つ取り上げます。 プライマリとセカンダリがあります。 セカンダリはレプリケーションを実行しますが、必ずしもプライマリと完全に同期しているわけではありません。

特定の時間値で「プライマリ」への挿入が発生します。 この挿入により、内部カウントが最大値の場合は 11 ずつ増加します。 または、クロック値をチェックし、クロック値が大きい場合はクロックに同期します。 これにより、時間ごとに整理することができます。

彼が録音を行った後、重要な瞬間が起こります。 クロックは「MongoDB」にあり、「Oplog」に書き込む場合にのみインクリメントされます。 これはシステムの状態を変更するイベントです。 すべての古典的な記事では、イベントはメッセージがノードに到達したときとみなされます。つまり、メッセージが到着しました。これは、システムの状態が変化したことを意味します。

これは、研究中に、このメッセージがどのように解釈されるかが完全には明らかではないという事実によるものです。 それが「Oplog」に反映されない場合、それはいかなる形でも解釈されず、システムの状態の変化は「Oplog」の単なるエントリにすぎないことを私たちは確信しています。 これにより、すべてが簡素化されます。モデルによってそれが簡素化され、XNUMX つのレプリカ セット内でそれを整理できるようになり、その他多くの便利なことが可能になります。

「Oplog」にすでに書き込まれている値が返されます。「Oplog」にはすでにこの値が含まれており、その時刻は 12 であることがわかります。ここで、たとえば、読み取りが別のノード (セカンダリ) から開始され、afterClusterTime が送信されます。メッセージ。 彼はこう言います。「少なくとも 12 時以降、または XNUMX 時の間に起こったことはすべて必要です」（上の写真を参照）。

これは、因果的一貫性 (CAT) と呼ばれるものです。 理論的には、これは時間の一部であるという概念があり、それ自体は一貫しています。 この場合、これは時間 12 で観察されたシステムの状態であると言えます。

ここにはまだ何もありません。これは、セカンダリがプライマリからデータをレプリケートする必要がある場合の状況をシミュレートするためです。 彼は待ちます...そして今、データが到着しました - 彼はこれらの値を返します。

それがすべての仕組みです。 ほとんど。

「ほぼ」とはどういう意味ですか? これがどのように機能するかを読んで理解した人がいると仮定しましょう。 ClusterTime が発生するたびに内部論理クロックが更新され、次のエントリが 20 ずつ増加することがわかりました。 この関数には 64 行かかります。 この人が XNUMX ビットの最大の数値から XNUMX を引いた数値を送信したとします。

なぜ「マイナスXNUMX」なのか？ 内部クロックがこの値に置き換えられるため (明らかに、これは可能な最大値であり、現在時刻よりも大きくなります)、「Oplog」にエントリが発生し、クロックは別の単位でインクリメントされます。最大値 (単純にすべての単位があり、他に行く場所がない)、unsaint ints) である必要があります。

この後、システムはまったくアクセスできなくなることは明らかです。 荷降ろしと清掃のみが可能で、多くの手作業が必要です。 完全な可用性:

さらに、これが別の場所にレプリケートされると、クラスター全体が単にダウンします。 誰でも非常に迅速かつ簡単に組織できる、絶対に受け入れられない状況です。 したがって、私たちはこの瞬間が最も重要な瞬間の一つであると考えました。 それを防ぐにはどうすればよいでしょうか？

私たちの方法は、clusterTime に署名することです

これは、メッセージ内 (青いテキストの前) で送信される方法です。 ただし、署名 (青色のテキスト) の生成も開始しました。

署名は、データベース内の安全な境界内に保存されているキーによって生成されます。 それ自体が生成および更新されます (ユーザーにはそれについて何も表示されません)。 ハッシュが生成され、各メッセージは作成時に署名され、受信時に検証されます。
おそらく人々の心の中には、「これによってどれくらい速度が低下するのでしょうか?」という疑問が生じるでしょう。 特にこの機能がない場合には、すぐに機能するはずだと言いました。

この場合、因果的一貫性を使用するとはどういう意味ですか? これは、afterClusterTime パラメーターを表示するためです。 これがなければ、とにかく単に値を渡すことになります。 バージョン 3.6 以降、噂話は常に機能します。

署名を継続的に生成したままにしておくと、機能がない場合でもシステムの速度が低下し、アプローチと要件を満たしていません。 それで、私たちは何をしたのでしょうか？

早くやれよ！

非常に単純なことですが、そのトリックは興味深いものです。おそらく誰かが興味を持ってくれるので、それを共有します。
署名されたデータを保存するハッシュがあります。 すべてのデータはキャッシュを通過します。 キャッシュは特定の時刻ではなく、範囲に署名します。 何らかの値が到着すると、Range を生成し、最後の 16 ビットをマスクして、この値に署名します。

このような署名を受け取ることで、システムを (相対的に) 65 倍高速化します。 これはうまく機能し、実験を行ったところ、逐次更新を行うと実際に時間が 10 万分の XNUMX に短縮されました。 両者が対立している場合、これが機能しないことは明らかです。 しかし、ほとんどの実際のケースでは機能します。 Range 署名と署名を組み合わせることで、セキュリティの問題が解決されました。

私たちは何を学びましたか？

このことから私たちが学んだ教訓は次のとおりです。

• 興味深いものがたくさんあるので、資料、物語、記事を読む必要があります。 何らかの機能に取り組むとき (特に今、トランザクションを行ったときなど)、読んで理解する必要があります。 時間はかかりますが、自分がどこにいるのかが明確になるので、実際には非常に便利です。 私たちは何も新しいことを思いついたようには見えませんでした。ただ材料を取り出しただけです。

  一般に、学術会議があるとき（たとえばシグモン）、考え方には一定の違いがあり、誰もが新しいアイデアに集中します。 私たちのアルゴリズムの何が新しいのでしょうか? ここには特に新しいことはありません。 むしろ目新しさは、既存のアプローチを融合した方法にあります。 したがって、まずはランパートをはじめとする古典を読むことだ。

• 本番環境では、要件はまったく異なります。 皆さんの多くは、抽象的な空間にある「球状」データベースではなく、可用性、遅延、フォールト トレランスに問題がある通常の現実のものに直面していると思います。
• 最後に、さまざまなアイデアを検討し、いくつかのまったく異なる記事を XNUMX つのアプローチに統合する必要がありました。 たとえば、署名に関するアイデアは一般に、Paxos プロトコルを考慮した記事から来ています。Paxos プロトコルは、非ビザンチン フェイルの場合は認証プロトコルの内側にあり、ビザンチン フェイルの場合は認証プロトコルの外側にあります... 一般に、これはまさに私たちが行っているものです。結局やってしまった。

  ここにはまったく新しいものはありません！ しかし、すべてを混ぜ合わせるとすぐに...卵、マヨネーズ、キュウリはすでに発明されているため、オリヴィエサラダのレシピはナンセンスであると言っているのと同じです...ほぼ同じ話です。

これで終わります。 ありがとう！

質問

会場からの質問（以下B）： – ミハイルさん、レポートありがとうございます！ 時間に関する話題は興味深いです。 あなたはゴシップを使用しています。 彼らは、誰もが自分の時間を持っており、誰もが自分の現地時間を知っていると言いました。 私の理解では、ドライバーが存在します。ドライバー、クエリ プランナー、シャードを備えた多くのクライアントが存在する可能性があります... そして、突然不一致が発生した場合、システムはどうなるでしょうか。誰かがそれが問題であると判断したのです。 XNUMX分前、XNUMX分遅れの人はいますか？ 私たちはどこに行き着くのでしょうか？

MT: – 実に素晴らしい質問です。 シャードについて話したかっただけです。 質問を正しく理解していれば、次のような状況になります。シャード 1 とシャード 2 があり、これら XNUMX つのシャードから読み取りが行われます。これらのシャードには不一致があり、認識している時間が異なるため、相互作用しません。特に oplogs に存在する時間。
シャード 1 が 2 万件のレコードを作成し、シャード 2 はまったく何もせず、リクエストが XNUMX つのシャードに届いたとします。 最初のものの afterClusterTime は XNUMX 万を超えています。 このような状況では、先ほど説明したように、シャード XNUMX はまったく応答しません。

で： – どのように同期して XNUMX つの論理時間を選択するのか知りたかったのですが?

MT: - 同期が非常に簡単です。 シャードは、ClusterTime の後に彼がやって来て、「Oplog」に時間が見つからなかったとき、承認されずに開始します。 つまり、彼は自分の手で時間をこの値まで上げます。 これは、このリクエストに一致するイベントがないことを意味します。 彼はこの出来事を人為的に作り出し、したがって因果関係が一致します。

で： – この後、ネットワークのどこかに失われた別のイベントが彼の元にやって来たらどうしますか?

MT: – シャードは単一のマスターであるため、二度と来ないように設計されています。 彼がすでにサインアップしている場合、彼らは来ませんが、後で来ます。 何かがどこかで行き詰まって、その後彼が何も書かず、その後にこれらのイベントが到着するということは起こり得ません - そして因果関係の一貫性が壊れます。 彼が何も書かないときは、全員が次に来るはずです (彼は彼らを待ちます)。

で： – キューに関していくつか質問があります。 因果的一貫性は、実行する必要があるアクションの特定のキューがあることを前提としています。 パッケージの 10 つがなくなったらどうなりますか? 11番目、12番目が来ます...XNUMX番目は消えました、そして他の誰もがそれが実現するのを待っています。 そして突然車が死んでしまったので、私たちは何もできません。 実行前に蓄積されるキューの最大長はありますか? どれか XNUMX つの状態が失われると、どのような致命的な障害が発生しますか? しかも、以前の状態があると書いたら、そこから何とか始めればいいんじゃないでしょうか？ しかし、彼らは彼を突き放しませんでした！

MT: – これも素晴らしい質問ですね！ 私たちは何をしているのでしょうか？ MongoDB には、クォーラム書き込み、クォーラム読み取りの概念があります。 どのような場合にメッセージが失われる可能性がありますか? 書き込みがクォーラムではない場合、または読み取りがクォーラムではない場合 (何らかのゴミが付着している可能性もあります)。
因果的一貫性に関しては、大規模な実験テストが行​​われ、その結果、書き込みと読み取りがクォーラム以外の場合に、因果的一貫性の違反が発生することが判明しました。 まさにあなたの言う通りです！

私たちのアドバイス: 因果的一貫性を使用する場合は、少なくともクォーラム読み取りを使用してください。 この場合、クォーラム レコードが失われたとしても、何も失われることはありません。これは直交する状況です。ユーザーがデータを失いたくない場合は、クォーラム レコードを使用する必要があります。 因果関係の一貫性は耐久性を保証しません。 耐久性は、レプリケーションとレプリケーションに関連する機構によって保証されます。

で： – シャーディングを実行するインスタンス (それぞれマスターではなくスレーブ) を作成する場合、そのインスタンスはそれ自身のマシンの Unix 時間または「マスター」の時間に依存します。 同期は初めてですか、それとも定期的にですか?

MT: – 今からはっきりさせておきます。 シャード (つまり、水平パーティション) – そこには常にプライマリが存在します。 また、シャードには「マスター」が存在する場合もあれば、レプリカが存在する場合もあります。 ただし、シャードは何らかのドメイン (シャードにはプライマリがある) をサポートする必要があるため、常に記録をサポートします。

で： ――すべては“師匠”次第ということですね？ マスタータイムは常に使用されますか?

MT: - はい。 比喩的に言うと、「マスター」、つまり「Oplog」へのエントリーが発生すると、時計が時を刻んでいるということです。

で： – 接続しているクライアントがいますが、時間について何も知る必要はありませんか?

MT: – 何も知らなくても大丈夫！ それがクライアント上でどのように機能するかについて話すと、クライアントが因果的一貫性を使用したい場合、セッションを開く必要があります。 これで、セッション内のトランザクション、権利の取得など、すべてが完了しました。セッションとは、クライアントで発生する論理イベントの順序です。

彼がこのセッションを開いて、そこで因果関係の一貫性が必要だと言うと (セッションがデフォルトで因果関係の一貫性をサポートしている場合)、すべてが自動的に機能します。 ドライバーはこの時間を記憶しており、新しいメッセージを受信すると時間を増やします。 データを返したサーバーから前回の応答がどのような応答を返したかを記憶します。 次のリクエストには、afterCluster("これより大きい時間") が含まれます。

クライアントは何も知る必要はありません。 これは彼にとってまったく不透明だ。 これらの機能を使用すると、何ができるでしょうか? まず、セカンダリを安全に読み取ることができます。プライマリに書き込み、地理的にレプリケートされたセカンダリから読み取ることができ、それが動作することを確認できます。 同時に、プライマリで記録されたセッションをセカンダリに転送することもできます。つまり、XNUMX つのセッションではなく、複数のセッションを使用できます。

で： – コンピューティング サイエンスの新しい層である CRDT (Conflict-free Replicated Data Types) データ型は、結果整合性のトピックと強く関連しています。 このようなタイプのデータをデータベースに統合することを検討したことがありますか? それについて何が言えますか?

MT: - 良い質問！ CRDT は書き込み競合に意味があります。MongoDB では単一マスターです。

で： – Devops から質問があります。 現実の世界では、ビザンチン障害が発生し、保護された境界内の邪悪な人々がプロトコルに侵入し始め、特別な方法で工芸品パッケージを送信し始めたときに、そのようなイエズス会の状況が発生しますか？

MT: – 境界内の邪悪な人々はトロイの木馬のようなものです! 境界内の邪悪な人々は多くの悪いことをする可能性があります。

で： – 大まかに言えば、サーバーに穴を開けたままにすると、そこから象の動物園を入れてクラスター全体を永久に崩壊させることができることは明らかです...手動での回復には時間がかかります...これは、控えめに言っても、間違っている。 一方で、これは興味深いことです。現実の生活や実務では、当然ながら同様の内部攻撃が発生する状況があります。

MT: – 実生活でセキュリティ侵害に遭遇することはめったにないので、実際にセキュリティ侵害が発生するかどうかはわかりません。 しかし、開発哲学について話すと、私たちは次のように考えます。セキュリティを担当する人々を提供する境界線があります。これは城であり、壁です。 そして境界線の内側では、やりたいことが何でもできます。 ディレクトリを表示するだけの権限を持つユーザーと、ディレクトリを消去する権限を持つユーザーがいることは明らかです。

権利に応じて、ユーザーが及ぼす損害はネズミの場合もあればゾウの場合もあります。 完全な権限を持つユーザーは何でもできることは明らかです。 権限が制限されたユーザーは、害を大幅に軽減できます。 特に、システムを破壊することはできません。

で： – 保護された境界内で、誰かがサーバーを完全に破壊するために、サーバー用の予期しないプロトコルを作成しようとしました。運が良ければクラスター全体を破壊しようとしました...これほど「良い」状態になることはありますか?

MT: 「そのようなことは聞いたことがありません。」 この方法でサーバーをクラッシュできるという事実は周知の事実です。 内部で失敗すること、プロトコルからのものであること、メッセージにこのような内容を書き込むことができる許可されたユーザーであること...実際には、まだ検証されるため、それは不可能です。 この認証を希望しないユーザーに対しては、この認証を無効にすることができます。その場合は、それがユーザーの問題です。 大まかに言えば、彼らは自分たちで壁を破壊したので、そこに象を押し込むと踏みにじることができます...しかし一般的には、修理工の格好をして、来てそれを引き抜くことができます！

で： – ご報告ありがとうございます。 セルゲイ（ヤンデックス）。 Mong には、レプリカ セット内の投票メンバーの数を制限する定数があり、この定数は 7 (セブン) です。 なぜこれが定数なのでしょうか? なぜこれは何らかのパラメータではないのでしょうか?

MT: – 40 ノードのレプリカ セットがあります。 常に多数派が存在します。 どのバージョンか分かりません...

で： – レプリカ セットでは非投票メンバーを実行できますが、投票メンバーは最大 7 人です。この場合、レプリカ セットが 3 つのデータ センターに分散している場合、シャットダウンをどうやって乗り切ることができますか? XNUMX つのデータセンターの電源が簡単にオフになり、別のマシンが停止する可能性があります。

MT: – これはすでにレポートの範囲を少し超えています。 これは一般的な質問です。 もしかしたらそれについては後でお話しできるかもしれません。

いくつかの広告 🙂

いつもご宿泊いただきありがとうございます。 私たちの記事が気に入っていますか? もっと興味深いコンテンツを見たいですか? 注文したり、友人に勧めたりして私たちをサポートしてください。 開発者向けのクラウド VPS は 4.99 ドルから, 当社があなたのために発明した、エントリーレベルのサーバーのユニークな類似物です。 VPS (KVM) E5-2697 v3 (6 コア) 10GB DDR4 480GB SSD 1Gbps 19 ドルからの真実、またはサーバーを共有する方法? (RAID1 および RAID10、最大 24 コア、最大 40GB DDR4 で利用可能)。

アムステルダムのエクイニクス Tier IV データセンターでは Dell R730xd が 2 倍安い? ここだけ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV 199 ドルから オランダで！ Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 ドルから! について読む インフラストラクチャー企業を構築する方法730 ペニーで 5 ユーロの価値がある Dell R2650xd E4-9000 vXNUMX サーバーを使用したクラスですか?

出所： habr.com