エンタープライズ向け分散DBMS

CAPの定理は、分散システムの理論の基礎です。もちろん、それをめぐる論争は収まりません。その定義は標準的ではなく、厳密な証拠もありません...それにもかかわらず、日常の常識™の立場をしっかりと守っていれば、定理が真実であることを直感的に理解できます。







はっきりしないのは、文字「P」の意味だけです。クラスターが分割されると、クォーラムに達するまで応答しないか、クォーラムに達するまで応答しないかを決定します。この選択の結果に応じて、システムはCPまたはAPのいずれかに分類されます。たとえば、Cassandraは、クラスター設定ではなく、特定の各要求のパラメーターに応じて、このように動作できます。しかし、システムが「P」ではなく、分割されている場合はどうなりますか？



この質問への答えはやや予想外です。CAクラスターを分割することはできません。

分割できないこのクラスターとは何ですか？



このようなクラスターの不可欠な属性は、共有データストレージシステムです。ほとんどの場合、これはSANを介して接続することを意味し、CAソリューションの使用をSANインフラストラクチャをホストできる大企業に制限します。複数のサーバーが同じデータを処理できるようにするには、クラスター化されたファイルシステムが必要です。このようなファイルシステムは、HPE（CFS）、Veritas（VxCFS）、IBM（GPFS）のポートフォリオに含まれています。

Oracle RAC

Real Application Clusterオプションは、2001リリースのOracle9iで最初に登場しました。複数のサーバーインスタンスが同じデータベースで動作するようなクラスター内。

Oracleは、クラスターファイルシステムと独自のソリューション（ASM、自動ストレージ管理）の両方を使用できます。



各コピーは独自のジャーナルを保持します。トランザクションは1つのインスタンスで実行およびコミットされます。インスタンスに障害が発生した場合、存続しているクラスターノード（インスタンス）の1つがログを読み取り、失われたデータを回復して、可用性を確保します。



すべてのインスタンスは独自のキャッシュを維持し、同じページ（ブロック）を複数のインスタンスのキャッシュに同時に配置できます。さらに、あるインスタンスでページが必要であり、そのページが別のインスタンスのキャッシュにある場合、ディスクから読み取る代わりに、キャッシュフュージョンメカニズムを使用して「ネイバー」からページを取得できます。







しかし、インスタンスの1つがデータを変更する必要がある場合はどうなりますか？



Oracleの特徴は、専用のロックサービスがないことです。サーバーが行をロックする場合、ロックレコードは、ロックされた行が配置されているメモリページに直接配置されます。このアプローチにより、Oracleはモノリシックデータベースのパフォーマンスチャンピオンになります。ロックサービスがボトルネックになることはありません。ただし、クラスター構成では、このアーキテクチャにより、ネットワークトラフィックが大量に発生し、デッドロックが発生する可能性があります。



レコードがブロックされるとすぐに、インスタンスは、レコードを格納するページが排他モードで取得されたことを他のすべてのインスタンスに通知します。別のインスタンスが同じページのレコードを変更する必要がある場合、ページの変更がコミットされるまで、つまり変更情報がディスクログに書き込まれるまで待機する必要があります（トランザクションを続行できます）。また、ページが数回ずつ順番に変更される場合があります。その場合、ページをディスクに書き込むときに、このページの現在のバージョンを誰が持っているかを確認する必要があります。



異なるRACノード間で同じページを誤って更新すると、データベースのパフォーマンスが大幅に低下し、クラスターのパフォーマンスが単一のインスタンスよりも遅くなる可能性があります。



Oracle RACの正しい使用法は、データを物理的にパーティション化し（たとえば、パーティションテーブルメカニズムを使用して）、専用ノードを介してパーティションの各セットにアクセスすることです。 RACの主な目的は、水平スケーリングではなく、障害耐性を提供することでした。



ノードがハートビートへの応答を停止すると、それを検出したノードが最初にディスク投票手順を開始します。欠落しているノードがここに記載されていない場合、ノードの1つがデータ回復の責任を負います。

• 欠落しているノードのキャッシュにあったすべてのページを「フリーズ」します。
• 欠落しているノードのログ（やり直し）を読み取り、これらのログに記録された変更を再適用し、他のノードに変更されたページの最新バージョンがあるかどうかを確認します。
• コミットされていないトランザクションをロールバックします。

