AppleのFoundationDBの初見

前回の記事では、データを水平方向にスケーリングする必要があり、トランザクションのACIDプロパティを保証する必要がある場合に生じる制限と障害を調べました。 この記事では、FoundationDBテクノロジーについて説明し、ミッションクリティカルなアプリケーションを開発するときにこれらの制限を克服するのにどのように役立つかを理解します。



FoundationDBは、並べ替えられたキーと値のストアペアを格納する、シリアル化可能なACIDトランザクションを備えた分散NoSQLデータベースです。 キーと値は、任意のバイトシーケンスにすることができます。 単一の発生ポイントはありません-すべてのクラスターマシンは同等です。 クラスターサーバー間でデータを分散し、その場でスケーリングします。クラスターにリソースを追加する必要がある場合、構成サーバーに新しいマシンのアドレスを追加するだけで、データベースはそれを自動的に取得します。



FoundationDBでは、トランザクションが互いにブロックすることはありません。 読み取りはマルチバージョンバージョン管理 （MVCC）で実装され、書き込みは楽観的同時実行制御 （OCC）で実装されます。 開発者は、すべてのクラスターマシンが同じデータセンターにある場合、書き込み遅延は2〜3ミリ秒で、読み取り遅延は1ミリ秒未満であると主張しています。 ドキュメントには10​​〜15ミリ秒の推定値が含まれていますが、これはおそらく実際の条件での結果に近いでしょう。



*複数のシャードでACIDプロパティをサポートしていません。



FoundationDBには、自動リシャーディングというユニークな利点があります。 DBMS自体は、クラスター内のマシンの均等なロードを保証します。1つのサーバーがいっぱいになると、バックグラウンドで隣接するサーバーにデータを再配布します。 同時に、すべてのトランザクションのSerializableのレベルの保証が保持され、顧客に気付く唯一の効果は、応答の遅延がわずかに増加することです。 データベースにより、負荷が最も大きいクラスターサーバーと最も少ないクラスターサーバーのデータ量の差が5％以下になることが保証されます。

建築

論理的に、FoundationDBクラスターは、異なる物理マシン上の類似したプロセスのセットです。 プロセスには独自の構成ファイルがないため、交換可能です。 いくつかの固定プロセスには専用の役割（コーディネーター）があり、起動時の各クラスタープロセスはアドレスを知っています。 コーディネーターのクラッシュはできるだけ独立していることが重要です。そのため、異なる物理マシンまたは異なるデータセンターに配置するのが最適です。







コーディネーターは、 Paxosコンセンサスアルゴリズムを介して互いに同意します。 彼らはCluster Controllerプロセスを選択し、その後、残りのクラスタープロセスに役割を割り当てます。 Cluster Controllerは、すべてのコーディネーターに、自分が生きていることを継続的に通知します。 ほとんどのコーディネーターが彼が死んだと信じている場合、彼らは単に新しいものを選択します。 Cluster ControllerもCoordinatorもトランザクション処理に関与していないため、主なタスクはスプリットブレインの状況を排除することです。



クライアントがデータベースに接続したい場合、すぐに現在のCluster Controllerのアドレスのすべてのコーディネーターにアドレスします。 ほとんどの回答が一致する場合、Cluster Controllerから現在の完全なクラスター構成を受け取ります（一致しない場合は、コーディネーターを再度呼び出します）。







Cluster Controllerは利用可能なプロセスの合計数を認識し、役割を配布します。これら5つはプロキシ、これら2つはリゾルバー、この1つはマスターになります。 そして、それらのいずれかが死亡した場合、彼はすぐに彼の代わりを見つけ、任意の自由なプロセスに必要な役割を割り当てます。 これはすべて、バックグラウンドで発生し、アプリケーションプログラマには見えません。



マスタープロセスは、データセットの現在のバージョンの数（データベース内の各レコードで増加します）、およびストレージサーバーへの多くのキーの配布とレート調整（負荷が高い場合のパフォーマンスの人工的な低下：クラスターがクライアントを認識している場合）を担当しますたくさんの小さなリクエストを行い、彼は待ってグループ化し、一度にパック全体に答えます）。



