なぜデータベースを分割するのでしょうか?
データベースの負荷とデータ量によって異なります。
単一プロジェクトの構築開始時は、データベースの負荷やデータ量が大きくないため、データベースを分割する必要がなく、小規模な金融システム、文書システム、ERPシステムなどであれば、基本的にMySQLデータベースインスタンスで十分です。 、OAシステムなど。
「タオバオテクノロジーの10年」で述べたように、電子商取引ビジネスのデータ量は急速に増加しており、初期のPHP+MySQLアーキテクチャでは実際の要件を満たせなくなったため、タオバオが最初に考えた方法はMySQLを使用することでした。オラクルに置き換えました。しかし、それから間もなくの 2008 年頃、単一ノードの Oracle データベースは使いにくくなったため、タオバオはついに単一ノード データベースに別れを告げ、データベースを分割し始めました。1 つのノードから複数のノードへ。
データベースの分割は特殊で、例えば、垂直分割と水平分割の 2 つの分割方法があります。では、最初に水平に分割しますか、それとも垂直に分割しますか? 順序は重要ですか? いいえ、順序は重要です。順序は決して間違ってはなりません。最初に水平に分割し、次に垂直に分割します。
垂直分割とは何ですか?
垂直分割とは、データベースを業務に応じて分割することです（つまり、異なる業務のテーブルには異なるデータベースが存在します）。同じ種類の業務のデータ テーブルは独立したデータベースに分割され、別の種類のデータ テーブルは分割されます。他のデータベースに分割されます。
たとえば、新しい小売電子商取引データベースの場合、製品関連のデータ テーブルをデータベースに分割し、これらのデータ テーブルに基づいて製品システムを構築できます。たとえば、JAVA または PHP 言語を使用してモール システムを作成します。次に、フォローアップ、販売、在庫に関連するデータ テーブルを別のデータベースに分割し、プログラムを使用して倉庫システムを構築します。
垂直スライスはどのような問題を解決しますか?
垂直シャーディングにより、単一ノード データベースの負荷を軽減できます。すべてのデータ テーブルが 1 つのデータベース ノードに配置されており、すべての読み取りおよび書き込みリクエストもこの MySQL に送信されることは間違いないため、データベースの負荷が高すぎることがわかります。ノードのデータベースが複数の MySQL データベースに分割されている場合、各 MySQL データベースの負荷を効果的に軽減できます。
垂直分割では解決できない問題とは
垂直分割ではテーブルの縮小を解決できません。たとえば、商品テーブルをどのデータベース ノードに分割しても、商品テーブルには依然として非常に多くのレコードが存在します。データベースをどれほど詳細に垂直分割しても、データ量は減少します。各データテーブルは変更なし。
MySQL では 1 つのテーブルに 2,000 万を超えるレコードがあり、読み取りおよび書き込みのパフォーマンスが急激に低下するため、垂直分割ではテーブルを縮小する効果が得られません。
水平分割とは何ですか?
水平分割とは、特定の分野の特定のルールに従ってデータを複数のデータテーブルに分割することです。データ テーブルを部分に分割し、複数のデータ テーブルに分割することで、テーブルの縮小効果を実現します。
多くの人は水平セグメンテーションを誤解しており、水平セグメンテーションによって取得されたデータ テーブルは異なる MySQL ノードに保存される必要があると考えています。実際、水平方向に分割されたデータ テーブルも MySQL ノードに保存できます。水平シャーディングには必ずしも複数の MySQL ノードが必要というわけではありません。なぜそんなことを言うのですか？
多くの人は、MySQL には、特別なルールに従ってテーブルのデータを異なるディレクトリに分割して保存できるデータ パーティショニング テクノロジが搭載されていることを知りません。Linux ホストに複数のハードディスクをマウントする場合、MySQL パーティショニング テクノロジを使用して、テーブルのデータを複数のハードディスクに分割して保存できます。このようにして、1 台のハードディスクの元々の制限された IO 能力が、複数のディスクの拡張された IO 能力にアップグレードされます。
スプリット ホライズンの使用法
水平シャーディングでは、テーブルのデータを複数のデータ テーブルに分割でき、テーブルを縮小する役割を果たす可能性があります。
ただし、すべてのデータ テーブルを水平方向に分割する必要があるわけではありません。データのセグメント化は、電子商取引システムのユーザー テーブル、商品テーブル、製品テーブル、住所テーブル、注文テーブルなど、大量のデータを含むデータ テーブルにのみ必要です。ブランド テーブル、サプライヤー テーブル、倉庫テーブルなど、データ量が大きくないため分割する必要のないデータ テーブルもあります。
スプリットホライズンのデメリット
異なるデータテーブルの分割ルールは一貫していないため、実際のビジネスに応じて決定する必要があります。したがって、データベースミドルウェア製品を選択するときは、豊富なセグメンテーションルールを備えた製品を選択する必要があります。一般的なデータベース ミドルウェアには、MyCat、Atlas、ProxySQL などがあります。MyCat は Java 言語で開発されているため、MyCat の効率を疑問視する人もいます。実際、データベースミドルウェアの役割は SQL ステートメントのルーターに相当します。ホームルーターのハードウェア構成はそれほど高くありませんが、100M ブロードバンドの楽しみには影響しません。同じことが MyCat にも当てはまります。MyCat は SQL ステートメントを転送する役割のみを果たし、実際には SQL ステートメントを実行しません。MyCat を使用することをお勧めする主な理由は、主キーに従ってデータをセグメント化する、主キーの範囲に従ってデータをセグメント化する、日付に従ってデータをセグメント化するなど、多くのデータ セグメント化ルールが付属していることです。したがって、ビジネスのニーズを満たすために、MyCat は現在非常に優れたミドルウェア製品であると考えられています。
水平シャーディングのもう 1 つの欠点は、容量を拡張するのがより面倒であることです。時間の経過とともに、遅かれ早かれシャーディングだけでは十分ではなくなります。現時点では、新しいクラスター フラグメントを追加することは最初の選択肢ではありません。MySQL シャードには 4 ～ 8 個の MySQL ノード (最小規模) が必要なため、シャードを追加する投資コストは非常に高くなります。したがって、正しいアプローチは、ホット データとコールド データを分離し、データを定期的にシャードにアーカイブすることです。期限切れのビジネス データをシャードからアーカイブに転送します。現在、最もデータ圧縮率が高いMySQLエンジンはTokuDBであり、トランザクションの書き込み速度はInnoDBエンジンの6～14倍となっています。アーカイブデータベースとしては、TokuDB を使用するのが最適です。
最初に水平分割を行ってから垂直分割を行うのはなぜですか?
データ量が増加するにつれて、最初に行うべきことはデータをシャーディングし、複数のハードディスクを使用してデータ IO 能力とストレージ容量を増やすことです。そうするコストが最も低くなります。少数のハードドライブでは良好な IO パフォーマンスが得られます。
次の段階に入り、データ量は増え続けますが、このときデータを複数の MySQL ノードに分割し、MyCat を使用してデータ分割を管理する必要があります。もちろん、データの読み取りと書き込みの分離なども行う必要がありますが、ここでは説明しません。バックグラウンドで水平セグメンテーションを実行しながら、業務システムは負荷分散や分散アーキテクチャなどを導入することもできます。理論的には、ホット データとコールド データの分離を使用した後、水平セグメンテーションの方法は、データ量がどれほど大きくても、定期的にアーカイブするだけで長期間継続できます。
データベースは水平分割の段階に達しており、データ量の増加はもはやアーキテクチャ設計を変更する主な理由ではありません。逆に、この段階では業務システムが耐えられない、システムをモジュールに分割しないと業務システムが耐えられない、ということで、システムをモジュールごとにいくつかのサブシステムに分割し、ビジネス。いくつかのサブシステムの中で、データは比較的独立しています。たとえば、タオバオはアリペイとすべてのデータを共有するわけではなく、同じデータテーブルのセットを共有することになるが、これはそれぞれのビジネスの発展にも影響を与えるだろう。したがって、垂直セグメンテーションを実行し、データテーブルを分類し、それらを複数のデータベースシステムに分割する必要があります。
そういえば、よく考えてみてください。データベースが早期に垂直分割されると、複数の独立した業務システムを再構築する必要があり、作業負荷が過大になります。水平セグメンテーションは業務システムに大きな変更を必要としないため、まずは水平セグメンテーションから始めるべきです。