クラウド データベースの選択に必読: 要件を整理するにはどうすればよいでしょうか?

[[419550]]

クラスター化されたデータベースが必要ですか?

クラスター化されたデータベースには、単一ノードのデータベースに比べていくつかの利点がありますが、コストと複雑さが増します。さらに、クラスター化されたデータベースは、より高い可用性、より高いスループット、そして場合によってはより低いレイテンシを実現します。

各ノードにデータベース全体のコピーがあるクラスターでは、冗長性と可用性が高まります。戦略に応じて、読み取り操作に単一のノードのみが必要な場合もあれば、クラスター内のノードのグループが戻り値について合意する必要がある場合もあります。

複数のノードを持つクラスターを使用すると、データベースはより多くの CPU を使用できるため、スループットが向上し、トランザクション レートが向上します。読み取りレイテンシは通常、最も近いノードが値を返すことを可能にする読み取り戦略を使用して短縮されます。一方、すべてのノードがコミットするまで待機する必要がある書き込みまたはトランザクション戦略では、書き込みのレイテンシが増加することがあります。

コンセンサス グループを使用すると、レイテンシを削減できます。 3 ノードのクラスターがあり、1 つのノードが過負荷になった場合、他の 2 つのノードがコンセンサス トランザクションを承認し、3 番目のノードが使用可能になったときに更新することができます。

シャーディングは、より多くのデータを処理するためにデータベースを分割する方法です。手動のシャーディングは時間がかかり、面倒な場合がありますが、多くのデータベースには自動シャーディング機能が備わっています。

分散データベースが必要ですか?

クラスタリングはデータベースを拡張するための究極の方法ではありませんが、最初のステップです。次のステップは分散データベースであり、通常は複数のリージョンにクラスターを持つことを意味します。一部のデータベースでは、分散された読み取り専用レプリカとプライマリの読み取り/書き込みインスタンスまたはクラスターが許可されます。他のデータベースでは、分散された読み取りおよび書き込みインスタンスまたはクラスターが許可され、同期メカニズムが備わっています。

分散データベースは、多くの場合、リモート ユーザーに対して低いレイテンシと高いスループットを提供できます。東京のユーザーがバルセロナのサーバーにアクセスすると 260 ミリ秒の遅延が発生する可能性がありますが、日本にデータベースのレプリカがあれば、平均読み取り遅延はわずか 10 ミリ秒になる可能性があります。これが書き込みとトランザクションにどのように影響するかは、データベースの一貫性要件とリモート クラスターの構成方法によって異なります。

初期の分散データベースは、最終的な一貫性を備えた NoSQL データベースでした。最終的な一貫性とは、リモート ロケーションでの書き込み後の読み取りで最新の情報が返されることは保証されませんが、時間の経過とともに更新されることを意味します。最終的な一貫性により、書き込みとトランザクションの完了の要件が緩和され、レイテンシが短縮されます。

最近のいくつかの分散データベースは、データ構造、コンセンサス グループ、および時間同期の助けを借りて強力な一貫性を実現しています。例としては、Google Cloud Spanner や CockroachDB などが挙げられます。

データベースの予算はいくらですか?

ほとんどのデータベースには無料の「コミュニティ」または「開発/テスト」バージョンがありますが、オンライン コミュニティ フォーラム以外のサポートが不足している可能性があります。コミュニティ エディションとオープン ソース エディションには、商用エディションで提供されるパフォーマンス最適化の一部が欠けている場合もあります。会社がデータベースに依存している場合は、ライセンスとサポートへの投資が必要になります。

データベースをクラウドで実行する場合は、少なくともクラウド リソースの料金を支払う必要があります。商用データベースの場合は、データベース ライセンスも必要になります。これは、ベンダーからの長期ライセンス、またはクラウド プロバイダーを通じて購入する従量課金制ライセンスになります。

付録: CAP定理

CAP 定理 (Brewer 他、1998) によれば、ネットワーク化された共有データ システムは、次の 3 つの望ましい特性のうち最大 2 つを備えているとされています。

C: 一貫性。データの最新コピーを保持することと同等。

A: このデータの更新の可用性。

P: ネットワークパーティションに対する耐性。

データベースの理想的な特性は、データベースがサービスを提供するアプリケーションのニーズによって異なります。アプリケーションがカタログを表示する場合、データベースの読み取り速度と待機時間が重要であり、ドキュメント データベースが理想的ですが、リレーショナル データベースやワイドカラム データベースも適しています。アプリケーションが金融取引を処理する場合、データベースの ACID プロパティ (原子性、一貫性、独立性、および耐久性) が重要であり、リレーショナル データベースが理想的です。

この3分の2という式は単純化しすぎていることが判明した。最新の分散データベース アーキテクチャでは、Paxos または Raft アルゴリズムを使用してグループを共有することで、ノード障害とネットワーク パーティションが軽減されます。実際、ノードがクラスターを離れても、クラスターはクォーラム メカニズムがある限り動作し続けます。さらに、大手クラウド プロバイダーなどのプライベート ネットワーク内ではパーティションはほとんど発生しません。これらのネットワークでは、データ センター間で冗長ファイバーが使用され、パブリック インターネット経由で内部トラフィックが転送されることはありません。

つまり、厳密に言えば CAP 定理を回避できるデータベースはありませんが、実際には優れたクラウド データベースは 5 つの 9 (99.999%) を超える可用性を備えているため、これらのデータベースは CAP 定理を回避でき、一貫性と可用性の両方を実現できます。

著者: Martin Heller は現在 InfoWorld の寄稿編集者兼コメンテーターであり、以前は Web および Windows プログラミング コンサルタントとして働いていました。ヘラー氏は 1986 年から 2010 年まで、データベース、ソフトウェア、Web サイトの開発に従事しました。直近では、Alpha Software でテクノロジーおよび教育担当副社長を務め、Tubifi の会長兼 CEO を務めていました。

元の URL: https://www.infoworld.com/article/3627792/how-to-choose-a-cloud-database.html