AnalyticDB for MySQLには、Data Lakehouse Edition (V3.0) とData Warehouse Edition (V3.0) の2つのエディションがあります。 このトピックでは、さまざまなAnalyticDB for MySQLエディションの機能と仕様について説明します。
AnalyticDB for MySQLエディション
データレイクハウスエディション (V3.0)
Data Lakehouse Edition (V3.0) は、コンピューティングとストレージを分離し、費用対効果の高いバッチ処理と高性能なリアルタイム分析機能を統合する分離アーキテクチャを使用しています。 Data Warehouse Edition (V3.0) と比較して、Data Lakehouse Edition (V3.0) は、完全に拡張されたデータ収集、ストレージ、コンピューティング、およびアプリケーション機能を備えています。 このエディションでは、Object Storage Service (OSS) またはC-Storeテーブル上のHudiテーブルへのデータ同期を、視覚化された方法でリアルタイムに設定できます。 下位のストレージ層に保存された完全なデータの単一のコピーを使用して、バッチ処理とリアルタイム分析の両方を実行します。 これにより、データ同期中に発生する一貫性と適時性の問題が防止されます。 コンピューティング層は、標準化されたAPIを使用するSpark多言語プログラム可能なコンピューティングエンジンをサポートします。 さらに、Data Lakehouse Edition (V3.0) のコンピューティングリソースは、バッチ処理とリアルタイム分析のために物理的に分離されています。 ビジネス要件に基づいて、コンピューティングリソースとストレージリソースを個別にスケーリングできます。
このエディションは、データ処理 (データクレンジングや標準化など) 、マルチソースの集計分析とテーブル結合、予測と洞察 (機械学習やAIなど) のシナリオに最適です。
エラスティックモードのData Warehouse Edition (V3.0)
Data Warehouse Edition (V3.0) は、コンピューティングストレージと分離されたアーキテクチャに基づいて構築されており、大量のデータをリアルタイムで書き込み、高性能なリアルタイム分析を実行できます。 このエディションでは、ビジネス要件に基づいてコンピューティングリソースとストレージリソースを個別にスケールアップできます。 また、ホットデータとコールドデータの階層ストレージを提供し、ストレージコストを削減します。 さらに、コンピューティングリソースは、バッチ処理およびリアルタイム分析のために物理的に分離される。
このエディションは、大量のデータをリアルタイムで書き込み、複雑な抽出-変換-読み込み (ETL) 操作を実行し、大量のデータに対して複雑なクエリを実行し、履歴データとログを分析するのに最適です。
エラスティックモードのData Warehouse Edition (V3.0) は、Basic EditionとCluster Editionで利用できます。
ベーシックエディション
Basic Editionは単一のノードにデプロイされます。 分散アーキテクチャの利点はありません。 このエディションは、ホットデータとコールドデータの階層ストレージをサポートしますが、高可用性、リソースグループの分離、またはスケジュールスケーリングはサポートしていません。 Alibaba CloudはBasic Editionのサービスレベル契約 (SLA) 保証を提供しておらず、フェールオーバーには4〜8時間が必要です。 本番環境ではBasic Editionを使用しないことを推奨します。 Basic Editionは、大量のデータ、高クエリ /秒 (QPS) 、または高可用性を必要としないシナリオに適しています。 個々の開発者がテストを実行し、スタートアップや中小企業が基本的なビジネスを処理することは理想的です。
クラスターエディション
Cluster Editionは複数のノードにデプロイされ、分散アーキテクチャの利点を提供します。 このエディションは、企業の開発、テスト、および生産に役立つより強力な機能を提供します。
予約モードのData Warehouse Edition (V3.0)
Data Warehouse Edition (V3.0) は、ストレージ-コンピューティング-分離アーキテクチャに基づいて構築されています。 これは、高スループットのリアルタイム書き込み、高い同時実行性、および迅速な応答を提供します。 このエディションは、クエリの高速化、ユーザープロファイリング、インタラクティブレポート、リアルタイムデータサービスなどのシナリオに適しています。
特徴
次の表は、さまざまなエディションの機能を比較しています。
カテゴリ | 機能 | Data Lakehouse Edition (推奨) | データウェアハウス版 | |
弾性モード | 予約モード | |||
コンピューティング | XIHE分析計算エンジン | 対応 | 対応 | 対応 |
Sparkプログラム可能な計算エンジン | 対応 | 非対応 | 非対応 | |
ストレージ | XUANWU分析ストレージエンジン | 対応 | 対応 | 対応 |
コスト効率の高いHudiストレージ | 対応 | 非対応 | 非対応 | |
リソース管理 | リソースグループ管理 | 対応 | Cluster Editionのみサポート | 非対応 |
スケジュールされたスケーリング | 対応 | Cluster Editionのみサポート | 非対応 | |
オンデマンドのスケーリング | 対応 | 非対応 | 非対応 | |
ホットデータとコールドデータ用の階層ストレージ | 対応 | 対応 | 非対応 | |
データインポート | リアルタイムデータのインポート | 対応 | 非対応 | 非対応 |
自動メタデータ検出 | 対応 | 非対応 | 非対応 | |
ジョブの開発 | SQLジョブ開発 | 対応 | 非対応 | 非対応 |
Spark求人開発 | 対応 | 非対応 | 非対応 | |
ジョブスケジューリング | 対応 | 非対応 説明 このエディションでは、ネイティブのジョブスケジューリング機能は提供されません。 ジョブスケジューリングは、Data Management (DMS) またはDataWorksを使用して実装する必要があります。 | 非対応 | |
仕様
データレイクハウスエディションの仕様 (V3.0)
コンピューティングリソース | ストレージリソース |
最小: 16 AnalyticDBコンピューティングユニット (ACU) 最大: 4,096 ACU | 最小: 24 ACU 最大: 2,064 ACU |
予約済みコンピューティングリソースのACUを512以上、または予約済みストレージリソースのACUを256以上購入する場合は、チケットを起票してください。
弾性モードでのData Warehouse Edition (V3.0) の仕様
カテゴリ | コンピューティングリソース |
基本版 | 8コアと32 GBメモリ、16コアと64 GBメモリ |
Cluster Edition | 最小: 16コアと64 GBメモリ 説明 2022年9月1日から中国本土で購入され、16コアおよび64 GBメモリ、または24コアおよび96 GBメモリを持つCluster Editionクラスターは、複数のノードにデプロイできます。 |
予約モードでのData Warehouse Edition (V3.0) の仕様
インスタンスタイプ | リソースプランの仕様 | ||
CPU | メモリ (GB) | ストレージ (GB) | |
C8 | 24コア | 192 | 最小: 100 最大: 2,000 |
C32 | 96コア | 768 | 最小: 100 最大: 8,000 |
よくある質問
クラスターのエディションを表示するにはどうすればよいですか。
AnalyticDB for MySQLコンソールにログインし、クラスターの [クラスター情報] ページに移動します。 [クラスター属性] セクションでは、クラスターのエディションとモードを表示できます。
エラスティックモードのData Warehouse Edition (V3.0) と予約モードのData Warehouse Edition (V3.0) の違いは何ですか?
ストレージリソースの課金方法は、2つのモードで異なります。
予約モードでは、クラスターを作成するときに必要なストレージ容量を指定する必要があります。 指定されたストレージ容量に基づいて課金されます。
エラスティックモードでは、クラスターを作成するときにストレージ容量を指定する必要はありません。 ストレージ使用量に基づいて課金されます。
たとえば、従量課金クラスターを購入し、特定の日のストレージ使用量が100 GBの場合、次の式に基づいてストレージリソースに対して課金されます。100 GB × 使用期間。 エラスティックモードでは、AnalyticDB for MySQLは20 GBのストレージに基づいて最小料金を課します。 ストレージ使用量が20 GB未満の場合でも、20 GBのデータストレージに対して課金されます。
エラスティックモードでは、コンピューティングリソースはストレージリソースから分離されます。 コンピューティングリソースは、データを処理および計算するために使用されます。 ストレージリソースは、データの読み書きに使用されます。 これにより、ワークロードのパフォーマンスのボトルネックがコンピューティングリソースまたはストレージリソースに起因するかどうかを特定し、それに応じてリソースをスケールしてコストを削減できます。
可用性はどのシナリオで影響を受けますか?
AnalyticDB for MySQLクラスターの可用性は、クラスターで障害が発生した場合、またはクラスターの構成変更やバージョンのアップグレードが行われた場合に影響を受ける可能性があります。