この記事は、データ テーブルに関する関連知識を提供します。主に、データ スキューの問題を解決するための自己均衡テーブルの細分化方法について説明します。興味のある友人は、一緒に見てみると良いでしょう。みんなに役立つ。助けて。
この記事では主に、増加するビジネス データの問題を解決するための B サイド トークン システムのデータ サブテーブルの適用について説明します。ボリュームと既存のデータ スキュー 主なシナリオは 1 対多のデータ スキュー問題です。
最初にビジネスについて簡単に説明します。 B トークンの背景。B トークン システムは、多くのユーザーを 1 つのトークンにバインドし、そのトークンをプロモーションにバインドして差別化と正確なマーケティングを実現するためにマーケティング シナリオで使用されます。一般に、トークンのライフ サイクルはこのプロモーションと同等です。
トークンとトークン ユーザーの関係は 1 対多の関係です。初期のトークン システムでは jed が使用されていました。データベースには 2 つのシャードがあり、途中で拡張が実行されて 8 シャードになり、保存されるデータ行数は 1 億 2,000 万行に達しました
1 億 2,000 万のデータが 8 つのサブデータベースに分散され、各サブデータベースには平均 1,500 万のデータがあります。データベース フィールドはトークン ID (token_uuid) を使用します。トークン ユーザーが少なく、数千人から 10,000 人しかいないフィールドもあれば、100 万から 150 万人という多数のトークン ユーザーがいるフィールドもあります。トークンの総数はそれほど多くなく、わずか約 20,000 です。傾向としては、一部のサブデータベースには 3,000 万を超えるデータがあり、一部のサブデータベースには数百万しかない場合があり、これがデータベースの読み取りおよび書き込みパフォーマンスの低下につながり始めています。また、トークンユーザー関係テーブルのデータ構造は非常に単純であるため、データ行数は多くても、それほどスペースを必要としません。 8 つのサブデータベースの合計占有スペースは 20G 未満です。同時に、トークンのライフサイクルは基本的にプロモーションのライフサイクルと同じであり、トークンは 1 つまたは複数のプロモーションに提供された後、ゆっくりと有効期限が切れて破棄され、将来的には新しいトークンが作成され続けます。したがって、これらの期限切れのトークンはアーカイブできます。
一方で、Bサイドビジネスの発展に伴い、ビジネスニーズも増加しており、ビジネスとのコミュニケーションを通じて、将来的には自動選考システムが開始されることを知りました。トークンを自動生成し、昇進に適した人材を選出 将来的には月間データ増加量は約3,000万、1年間運用すると3億6,000万増加、その頃には1テーブルの平均データ量は60に達する現在の設計アーキテクチャでは、ビジネス ニーズを完全に満たすことができません。
同時にページ内でトークン配下のユーザーをトークンIDに基づいて問い合わせる機能もありますが、これは管理側の操作のみに使用され、頻繁に使用されるものではありません。
データベースの読み書きパフォーマンスの低下に直面する、ビジネスの成長ニーズに加えて、現在、次の問題に直面しています:
単一テーブル内のデータ行が多すぎる問題を解決する方法
現在のサブデータベース スキームには深刻なデータ スキューがあります
将来のデータ増加に対処する場合
一般的に、最初の問題に対処するには、通常、データベースをテーブルに分割する必要があります。 、現在 8 つのパーティションがあります。データベース、および 8 つのサブデータベースが占有するスペースは 20G 未満です。単一データベースのリソースは大幅に浪費されるため、サブデータベースを追加することはまったく検討されません。そのため、テーブル シャーディングが最適です。解決。
データをテーブルに分割するには、通常、垂直テーブルと水平テーブルの 2 つの方法があります。
テーブルの垂直分割とは、データの列を分割し、主キーまたはその他のビジネス フィールドを適用してそれらを関連付けることを指します。これにより、単一のテーブル データが占有するスペースを削減したり、冗長性を削減したりできます。残りのストレージの場合、B トークンのシーン データ構造は単純であり、データの占有スペースがほとんどないため、このテーブル分割方法は使用されません。
水平テーブル分割とは、ルーティング アルゴリズムを使用してデータ行を複数のテーブルに分割することを指します。データは、読み取り時にもこのルーティング アルゴリズムに基づいて読み取られます。このテーブル パーティション化戦略は一般に、データ構造は複雑ではないが、多数のデータ行があるシナリオに対処するために使用されます。これを使用します。この方法を使用する際に考慮する必要があるのは、ルーティングのアルゴリズムをどのように設計するかですが、ここでもテーブルの分割にこの方法が使用されています。
業界ではデータ テーブル ルーティング アルゴリズムを使用する方法がたくさんあります。1 つは、一貫性ハッシュを使用する方法で、適切なサブテーブル フィールドについては、フィールド値をハッシュした後の値が固定されており、この値を使用してモジュロ演算またはビット単位の演算を通じて固定シリアル番号を取得し、データがどのテーブルに格納されるかを決定します。
サブライブラリなどの一般的なアプリケーションの多くはコンシステントハッシュを使用しており、サブライブラリフィールドの値を瞬時に計算することでデータがどのサブライブラリに属するかを判断し、どのサブライブラリに保存するかを決定します。データ内のデータ、またはデータからのデータの読み取り。クエリ中にサブデータベース フィールドが指定されていない場合は、クエリ要求をすべてのサブデータベースに同時に送信する必要があり、最後に結果が要約されます。
また、Java コードのような HashMap のデータ構造は、実際には一貫性のあるハッシュ アルゴリズムのテーブル分割戦略であり、キーをハッシュすることによって、データが配列に格納されるシリアル番号が決定されます。 HashMap で使用されるはモジュロではありません。シリアル番号を取得する代わりに、ビット単位の演算が使用されます。このメソッドは、HashMap の拡張が 2 の x 乗のサイズに基づいていることも決定します。この原理は、将来の機会。
上記は、HashMap でのデータ ハッシュの保存プロセスを簡略化したものです。もちろん、一部の詳細は省略しています。たとえば、HashMap の各ノードはリンクされたリストです (多すぎます)衝突が起こると赤黒の木になります)。このシナリオに適用すると、各シリアル番号をデータ テーブルとみなすことができます。
上記のルーティング アルゴリズムの利点は、ルーティング戦略がシンプルであり、リアルタイム計算のために追加のストレージ領域を追加する必要がないことですが、拡張したい場合には問題もあります。容量を増やすには、データベースのパーティション化など、移行のために履歴データを再ハッシュする必要があります。ライブラリがサブデータベースを追加する場合、すべてのデータをサブデータベースに再計算する必要があります。HashMap の拡張では、シーケンス番号を再計算するための再ハッシュも実行されます。配列内のキーの。データ量が多すぎると、この計算処理に時間がかかります。同時に、データ テーブルが少なすぎる場合、またはシャーディング用に選択されたフィールドの離散性が低い場合は、データ スキューが発生します。
この再ハッシュ プロセスを最適化するテーブル分割アルゴリズムもあります。これは一貫性のあるハッシュ リングです。このメソッドは、エンティティ ノード間の多くの仮想ノードを抽象化します。その後、一貫したハッシュ アルゴリズムを使用してこれらの仮想ノード上のデータをヒットし、各エンティティ ノードは実際には、エンティティ ノードの反時計回り方向で他のエンティティ ノードに隣接する仮想ノードのデータを担当します。この方法の利点は、容量を拡張してノードを追加する必要がある場合、追加されたノードはリング上の任意の場所に配置され、ノードの時計回り方向に隣接するノードのデータにのみ影響を与えることです。ノード内のデータは、この新しいノードにインストールするだけで移行する必要があるため、再ハッシュ プロセスが大幅に削減されます。同時に、仮想ノードの数が多いため、データをリング上でより均等に分散することもでき、物理ノードが適切な場所に配置されている限り、データのスキューの問題は最大限に解決できます。
たとえば、図は一貫性のあるハッシュ リングのハッシュ プロセスを示しています。リング全体には 0 から 2^32-1 までのノードがあり、実線はが本物のノードで、他はすべて仮想ノードです。Zhang San はハッシュによってリング上の仮想ノードに落ち、仮想ノードの位置から時計回りに実ノードを探します。最終的なデータは、実ノードなので、Crazy Donkey と Li Si ストアがノード 2 にあり、Wang Wu はノード 3 に、Zheng Liu はノード 4 にあります。
ノード 5 の容量を拡張した後、ノード 1 とノード 5 の間のデータをノード 5 に移行する必要があります。他のノードのデータは移行する必要はありません。かわった。ただし、図からわかるように、この 1 つのノードだけを追加すると、各ノードが担当するデータが不均等になる可能性が高くなります。たとえば、ノード 2 とノード 5 は他のノードよりもはるかに少ないデータを担当するため、データが均一な状態を維持できるように、容量を指数関数的に拡張することが最善です。
前述のように、トークン ID の数は多くなく、トークンに含まれるユーザー数は 10,000 ～ 100 万の範囲です。単純に整合性ハッシュを使用し、サブテーブル戦略としてトークン ID を使用すると、データ スキューが発生します。は深刻であり、将来の拡張時にデータ移行コストも高額になります。
ただし、一貫したハッシュ リングを使用すると、将来 2 の倍数で最適な拡張が可能になります。そうでない場合、一部のノードはより多くの仮想ノードを担当し、一部のノードはより少ない仮想ノードを担当することになります。 、結果としてデータは不均等になります。ただし、データベースの同僚と通信する場合、1 つのデータベース内のデータ テーブルの数が多すぎないように注意してください。そうしないと、データベースに大きな負荷がかかります。コンシステント ハッシュ リング方式では、容量が 2 ～ 3 倍に拡張される可能性があり、 1 に達するまでのサブテーブルの数。非常に高い値。
上記の問題を踏まえ、トークン ID をサブテーブルとして使用することを決定する前提で、動的拡張をサポートし、データ スキューの問題を解決する方法に焦点を当てる必要があります 。
水位閾値と容量拡張の監視
現在、水位のしきい値は依然として手動設定に依存しています。どのくらいの大きさに設定すべきかは非常に感情的です。設定できるのは 1 つだけで、アラーム後に適切に調整できます。しかし、実際には、システムはインターフェイスの読み取りおよび書き込みパフォーマンスの変動を自動的に監視することができ、ほとんどの式が高いレベルに達しても、インターフェイスの読み取りおよび書き込みパフォーマンスは大きく変化しないことがわかります。自動的にしきい値を増やしてスマートなしきい値を形成します。
インターフェイスの読み取りおよび書き込みパフォーマンスが大幅に変化し、ほとんどのテーブルがしきい値に達していることが判明した場合、容量拡張を検討する必要があることを示すアラームが発行されます。
問題を解決する特効薬はありません。手元にある技術的手段とツールを使用して、それらを組み合わせ、適応させて問題を解決する必要があります。ビジネスやシナリオには、良い悪いはなく、向いているか向いていないだけです。
以上が知識の拡張: データの偏りを解決するための自己均衡テーブル分割方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