トランザクションロギングとストレージは、2つの独立したストレージサブシステムです。 1つ目は、データを受信順にすばやくディスクに書き込むための一時的なストレージです。2つ目は、ディスク上のデータがキーの昇順でソートされる永続的なストレージです。 各トランザクションのコミット、少なくとも3つのtLogプロセスは、クラスターがクライアントに成功を報告する前にデータを保存する必要があります。 並行して、バックグラウンドのデータはtLogサーバーからストレージサーバーに移動します（ストレージも冗長です）。

リクエスト処理

すべてのクライアント要求がプロキシプロセスを処理します。 トランザクションを開くと、クライアントはプロキシにアクセスし、他のすべてのプロキシをポーリングし、クラスターデータの現在のバージョン番号を返します。 それ以降の読み取りはすべて、このバージョン番号で行われます。 トランザクションを開いた後に別のクライアントがデータを書き留めた場合、その変更は表示されません。



競合を解決する必要があるため、トランザクションの記録はもう少し複雑です。 これには、変更されたすべてのキーを一定期間メモリに保存するリゾルバープロセスが含まれます。 クライアントが書き込みのコミットトランザクションを完了すると、リゾルバーは読み取り中のデータが古いかどうかを確認します。 （つまり、私のトランザクションよりも後に開かれたトランザクションが完了し、読み取ったキーが変更されたかどうか。）これが発生した場合、トランザクションはロールバックされ、クライアントライブラリ自体（！）が再度コミットを試みます。 開発者が考える必要があるのは、トランザクションがべき等であるということだけです。つまり、繰り返し使用しても同じ結果が得られるはずです。 これを実現する1つの方法は、トランザクション内で一意の値を保存し、トランザクションの開始時にデータベース内でその存在を確認することです。







すべてのクライアント/サーバーシステムと同様に、トランザクションが正常に完了したが、切断のためにクライアントが確認を受信しなかった場合があります。 クライアントライブラリは、それらを他のエラーと同様に扱います。単に再試行します。 これにより、トランザクション全体が再実行される可能性があります。 ただし、トランザクションがべき等である場合、これに問題はありません。最終結果には影響しません。

スケーリング

ストレージサブシステムには数千のサーバーが存在する場合があります。 特定のキーに関するデータが必要な場合、クライアントはどちらに連絡する必要がありますか？ Cluster Controllerから、クライアントはクラスター全体の完全な構成を認識し、各ストレージサーバーのキー範囲が含まれます。 そのため、中間リクエストなしで、目的のストレージサーバーに直接アクセスするだけです。



目的のストレージサーバーが使用できない場合、クライアントライブラリはCluster Controllerから新しい構成を取得します。 サーバーがクラッシュした結果、クラスターが冗長性が不十分であると認識した場合、クラスターはすぐに他のストレージから新しいノードの収集を開始します。



トランザクションでギガバイトのデータを保存するとします。 どうすれば迅速に対応できますか？ 方法はありません。したがって、FoundationDBは1つのトランザクションのサイズを10メガバイトに制限しました。 さらに、これは、トランザクションが関係するすべてのデータ（読み取りまたは書き込み） に対する制限です。 データベースの各エントリも制限されています。キーは10キロバイトを超えることはできません。値は100キロバイトです。 （同時に、最適なパフォーマンスのために、開発者は32バイトの長さのキーと10キロバイトの長さの値を推奨します。）



トランザクションは潜在的に競合の原因になる可能性があるため、ロールバックする必要があります。 したがって、コミットコマンドが到着するまで、速度のために、現在の変更をディスクではなくRAMに保持するのが理にかなっています。 1GB /秒の負荷でデータベースにデータを書き込むとします。 その後、極端な場合のクラスターは毎秒3GBのRAMを割り当てます（3台のマシンにトランザクションを書き込みます）。 このような使用済みメモリの雪崩のような成長を制限する方法は？ 最大トランザクション時間を制限するのは非常に簡単です。 FoundationDBでは、トランザクションは5秒を超えることはできません。 トランザクションが開かれてから5秒後にクライアントがデータベースにアクセスしようとすると、クラスターは新しいコマンドを開くまですべてのコマンドを無視します。

