分割する理由
Caicaiは、正式に開始する前に、データテーブルを分割する必要があるかどうかは、ビジネスのデータ量が分割する必要のある規模に達しているかどうか、現在の問題を解決する他の解決策があるかどうかなど、多くの要因を包括的に考慮する必要があることを強調する必要があります。 ？何度も見たことがありますが、全体の状況を考えずにやみくもにテーブルを割っているリーダーもいます。その結果、全員が996週間連続で残業しています。あなたは髪を失うリーダーになりませんか？一部のアーキテクトは、小規模ビジネスの開始時にテーブルを分割します。あなたと協力するために、あなたは追いつくためにノンストップの残業も行っています。オンラインにした後、彼らはビジネスデータの量が非常に少ないことに気付きますが、コードはテーブル分割戦略によって制限されすぎています。 。テーブルの解体によって引き起こされる問題は、特定のシナリオでは非常にコストがかかる場合があります。
データベーステーブルの分割によって解決される問題は、主にストレージとパフォーマンスの問題です。単一のテーブルのデータ量が一定のレベルに達すると、mysqlのパフォーマンスは急激に低下します。sqlserverやOracleなどのDBに課金する場合と比較して、mysqlはまだいくつかの側面にあります。不利ですが、テーブル分割の戦略は、ほとんどすべてのリレーショナルデータベースに適用できます。
データベースの分割に目がくらんではいけません
サブテーブル戦略
テーブル分割とデータベース分割には類似点がありますが、分割のルールも異なります。次の分割ルールは、テーブルを分割するためのものです。
水平セグメンテーション
水平セグメンテーションは、多くのビジネスで最も一般的に使用されるセグメンテーション方法です。本質は、最も一般的なID範囲やビジネスプライマリキーのハッシュ値などのルールに従って、1つのテーブルのデータ行を複数のテーブルに分散することです。セグメント化されるテーブルデータの大きさの順序に関しては、これはテーブルに格納されるデータ形式に関連します。たとえば、intフィールドの列が数列しかないテーブルは、テキストタイプのテーブルの数列よりも高いストレージ制限が必要です。この制限が1000万であると仮定しましょう。ただし、システムの担当者または設計者として、テーブルのデータレベルが数千万レベルに達した場合、これはシステムパフォーマンスのボトルネックの隠れた危険であるため、注意を払う必要があります。
データテーブルの水平セグメンテーションと比較して、ビジネスの最適化を満たすシナリオでテーブルパーティションを作成し、ルールに従って異なるパーティションを異なる物理ディスクに割り当てることを好みます。このように、ビジネスのSQLステートメントはほとんど変更できません。当社のsqlserverデータベースは、ビジネステーブルが分割された後、数十億のデータ量に達しましたが、クエリと挿入の速度は依然としてビジネスのニーズを満たすことができます（システムを最適化するには、ビジネスレベルを最適化するための努力が必要です。 ）。
垂直分割
垂直分割と言えば、テーブルをビジネスごとに分割することもできます。たとえば、データベース内にユーザー情報があり、ビジネスごとに基本情報と拡張情報に分けることができます。ビジネスにとって有益な場合は、完全に基本情報テーブルに分割して拡張することができます。インフォメーションシート。もちろん、頻繁にアクセスする情報を1つのテーブルに分割したり、他のまれな情報を1つのテーブルに分割したりするなど、他のルールに従って分割することもできます。特定の分割ルールは、その時点で解決する問題によって異なります。垂直分割は複雑さをもたらす可能性があります。たとえば、ユーザーの基本情報と拡張情報の元のクエリで一度に結果をクエリでき、テーブルを分割した後、結果をクエリするには結合操作または2つのクエリが必要です。
サブテーブルのコスト
- データテーブルが垂直方向に分割された後、元のクエリがテーブルの結合クエリになる可能性があります。これにより、パフォーマンスがある程度低下します。
- データテーブルの水平セグメンテーションには特定のルールが必要です。主に、範囲セグメンテーションとハッシュ値セグメンテーションの2つの一般的に使用されるルールがあります。範囲セグメンテーションとは、特定のフィールドの範囲に応じたセグメンテーションを指します。たとえば、ユーザーテーブルはユーザーIDに従ってセグメント化され、IDはユーザーテーブル1では1〜100,000、ユーザー2では100001〜2,000万であるため、このセグメンテーションはメリットは、データ移行の問題を考慮せずに無制限に拡張できることです。デメリットは、新しいテーブルと古いテーブルのデータ分散が均一でなく、サブテーブルの範囲を選択するのが難しいことです。範囲が小さすぎると、テーブルが多すぎて多すぎます。問題がまったく解決されていないという混乱を引き起こします。別のテーブル分割戦略は、ハッシュ値に従って列を異なるテーブルにルーティングすることです。また、例としてユーザーIDを取り上げます。最初に10個のデータベーステーブルを計画する場合、ルーティングアルゴリズムは単純にuser_id％10を使用できます。の値は、データが属するデータベーステーブル番号を表します。ID985のユーザーは番号5のサブテーブルに配置され、ID10086のユーザーは番号6のワードテーブルに配置されます。このセグメンテーションルールの利点は、各テーブルのデータ分散が比較的均一であるということですが、後の拡張はデータの一部を移行するように設計されます。
- テーブルが分割された後、操作による順序がある場合、データベースは無力になり、ビジネスコードまたはデータベースミドルウェアによってのみ実行できます。
- 検索ビジネス要件がある場合、sqlステートメントは、複数のテーブルを結合してテーブルを照会するためにのみ使用できます。同様に、カウント統計操作などの統計要件もあります。
あなたのビジネスでテーブル分割を実行したことがありますか？
よりエキサイティングな記事
