MySQL 20 の高性能アーキテクチャ設計原則 (収集する価値あり)

オープンソース データベース アーキテクチャの設計原則

01. 技術の選択

最も使い慣れていて、最大限に活用できる成熟したプラットフォームとテクノロジーを選択し、悪いものではなく良いものを、新しいものではなく使い慣れたものを使用してください。現在、業界で主流の MySQL ブランチ バージョンには、Oracle の公式バージョンの MySQL、Percona Server、および MariaDB が含まれます。

02. 高可用性オプション

高可用性ソリューションの本質は、ダウンタイムの少ないソリューションを模索することです。高可用性の反対は非可用性であると理解できます。ほとんどの場合、データベースのダウンタイムはデータベースの非可用性につながります。技術の発展に伴い、オープンソース データベースには多くの高可用性コンポーネント (マスター スレーブ レプリケーション、半同期、MGR、MHA、Galera Cluster) があります。対応するシナリオには、万能薬ではなく、適切なコンポーネントが 1 つだけあります。各高可用性コンポーネントの長所と短所を理解する必要があります。

03. テーブルデザイン

現在、テーブル設計において一貫して遵守され、推奨されている原則は次のとおりです。

• 単一テーブルのデータ量
  

すべてのテーブルに注釈を付ける必要があり、1つのテーブル内のデータ量は3000万以内に抑えることが推奨されます。

• 大きなフィールドデータを保存しない
  

画像やファイルなどの大きなデータをデータベースに保存しない

• 表の使用ガイドライン

大きなフィールドとアクセス頻度の低いフィールドを分割して、ホットデータとコールドデータを分離します。

1つのテーブル内のフィールド数は20以内に抑える必要がある。

• インデックス仕様
  

1. 1つのテーブル内のインデックスの数は5を超えない

2. 1つのインデックス内のフィールドの数は5を超えない

3. INNODB 主キーの場合、自動インクリメント列を使用することをお勧めします。主キーは変更しないでください。また、文字列を主キーとして使用しないでください。

主キーを指定しない場合、INNODB は代わりに一意で null 以外の値のインデックスを使用します。

4. 複合インデックスの場合は、最も差が大きいフィールドをインデックスの先頭に配置する

5. 冗長または重複したインデックスを避ける: 適切なジョイントインデックスを作成する(冗長性を避ける)

6. '性別'などのカーディナリティの低い列にインデックスを作成しないでください。

7. インデックス列に対して数学演算や関数演算を実行しない

• 文字セット utf8mb4 (珍しい文字、絵文字)
  

04. 最適化の原則

05. コピー方法

MySQL レプリケーションは、非同期モード、半同期モード、グローバル トランザクションの強力な一貫性、および binglog 同期を提供します。異なるビジネス システム間または 2 つのデータベース間で同期が必要です。非同期方式では、障害の拡散や拡大、効率の問題を防ぐことができますが、強力な一貫性はより複雑になり、同時実行性とトランザクション サイズが制限されます。

06. 分離原則

基幹業務、重要業務、チャネル、社内業務など業務システムを区別し、システムごとに異なるアーキテクチャを構築します。コアビジネスに最適な設定はサブデータベースとマルチアクティブ専用ハイウェイを使用することですが、他のビジネスでは読み取り/書き込み分離とキャッシュを使用できます。

07. スケーラビリティ

システムにとってスケーラビリティは非常に重要であり、水平方向の拡張は可能な限り実現する必要があります。垂直方向の拡張に過度に依存しないようにし、垂直方向と水平方向の両方に拡張できる能力を備えてください。たとえば、ステートレス アプリケーションは、複数の負荷分散セットとマルチアクティブ データベース アーキテクチャを使用して展開する必要があります。

08. 読み取りと書き込みの分離

• 読み取りが多く書き込みが少ないシナリオ（書き込み 10%、読み取り 90%）
• レプリケーションには遅延があるが、ビジネスは遅延に敏感ではない
• 実装：

1. アプリケーションコードを通じて読み取りと書き込みの分離を構成する。

2. 読み取り専用ライブラリを中間プロキシ経由でルーティングする

3. ビジネスとデータベースを一体化

09. データベースとテーブルを分離する

• テーブル内のデータ レコード数が 3,000 万を超えると、最適なインデックスを使用してもデータ クエリの速度を向上させることはできません。このとき、パフォーマンスと柔軟性を高め、データベースのクラッシュを回避するには、テーブルをより多くの小さなテーブルに分割する必要があります。
• 中間価格の導入には、パフォーマンスコストと集約需要を考慮する必要があります。
• データベース分割の原則は、データベースをできるだけアプリの上位層、つまりトラフィックで分割することです。
• 適切なポイント数: 可用性とパフォーマンスが TPS を満たします。
• ルーティング: 構成ファイルに書き込むか、テーブルまたは Zookeeper を挿入します。
  

10. アーカイブの原則