ノード間の切り替えを簡素化するために、Oracleにはサービスの概念（仮想インスタンス）があります。インスタンスは複数のサービスを提供でき、サービスはノード間を移動できます。ベースの特定の部分（たとえば、クライアントのグループ）にサービスを提供するアプリケーションインスタンスは1つのサービスで動作し、ベースのこの部分を担当するサービスは、ノードに障害が発生すると、別のノードに移動します。

トランザクション用のIBMPure Data Systems

DBMSのクラスターソリューションは、2009年にBlueGiantポートフォリオに登場しました。理想的には、これは「従来の」ハードウェア上に構築されたParallelSysplexクラスターの継承者です。 2009年にDB2pureScaleがソフトウェアスイートとしてリリースされ、2012年にIBMはPure Data Systems forTransactionsと呼ばれるアプライアンスを提供しています。名前が変更されたNetezzaにすぎないPureData Systems forAnalyticsと混同しないでください。



pureScaleアーキテクチャは一見OracleRACのように見えます。同じように、複数のノードが共有ストレージシステムに接続され、各ノードは独自のメモリ領域とトランザクションログを使用してDBMSの独自のインスタンスを実行します。ただし、Oracleとは異なり、DB2にはdb2LLM *プロセスセットで表される専用のロックサービスがあります。クラスター構成では、このサービスは、Parallel Sysplexではカップリングファシリティ（CF）と呼ばれ、PureDataではPowerHAと呼ばれる別のノードに配置されます。



PowerHAは次のサービスを提供します。

• ロックマネージャー;
• グローバルバッファキャッシュ。
• プロセス間通信の領域。

リモートメモリアクセスは、PowerHAからデータベースノードへ、またはその逆にデータを転送するために使用されるため、クラスター相互接続はRDMAプロトコルをサポートする必要があります。 PureScaleは、InfinibandとRDMA overEthernetの両方を使用できます。







ノードがページを必要とし、このページがキャッシュにない場合、ノードはグローバルキャッシュにページを要求し、そこにない場合にのみ、ディスクからページを読み取ります。 Oracleとは異なり、クエリはPowerHAにのみ送信され、隣接ノードには送信されません。



インスタンスが文字列を変更しようとすると、排他モードでブロックされ、文字列が存在するページは共有モードでブロックされます。すべてのロックはグローバルロックマネージャーに登録されます。トランザクションが完了すると、ノードはロックマネージャにメッセージを送信します。ロックマネージャは、変更されたページをグローバルキャッシュにコピーし、ロックを解放して、他のノードのキャッシュ内の変更されたページを無効にします。



変更された文字列を含むページがすでにロックされている場合、ロックマネージャは、変更を行ったノードのメモリから変更されたページを読み取り、ロックを解除し、他のノードのキャッシュ内の変更されたページを無効にして、それを要求したノードにページロックを与えます。



ダーティ、つまり変更されたページは、通常のノードとPowerHA（キャストアウト）の両方からディスクに書き込むことができます。



pureScaleノードの1つに障害が発生した場合、回復は障害時にまだ完了していなかったトランザクションのみに制限されます。完了したトランザクションでそのノードによって変更されたページは、PowerHAのグローバルキャッシュにあります。ノードは、クラスターサーバーの1つで削除された構成で再起動し、コミットされていないトランザクションをロールバックして、ロックを解放します。



PowerHAは2つのサーバーで実行され、マスターノードはその状態を同期的に複製します。プライマリPowerHAノードに障害が発生した場合、クラスタはスタンバイノードで動作し続けます。

もちろん、単一のノードを介してデータセットにアクセスすると、クラスター全体のパフォーマンスが向上します。PureScaleは、データの一部の領域が1つのノードによって処理されていることに気付く場合もあり、この領域に関連するすべてのロックは、PowerHAと通信せずにローカルでノードによって処理されます。ただし、アプリケーションが別のノードを介してこのデータにアクセスしようとするとすぐに、集中ロック処理が再開されます。



90％の読み取りおよび10％の書き込みワークロードでの内部IBMベンチマークは、実際の実稼働ワークロードと非常によく似ており、128ノードまでほぼ線形にスケーリングします。残念ながら、試験条件は明らかにされていません。

HPE NonStop SQL

Hewlett-Packard Enterpriseポートフォリオには、独自の可用性の高いプラットフォームもあります。これは、1976年にTandemComputersによって発売されたNonStopプラットフォームです。 1997年、同社はCompaqに買収され、Compaqは2002年にHewlett-Packardと合併しました。