指数

人のリストを保持し、各人が一意の識別子を持ち、それをキーとして使用し、値に他のすべての属性（名前、性別、年齢など）を書き込むとします。

キー	価値
12345	（Ivanov Ivan Ivanovich、M、35）

徹底的な検索をせずに30歳のすべての人のリストを取得する方法は？ 通常、このためにデータベースにインデックスが作成されます。 インデックスは、追加の属性をすばやく検索するために設計された別のデータビューです。 次の形式のエントリを簡単に追加できます。

キー	価値
（35、12345）	''

必要なリストを取得するには、キーの範囲（30、*）を検索するだけです。 FoundationDBはキーでソートされたデータを保存するため、このようなクエリは非常に高速に実行されます。 もちろん、インデックスは追加のディスク領域を占有しますが、かなりの量が必要です。 すべての属性が複製されるわけではなく、年齢と識別子のみが複製されることに注意してください。



レコード自体とそれにインデックスを追加する操作が1つのトランザクションで実行されることが重要です。

信頼性

FoundationDBはC ++で記述されています。 著者は2009年に作業を開始し、最初のバージョンは2013年にリリースされ、2015年3月にAppleに買収されました。 3年後、Appleは予期せずソースコードを開きました。 噂では 、AppleがiCloudサービスのデータを保存するために、とりわけそれを使用しているという。



経験豊富な開発者は通常、すぐに新しいソリューションを信頼しません。 技術が確実に確立されるまでには数年かかる場合があり、製品で大量に使用されるようになります。 この時間を短縮するために、著者はC ++の興味深い拡張機能であるフロー言語を作成しました。 これにより、プログラム実行の完全に予測可能な繰り返しの可能性により、信頼できない外部コンポーネントを使用して作業を正常にエミュレートできます。 ネットワークまたはディスクへの各呼び出しはラッパー（アクター）にラップされ、各アクターにはいくつかの実装があります。 標準実装では、意図したとおりにデータをディスクまたはネットワークに書き込みます。 そして、他は1000回のうち999回ディスクに書き込み、1000回のうち1回失われます。 代替のネットワーク実装では、たとえば、ネットワークパケット内のバイトを交換できます。 不注意なシステム管理者の作業を模倣するアクターさえいます。 これにより、データフォルダーが削除されるか、2つのフォルダーがスワップされる場合があります。 開発者は数千のシミュレーションを実行し 、さまざまなアクターを置き換え、Flowを使用して100％の再現性を実現します。テストがクラッシュした場合、シミュレーションを再開して同じ場所でクラッシュすることができます。 特に、スレッドを切り替えるときにOSスケジューラーによって生じる不確実性を排除するために、各FoundationDBプロセスは厳密にシングルスレッドです。



ほぼすべての一般的なNoSQLソリューションでデータ損失のシナリオを発見した研究者がFoundationDBをテストするように頼まれたとき、著者は巨大な仕事をし、自分自身よりもはるかに深く徹底的にテストし たため、ポイントがわからないと指摘して拒否しました。



クラスター障害はランダムであると考えるのが慣習ですが、経験豊富な開発者はこれがケースとは程遠いことを知っています。 同じメーカーと同じ数の他のディスクを1万台持っている場合、故障率は異なります。 FoundationDBでは、どのマシンが同じデータセンターにあり、どのプロセスが同じマシンにあるかをクラスターに伝えることができる、いわゆるマシン対応の構成が可能です。 データベースは、マシン間で負荷を分散するときにこれを考慮します。 また、クラスター内のマシンには通常、異なる特性があります。 FoundationDBはこれも考慮に入れ、リクエストキューの長さを調べ、バランスの取れた方法で負荷を再分散します。より弱いマシンはより少ないリクエストを受信します。



