ベストプラクティス - PolarDB - Alibaba Cloud ドキュメントセンター

一般的なシナリオ

さまざまなシナリオで分散データベースに接続する必要がある場合があります。 PolarDB-Xは、古いアプリケーションと新しいアプリケーションのデータベースとテーブルの使用、SQL特性、パフォーマンスとスループットの要件に基づいて、使用シナリオを4つの一般的なアプリケーションタイプに2.0に分割します。次の表に、アプリケーションの種類を示します。

アプリケーションタイプ	例	説明	SQL特性
大量の既存ビジネスを持つアプリケーション	医療会社や病院で10年以上使用されているビジネスシステム	既存のビジネスでは、多数のデータベースとテーブルが使用されています。データベースの数が10以上、またはテーブルの数が100以上。さまざまなタイプのSQLクエリが必要です。スタンドアロンデータベースのリソースは限られており、ビジネスクエリの応答時間 (RT) は遅くなります。	データベースは、多数の古いアプリケーションによって使用され、既存のビジネスに使用される多数のデータベースまたはビジネステーブルが存在する。古くて複雑なSQL文が多数存在し、変更することはできません。
既存および新規ビジネスのアプリケーション	長年にわたり事業を運営し、新機能を開発したい売り手の受注管理システム	既存のビジネスでは、比較的多数のデータベースとテーブルが使用されます。データベースの数が2以上であるか、またはテーブルの数が10以上である。新しいビジネスには大きなテーブルを使用する必要があります。また、データが急速に増加するため、スタンドアロンデータベースのリソースが不十分です。	比較的多数のデータベースとテーブルがビジネスに使用されます。既存のビジネスで使用されるSQL文は多数存在し、ほとんどの文は変更できません。新しいビジネスに使用される一部の大きなテーブルとSQL文は、変更および最適化できます。
スタンドアロンMySQLデータベースに基づいて開発された新しいビジネスアプリケーション	写真会社が展開するビジネスシステム	データベースとテーブルの数とビジネス規模は小さいです。データベースの数が2未満、またはテーブルの数が10未満。大量の増分データが生成されることが予想されるため、スケーラビリティが要求される。	ビジネスの初期段階では、システムの即時立ち上げが必要です。後の段階では、システムの高速反復と最適化が必要です。新しいビジネスに使用されるデータベースとSQL文は、変更および最適化できます。
高いパフォーマンスとスループットを備えたビジネスアプリケーション	大手电子商取引会社のコア取引システム	データベースとテーブルの数は少ないですが、データサイズが大きく、同時実行性が高くなります。アプリケーションは、SQLクエリRTに非常に敏感です。ビジネスの全体的なスループットとパフォーマンスは非常に重要です。	いくつかの固定タイプのSQLクエリのみが実行されます。 SQLクエリには、高い同時実行性と安定したパフォーマンスが必要です。

前述のアプリケーションタイプのユーザーは、さまざまなシナリオでさまざまな課題に直面します。ユーザーがアプリケーションを分散データベースに接続するように変換するとき、異なる要件があります。

上記のアプリケーションタイプのユーザーが分散データベースを効率的に使用してビジネス上の問題を解決できるように、PolarDB-Xの透過的な分散機能にはさまざまな作業モードが用意されています。ユーザーは、PolarDB-Xデータベースに初めて接続するときに、ビジネス要件を満たす作業モードを選択できます。

各シナリオで作業モードを推奨

次の表に、PolarDB-Xの透過的な配布機能によって提供される作業モードとそのビジネス効果を示します。

アプリケーションタイプ	最適化の目的	痛みのポイント	推奨作業モード	ビジネス効果
大量の既存ビジネスを持つアプリケーション	スタンドアロンデータベースによって引き起こされるリソース制限、特にCPUとI/Oの制限を破る必要があります。 SQLクエリRTを最適化する必要があります。	既存のビジネスには数百または数千のデータベースとテーブルが使用されており、データベースとテーブル間のJOIN操作は複雑です。ビジネスで実行される元のSQLクエリは複雑で、変更できません。分散データベースのSQL文との高い互換性が必要です。	パーティション分割されていないテーブルsharding	新しいビジネスのデータベース、テーブル、およびSQLステートメントは、既存のビジネスのものと最大限互換性があります。クエリのパフォーマンスはほとんど変わりません。多数の分割されていないテーブルが、異なるデータノード (DN) に分散される。これにより、スタンドアロンデータベースによって引き起こされるリソース制限を突破し、負荷分散を実装し、パフォーマンスを向上させることができます。
既存および新規ビジネスのアプリケーション	スタンドアロンデータベースに起因するリソースの制限、特にCPU、I/O、およびディスクの制限を破る必要があります。ビジネスのSQLクエリのパフォーマンスは変更しない必要があります。大きなテーブルのディスク領域をスケールアウトする必要があります。	既存のビジネスで使用されるデータベースやテーブルは多数存在し、データベースとテーブル間のJOIN操作は複雑です。既存のビジネスで実行されるSQLクエリは複雑であり、ほとんどのクエリは変更できません。新しいビジネスのための特定のデータベースおよびテーブル、特に大きなテーブルのデータ量は急速に増加します。	非パーティションテーブルsharding + manual partitioning 説明作業モードを非パーティション分割テーブルシャーディングに設定した後、`ALTER table <table_name> PARTITION BY KEY(<column_name>) locality='';` ステートメントを実行して、手動パーティション分割を実行します。詳細については、「地域」をご参照ください。	新しいビジネスのデータベース、テーブル、およびSQLステートメントは、既存のビジネスのものと最大限互換性があります。クエリのパフォーマンスはほとんど変わりません。多数の非分割テーブルが異なるDNに分散される。これにより、スタンドアロンデータベースによって引き起こされるリソース制限を突破し、負荷分散を実装し、パフォーマンスを向上させることができます。大きなテーブルに対して手動パーティション分割を実行できます。これにより、ディスクのスケーラビリティの問題を解決しながら、読み取りと書き込みのパフォーマンスが保証されます。
スタンドアロンMySQLデータベースに基づいて開発された新しいビジネスアプリケーション	スケーラビリティが必要です。ビジネスパフォーマンスの要件は高くありません。	変革コストを削減する必要があり、ビジネスをすぐに立ち上げる必要があります。	自動パーティショニング	すべてのテーブルは自動的にパーティション分割されます。これは、スタンドアロンデータベースによって引き起こされるリソース制限を突破するのに役立ちます。デフォルトでは、すべてのインデックスはグローバルインデックスです。これにより、主キー以外の列ベースのクエリの基本的なパフォーマンスが保証されます。
高いパフォーマンスとスループットを備えたビジネスアプリケーション	線形スケーラビリティが必要です。高いパフォーマンスが必要です。	線形スケーラビリティと、毎秒数万または数十万のクエリ (QPS) を伴う同時実行が必要です。ビジネスはパフォーマンスに敏感であるため、SQLクエリは迅速かつ安定している必要があります。	手動パーティショニング	ビジネスシナリオに基づいて、すべてのテーブルに最適なパーティショニングソリューションを手動で選択できます。線形スケーラビリティの要件を満たすように、ビジネスクエリのSQL文を変更できます。