NonStopは、HLRやバンクカード処理などの重要なアプリケーションを構築するために使用されます。プラットフォームは、コンピューティングノード、データストレージシステム、通信機器を含むソフトウェアとハ​​ードウェアの複合体（アプライアンス）の形で提供されます。 ServerNet（最新のシステムでは-Infiniband）は、ノード間の交換とデータストレージシステムへのアクセスの両方に機能します。



以前のバージョンのシステムでは、相互に同期された独自のプロセッサが使用されていました。すべての操作は複数のプロセッサによって同期的に実行され、プロセッサの1つが間違えられるとすぐにオフになり、2つ目は引き続き機能しました。その後、システムは従来のプロセッサ（最初にMIPS、次にItanium、最後にx86）に切り替わり、他のメカニズムが同期に使用されるようになりました。

• メッセージ：各システムプロセスには「シャドウ」ツインがあり、アクティブプロセスはその状態に関するメッセージを定期的に送信します。メインプロセスが失敗した場合、シャドウプロセスは最後のメッセージで決定された瞬間から動作を開始します。
• : , , ; , /.

1987年以来、リレーショナルDBMSはNonStopプラットフォーム（最初はSQL / MP、その後はSQL / MX）で実行されています。



データベース全体が部分に分割され、各部分が独自のData Access Manager（DAM）プロセスを担当します。データの書き込み、キャッシュ、およびロックのメカニズムを提供します。データ処理は、それぞれのデータマネージャと同じノードで実行されるExecutor ServerProcessによって処理されます。 SQL / MXスケジューラーは、タスクをエグゼキューター間で分割し、結果をマージします。一貫した変更を行う必要がある場合は、TMF（トランザクション管理機能）ライブラリが提供する2フェーズコミットプロトコルを使用してください。







NonStop SQLは、長い分析クエリがトランザクションの実行に干渉しないように、プロセスに優先順位を付ける方法を知っています。ただし、その目的は、分析ではなく、正確に短いトランザクションの処理です。開発者は、ファイブナインのレベルでNonStopクラスターの可用性を保証します。つまり、ダウンタイムは年間わずか5分です。

SAP HANA

HANA DBMS（1.0）の最初の安定したリリースは2010年11月に行われ、SAPERPパッケージは2013年5月にHANAに移行しました。プラットフォームは、購入したテクノロジーに基づいています：TREX検索エンジン（柱状ストレージで検索）、P * TIME、MAXDB。



「HANA」という言葉自体は、高性能ANalyticalApplianceの頭字語です。このDBMSは、任意のx86サーバーで実行できるコードの形式で提供されますが、産業用インストールは認定された機器でのみ許可されます。 HP、Lenovo、Cisco、Dell、Fujitsu、Hitachi、NECからのソリューションがあります。一部のLenovo構成では、SANなしでの操作も可能です。ローカルディスク上のGPFSクラスターが共有ストレージの役割を果たします。



上記のプラットフォームとは異なり、HANAはインメモリDBMSです。つまり、データのプライマリイメージはRAMに保存され、災害時に回復するためにログと定期的なスナップショットのみがディスクに書き込まれます。







HANAクラスターの各ノードは、データの独自の部分を担当し、データマップは、コーディネーターノードにある特別なコンポーネントであるネームサーバーに格納されます。ノード間のデータは複製されません。ロック情報も各ノードに保存されますが、システムにはグローバルデッドロック検出器があります。



HANAクライアントは、クラスターに接続するときに、そのトポロジーをロードしてから、必要なデータに応じて、任意のノードに直接アクセスできます。トランザクションが単一ノードのデータに影響を与える場合、このノードによってローカルで実行できますが、複数のノードのデータが変更されると、イニシエーターノードはコーディネーターノードに接続し、コーディネーターノードが分散トランザクションを開いて調整し、最適化された2フェーズコミットプロトコルを使用してコミットします。



コーディネーターノードが複製されるため、コーディネーターに障害が発生した場合、バックアップノードがすぐに引き継ぎます。ただし、データのあるノードに障害が発生した場合、そのデータにアクセスする唯一の方法は、ノードを再起動することです。原則として、HANAクラスターでは、失われたノードをできるだけ早く再起動するために、スペアサーバーが保持されます。