どのクラウド データベースを使用すべきでしょうか?

クラウド コンピューティングの基本原則は、使い捨ておよび交換可能な複数のマシンを使用することです。これは、クラウド コンピューティング テクノロジの使用と、クラウドに実装されたデータベース システムの機能に直接影響を及ぼします。

従来のデータベースは、大まかに、並列処理重視 (MongoDB や Teradata など) と単一ストレージ システム重視 (PostgreSQL や MySQL など) に分けられます。どちらのカテゴリも、コア設計に固有の制限があります。これらの制限の程度は、成熟度に応じて部分的に決まります。ただし、一部のコアアーキテクチャ上の決定では、特定の機能が効率的にサポートされない可能性があります。

たとえば、Greenplum にはシーケンスがありますが、Redshift にはシーケンスがありません。どちらも PostgreSQL の派生製品です。 BigQuery にはシーケンスがありませんが、Teradata にはシーケンスがあります。ただし、従来の意味でのシーケンスではありません。

クラウド データベースも同じカテゴリに分類され、新しいシステムは明らかに並列処理を優先する傾向があります。クラウド コンピューティング システムの基本的な特性は、並列性、スケーラビリティ、マシンの交換可能性です。

単一システムファーストのカテゴリでは、クラウドのインスタンス化は、Heroku PostgreSQL、Amazon Aurora (PostgreSQL/MySQL)、Google Cloud SQL (PostgreSQL/MySQL)、Azure SQL (SQL Server) などの従来のスタンドアロン製品の管理コスト、アップグレード、信頼性 (RPO/RTO) に重点を置く傾向があります。

並列優先カテゴリには、SQL/リレーショナル カテゴリ (BigQuery、Snowflake、Redshift、Spark、Azure Synapse) と DHT/NoSQL (BigTable、Dynamo、Cassandra、Redis) カテゴリの 2 つのサブカテゴリがあります。この違いは、SQL のような言語があるかどうかではなく、システム内のデータの物理レイアウトが、ハッシュされた高速検索キーによる単一行アクセス用に調整されているか、またはソート、マージ、およびフィルター操作を使用した一括アクセス用に調整されているかによって決まります。

並列優先リレーショナル データベースは通常、1 つ以上のクラウドネイティブ ストレージ システムに依存します。これらのストレージ システムは、常に並列処理を優先して構築されており、非常に制限された get-object/put-object API を公開しています。これにより、多くの場合、データのパーティション分割は可能ですが、高性能なランダム アクセスは許可されません。これにより、データベースが高度な永続データ構造 (インデックスなど) や、多くの場合は変更可能なデータを実装する能力が制限されます。

したがって、ネイティブ ストレージを使用するクラウド コンピューティングの実装では、インデックスではなく、マイクロパーティションの順次読み取りと書き込みに依存することがよくあります。ストレージ レベルのオブジェクトには、オブジェクト名に基づいて、物理アクセス パスが 1 つだけあることがよくあります。インデックス作成は基盤となるストレージの外部で実装する必要があり、実装されたとしても、基盤となるクラウド ストレージ API によって、ストレージ レベルのオブジェクトでアドレスやバイト オフセットを実際に使用することが困難になる可能性があります。

クラウドコンピューティングの利点

（１）クラウドプラットフォームはユーザーのために管理されるインフラです。

クラウドでは、展開、信頼性、管理がユーザーの懸念事項となります。電源、ソフトウェアのインストール、ハードウェアからオペレーティング システムの管理、セキュリティ (強化から侵入検知まで) まで、スタックのすべてのレイヤーは、クラウド コンピューティング ベンダーによって管理されます。

クラウド ベンダーの無料トライアルの利便性により、ユーザーは最初の実験を開始して実行し、必要に応じて大規模に拡張することができますが、これは従来のオンプレミス システムでは困難です。

もう 1 つの利点は、クラウド コンピューティング ベンダーが、サードパーティの SaaS 製品との統合のための標準化されたプロセスを多数提供していることです。その結果、クラウド コンピューティング プロバイダーはインフラストラクチャの問題を他人事にし、ユーザーがコア ビジネスに集中できるようにします。

（２）効率性