そのため、FoundationDBは、ACIDトランザクションと最高レベルの分離であるSerializableを数千台のマシンのクラスターで提供します。 驚くべき柔軟性と高性能を併せ持つ、魔法のように聞こえます。 ただし、すべての費用を支払う必要があるため、技術的な制限があります。

制限事項

トランザクションのサイズと長さに関する前述の制限に加えて、次の機能に注意することが重要です。

• クエリ言語はSQLではありません。つまり、SQLの経験がある開発者は再学習する必要があります。
  
  
• クライアントライブラリは、5つの高レベル言語（Phyton、Ruby、Java、Golang、およびC）のみをサポートします。 C＃の公式クライアントはまだありません。 REST APIがないため、別の言語をサポートする唯一の方法は、標準Cライブラリの上にラッパーを記述することです。
  
  
• 共有メカニズムはありません。このロジックはすべてアプリケーションで提供する必要があります。
  
  
• データストレージ形式は文書化されていません（通常、商用データベースにも文書化されていません）。 これはリスクです。クラスターが突然アセンブルされない場合、何をすべきかがすぐにはわからず、ソースファイルを掘り下げる必要があるためです。
  
  
• 厳密に非同期のプログラミングモデルは、初心者の開発者にとっては複雑に思えるかもしれません。
  
  
• トランザクションのべき等性について常に考える必要があります。
  
  
• 長いトランザクションを小さなトランザクションに分割する必要がある場合は、グローバルレベルで整合性を自分で管理する必要があります。
  
  

英語から翻訳すると、「Foundation」は「Foundation」を意味し、このDBMSの作成者はこのようにその役割を理解します。単純なレコードのレベルで高いレベルの信頼性を提供し、他のデータベースは基本機能のアドオンとして実装できます。 したがって、FoundationDBの上に、ドキュメント、グラフなど、さまざまな他のレイヤーを潜在的に作成できます。 問題は、パフォーマンスを損なうことなくこれらのレイヤーをどのように拡張するかです。 たとえば、CockroachDBの作成者は既にRocksDB（ローカルキーバリューストア）の上にSQLレイヤーを構築することでこの道を歩んでおり、リレーショナル結合に固有のパフォーマンスの問題を抱えています。



これまでに、AppleはFoundationDBの上に2つのレイヤーを開発し、公開しています： ドキュメントレイヤー （MongoDB APIをサポート）およびレコードレイヤー （ プロトコルバッファー形式でフィールドセットとしてレコードを保存し、インデックスをサポートし、Javaでのみ使用可能）。 歴史的に閉鎖されたAppleの企業が今日GoogleとMicrosoftの足跡をたどり、内部で使用されている技術のソースコードを公開しているのは喜ばしく、驚くべきことです。

見込み

ソフトウェア開発にはこのような実存的な矛盾があります。ビジネスは常に製品の変更と改善を望んでいます。 しかし同時に、彼は信頼できるソフトウェアを求めています。 また、ソフトウェアが変更されるとバグが発生し、ビジネスがこれに苦しむため、これらの2つの要件は互いに矛盾します。 したがって、製品で信頼性のある実証済みの技術に依存し、自分でコードを記述しなくて済む場合、これは常に価値があります。 この意味で、特定の制限にもかかわらず、松葉杖を異なるNoSQLデータベースにスカルプトするのではなく、ACIDプロパティを備えた実稼働実証済みのソリューションを使用できるのはクールです。



1年前、私たちは別のテクノロジーであるCockroachDBについて楽観的でしたが、パフォーマンスに対する期待に応えることができませんでした。 それ以来、分散キーと値のストア上のSQLレイヤーのアイデアに対する欲求を失い、そのため、たとえばTiDBを注意深く見ていませんでした 。 FoundationDBは、プロジェクトの最大のデータセットのセカンダリデータベースとして慎重に試す予定です。 FoundationDBまたはTiDBを実稼働で実際に使用した経験がある場合は、コメントでご意見をお聞かせください。