履歴データは定期的にアーカイブされるか、他のビッグデータ プラットフォームに移動されます。軽量データベースでより有用なデータをキャッシュできるようになります。

MySQL のパーティション化されたテーブルでは、パーティション ロックと書き込み専用の読み取りシナリオを回避するように注意してください。

11. 接続プールの要件

ロングリンク、自動再リンク、遅延および例外記録、弾性リンク、完全検出、異常アラーム、高度な要件

あらゆるアクセス状況を記録し、多くの機能を拡張できます。

アプリケーションとデータベースの接続プールの設定、データベースで許可される接続数の設定、および一般的な問題。

A) アプリケーションのデータベース接続プールが小さすぎる。データベースの応答が遅い場合（新しいアプリケーション、インデックスの不足など）、

深刻な待ち行列や雪崩さえ発生しており、残念ながらデータベースの容量が枯渇するには程遠い状況です。

B) 障害をタイムリーに検出し、データベースに再接続する機能がありません。

C) 分離レベルの設定: RR と RC ではパフォーマンスが異なります。

12. アプリケーションの分離

データベースには直接アクセスするのではなく、アプリケーションを介してアクセスします。重要な業務は、セキュリティ レベルの低いシステムに依存することはできません。アプリケーション レイヤーで重要な業務と通常の業務を切り離し、主要な業務を独立させる必要があります。

13. コンポーネント障害耐性

単一のアプリケーション、単一のハードウェア、または単一のインフラストラクチャ、単一サイトの災害復旧、ビジネスへの影響、および障害復旧機能は、四半期ごとに訓練する必要があります。

14. キーワードコンポーネントの負担を軽減する

特にデータベース アクセスの場合、データベース コストが最も高く、スケーラビリティが最も難しく、可用性の保証が最も難しく、リカバリが最も困難で時間がかかります。

負担を軽減する: 可能であれば使用せず、最も単純でコストの低いステートメントを使用し、大規模なトランザクションを避け、2 フェーズ トランザクションを慎重に使用します。

15. グレースケールデータベース

リリース中のデータベース変更による全体的な影響を軽減するには、アプリケーションのグレースケールだけでなく、専用のグレースケール データベースも用意するだけでは不十分です。データベースのパーティショニングと読み取り/書き込み分離アーキテクチャでは、データベースを含む完全なアプリケーション アーキテクチャが非常に自然になります。

いわゆるグレースケール環境は、本番環境と本番データのことであり、本番環境にも影響を及ぼしますが、その範囲はテスト環境よりも広く、より現実的です。実際には小規模な生産環境です。ゲームのベータ版に似ています。

16. 高度なシミュレーションアーキテクチャシステム

高度なシミュレーションアーキテクチャシステムの構築

• データベースとオペレーティングシステムのアップグレード: アプリケーションが適応するかどうか、パフォーマンスが向上するか低下するか
• アプリケーションの起動とシステムの変更（プラットフォームの変更など）により、ビジネスへの影響とパフォーマンスのボトルネックを予測します。
• ダブルイレブンの買い物ラッシュ時のような突然の取引量に対処するには、パフォーマンスの限界とボトルネックがどこにあるかを理解する必要があります。
  

17. 災害復旧

高可用性は運用と保守の中心的な要件であり、災害復旧は最後の障壁です。

たとえば、アクティブ/アクティブ デュアルはアクティブ/アクティブ シングルよりも優れており、MGR はレプリケーション アーキテクチャよりも優れており、重要なシステムは高可用性と災害復旧のために構築する必要があります。

18. 多拠点建設

冗長化は基盤であり、多拠点化は災害復旧能力と拡張能力を向上させ、ビジネスを確実にするためです。

19. アプリケーションとデータベースが統合されている

アプリケーションと運用保守担当者が連携して、アプリケーションの分離、データベースの分離、債権回収と補充、業務監視、アプリケーションのルーティング、障害切り替えなどの問題を解決します。可用性、効率性、障害回復などのすべての側面を考慮する必要があります。

20. パフォーマンスの改善

オープン ソース データベースの使用は合理的であり、パフォーマンスを最大化するために他の種類の周辺データベースと効果的に組み合わせる必要があります。例: Redis、MongoDB、ES、ClickHouse など。

要約する

1. 最も適切なアーキテクチャは、コストと利益のバランスを取りながらソフトウェア機能とビジネス シナリオを組み合わせたものです。

2. ビッグデータの場合、読み取りと書き込みの分離やデータベースとテーブルのシャーディングを使用できますが、適切なものを選択する必要があります。

3. データベースシャーディングに適していない場合は、コアデータベースを可能な限り小さくしてから、垂直拡張によって容量を拡張することを検討する必要があります。

4. さまざまなテクノロジー、高可用性、災害復旧対策を使用して可用性を確保します。

以上がMySQL 20の高性能アーキテクチャ設計原則（収集する価値あり）の詳細な内容です。MySQLアーキテクチャ設計の詳細については、123WORDPRESS.COMの他の関連記事に注目してください。