クラウド コンピューティングはリソースの利用率を最大化できます。クラウド コンピューティング システムでは、非クラウド システムよりも、データベース アプリケーションにリソース使用率制御を公開する方がはるかに一般的です。クラウド コンピューティングは、負荷を平準化して需要の少ない期間に移動し、インタラクティブなジョブやビジネス クリティカルなジョブを優先することができます。

もちろん、クラウド コンピューティング プロバイダーは、大規模な調達、負荷分散、非常に高い利用率による効率性を活用できます。これらのスケール パラメータだけでも、クラウドに移行する理由になります。強化と侵入検知にベンダーの専門知識を活用することのメリットは言うまでもありません。

規模と密接に関連しているのは、クラウド コンピューティング ベンダーが低価格でパッシブ ストレージを提供できることです。これにより、実験や分析の目的、バックアップや監査の目的を問わず、履歴データをより長期間保持することが容易になり、タイム トラベルなどの機能を実装して履歴の観点からデータを調査するコスト効率が向上します。

もちろん、クラウド コンピューティング プロバイダーのスケールを利用して一時的にスケールアウトすることで、データ処理の負荷が重くなる問題を解決できますが、当然ユーザーはこれに費用を支払うことになります。

（３）経済的である。

規模の経済と効率性を超えて、クラウド コンピューティング ベンダーの会計メカニズムは、ストレージと処理のコスト データを個々のクエリ レベルまで公開する傾向があります。これにより、ユーザーは特定の分析の費用対効果について適切なビジネス上の意思決定を行い、それに応じて最適化の決定を行うことができます。実際、ユーザーは、時間と労力をかけて「堅牢な分析」を形成するよりも、クラウド コンピューティングの規模を拡大して分析の構造をスケールアップして簡素化する方が、コストが安く、精度も高くなると判断する場合があります。

クラウドコンピューティングの弱点

（１）クラウドプラットフォームはユーザーのために管理されるインフラです。

クラウド コンピューティングには、メインフレームとはまったく異なる一連の障害ドメインがあります。クラウド プラットフォーム上の分散コンピューティングは共有インフラストラクチャ (コンピューティング、ストレージ、ネットワーク) であるため、干渉を受けやすく、障害が発生すると対話性障害や一時的な作業障害が発生する可能性があります。まれに、クラウド ベンダーの自動管理によっても、システムのプロパティや動作が変更され、顧客エクスペリエンスに悪影響が及ぶ場合があります。

（２）効率性

ほとんどのクラウド データベースは、従来のオンプレミス システムと比較するとまだ未熟です。クラウド データベースには、より成熟した製品の機能が欠けています。完全に分散された、障害が発生しやすいプラットフォームという概念では実用的ではないため、一部の機能は導入されない可能性があります。

多くのクラウドベースの並列リレーショナル システムは、特定のデータベース変更 (INSERT、UPDATE、DELETE) 操作に対しては効率が大幅に低く、特定のユース ケースで問題が発生する可能性があります。

もちろん、クラウドとオンプレミス システム、または他のクラウドでホストされているシステム間の追加の遅延により、クラウド インフラストラクチャの統合が必要になることがよくあります。多くの場合、ユーザーは最初に地理的な場所とクラウド コンピューティング プロバイダーを選択する必要があり、その後はクラウド コンピューティング プロバイダーが提供するサービスに事実上制限されます。

（３）経済的である。

クラウド コンピューティングのコストは、オンプレミス展開とはまったく異なる曲線を描きます。つまり、容量の拡張が非常に簡単です。コスト管理が難しくなります。一方、コストに上限が設定されている場合、コスト上限に達した後に送信されたインタラクティブ ジョブは拒否される可能性があります。これにより、従来のデータベース管理者がデプロイメントを成功させるために習得する必要のある複雑さがさらに増します。

もちろん、クラウド コンピューティングのベンダー ロックインは企業にとって一般的です。クラウド間の移行は、オンプレミス システム間の移行ほど簡単ではありません。

ユーザーが選択できる製品は非常に多くありますが、すべての機能を備えた製品は存在しません。最も重要な最初のステップは、必要なすべてのワークフローの重要なプロパティまたは動作を特定し、選択したクラウド コンピューティング ベンダーがこれらのサービスを提供する能力を持っていることを確認することです。これらのサービスはそれぞれ異なる製品から提供される可能性がありますが、少なくとも統合が弱い製品から提供される可能性があります。したがって、Oracle や Teradata が提供するような製品に「すべて」を期待しないでください。