データベースのシャーディングとテーブルのシャーディング後に設計される最初の問題は、ルーティング キーの選択方法とキーのルーティング方法です。ルーティング キーは存在し、各テーブル内で一意である必要があります。ルーティング戦略では、データが均等に分散されるようにする必要があります。
大量のデータをアーカイブする場合は、ルーティング キーとして時間を選択できます。たとえば、データの作成時刻をルーティング キーとして使用して、月ごとまたは四半期ごとにテーブルを作成します。データベースとテーブルをシャーディングした後、時間をルーティング戦略として使用すると、データのアーカイブが実現できます。履歴データのアクセス トラフィックは少なく、トラフィックは最新のデータベース テーブルに送信されます。
ビジネス関連のルーティング キーを設計することもできます。これにより、各データベースのリソースがトラフィックに十分耐えられることが保証されます。
ユーザーの観点から見ると、テイクアウト注文プラットフォームはデータベースとテーブルに分割された後、注文されたテイクアウト注文のステータスのリアルタイム表示と追跡をサポートする必要があります。注文情報。販売者は注文情報を照会し、注文を通じて料理の品質を分析し、ビジネス上の意思決定を行う必要があります。
ユーザー消費者 = C 側販売業者 = B 側
ユーザーが注文した後、注文が失敗する可能性があります異なるテーブルに分割する場合、クエリ時に複数のテーブルをクエリする必要がある場合があります。
注文の作成時に注文がテーブルにランダムに挿入される場合、または注文がどのテーブルに挿入されるかわからない場合は、クエリを実行するときにすべての注文をクエリする必要があるテーブルはクエリの正確さを保証できます。
注文を挿入するときに特定のルールがある場合、注文はこのルールに従ってデータベースに挿入され、クエリの際には、対応するルールも実行されて対応するテーブルがクエリされます。これにより、データ操作の複雑さが軽減されます。ユーザーと販売者の両方は、データをクエリするときに同じルーティング戦略に従うことができます。これは、ルーティング戦略を設計することで実現できます。
前のセクションのルーティング戦略分析に従って、ここで、顧客ルーティング キーを選択する必要があります。ルーティングキー 。クライアントでは、同じ ユーザー ID のデータを固定テーブルに保存できるため、ユーザー ID をルーティング キーとして選択できます。
単一データベースの場合、ユーザーは注文を出し、注文を生成し、ユーザー ID をルーティング キーとして使用し、user_id のハッシュ値を取得し、テーブル数の剰余を取得します。ルーティングが必要な対応するテーブルを取得し、データを入力します。
#複数のデータベースと複数のテーブルの場合は、まず対応するデータベースを見つけてから、対応するテーブルを見つける必要があります。複数のデータベースと複数のテーブルのルーティング戦略: ユーザーが注文する -> 注文を生成する - > ルーティング戦略: ユーザー ID のハッシュ値に基づいてデータベースの数をモジュロして、対応するデータベースを見つける -> ユーザーのハッシュ値を割るテーブルの数のペアによる ID、および対応するテーブルを見つけるためのテーブルの数のモジュロ。
ルーティング戦略設計の重要なポイントは、特定のビジネス シナリオに従って設計し、ユーザーとより密接に関係するルーティング キーとしてハッシュ値モジュロを使用することです。 information
別個のテーブル セットがマーチャント B 側用に設計されています (C 側と B 側は独立しています)。
ユーザーの観点では user_id をルーティング キーとして使用し、販売者の観点では販売者の ID をルーティング キーとして使用します。販売者はルーティング キーを介してデータをどのようにルーティングしますか。注文を行うと、Youhu はチームメイトの注文番号を MQ に送信します。販売者はこの MQ を使用し、注文番号に基づいて注文情報を取得し、その注文情報を販売者のデータベース テーブルに挿入できます。販売者の ルーティング ポリシー とユーザーの ルーティング ポリシー は同じです。
クライアントとマーチャントの完全なデータ フロー図:
以上がMySQL データベースとテーブルのパーティショニング後のルーティング戦略設計の分析例の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。