MyBatis が Mysql データベースサブデータベースとテーブルサブデータベースを実装する方法の詳細な例の説明-mysql チュートリアル-php.cn

この記事では主にMyBatisのMysqlデータベースサブデータベースとテーブルサブテーブルの実装の動作と概要を紹介しますので、必要な方は参考にしてください

前書き

データベースとして、テーブルとして。ユーザーとしてのデータベース時間が経つにつれて、データの量はいつか管理できなくなります。このとき、1 つのテーブルのデータが数千万を超える場合、その操作には非常に時間がかかります。

MyBatis にサブテーブルを実装するための最も簡単な手順

記事のタイトルがこのように書かれているので、実際の情報に直接進む方がより実践的です。まず、その方法を見てみましょう。最も単純なサブテーブルを実装します。

1. シミュレートされたユーザーテーブルのデータ量は数千万を超えます (実際にはその可能性は低いですが)

2. ユーザーテーブルの元の名前は user_tab であり、それを user_tab_0 と user_tab_1 (実際にはそのようなランダムな名前ではない可能性があります)。これにより、元の数千万のデータを 2 つのデータ量で 2 つのテーブルに分離できます。百万。 user_tab，我们切分为user_tab_0和user_tab_1（实际也可能不是这么随意的名字），这样就能把原来千万的数据分离成两个百万的数据量的两张表了。

3、如何操作这两张表呢？我们利用userId也就是用户的唯一标识进行区分。

4、userId%2 == 0的用户操作表user_tab_0，同理userId%2 == 1的用户操作表user_tab_1

3. これら 2 つのテーブルを操作するには?ユーザーの一意の識別子である userId を使用して区別します。

4. userId%2 == 0 のユーザー操作テーブル user_tab_0 は、ユーザー操作テーブル userId%2 == 1 と同じです。 >. code>user_tab_1

5. では、MyBatis で SQL ステートメントを実装するにはどうすればよいでしょうか?以下は user

<select id="getUser" parameterType="java.util.Map" resultType="UserDO"> 
    SELECT userId, name 
    FROM user_tab_#{tabIndex} 
    WHERE userId = #{userId} 
</select>

ログイン後にコピー

をクエリするための SQL ステートメントの例です。この中で、2 つのパラメーター tabIndex と userId を渡します。tabIndex は操作テーブルのインジケーター値 (0 または 1) です。 userId が 5 であるユーザーをクエリすると、最終的な SQL ステートメントは次のようになります:

SELECT userId, name 
FROM user_tab_1 
WHERE userId = 5

ログイン後にコピー

ここでは、その他の冗長な DAO サービスと実装については説明しませんが、賢明な方ならご存知だと思います。

上記は最も単純な実装であり、サブテーブルの要件を満たすために追加のフレームワークやプラグインは必要ありません。

以上が基本的にすべての実装内容です。ここからは分離の詳細について説明していきます。興奮を見ている人は基本的に退出してください。

以下の角度からお話します。できるだけ簡単な言葉で表現しました。

分割方法

分割には主に水平分割と垂直分割の 2 つの方法があります。

1. 水平分割

簡単に言うと、テーブルを複数の同一のテーブルに分割し、テーブル名が異なります。上記の最も単純な例と同じです。

この種のセグメント化は、一部の保存されたレコードテーブルなど、テーブル内のデータ量が多すぎて操作時間が遅くなる状況に適しています。

2. 垂直セグメンテーション

異なるビジネスモジュールを異なるデータベースに分割します。これらのビジネスモジュールは、直接 0 結合されることが望ましい (簡単に言うと、関係がありません)。

これは、一般にデータ量が多く、ビジネスシナリオが分散しており、それらの間に論理的な関係がない状況に主に適しています。

分離の戦略

具体的な戦略はたくさんありますが、独自の戦略を設計することもできます。一般的な戦略は次のとおりです。これらは列挙するだけであり、詳細は説明しません。

1. "%" モジュロは、上記の例で実装されているものであり、最も単純なものでもあります。

2. MD5 ハッシュ

3. シフト

4. 日付と時刻 (月ごとに 1 つのテーブル、今月はこのテーブルを操作するなど)

5. 列挙範囲 (ユーザー 1 ～ 10000 が最初のテーブルを操作し、ユーザー 10001 ～ 20000 が 2 番目のテーブルを操作します)

分離の問題

最後のポイントと引き起こされる問題について話しましょう。

データベースは決して一人で分割できるものではありません。 (人々はもっと感情的です。どうして簡単に別れることができますか?)

真面目な話、私は別居によってのみ引き起こされる以下の問題をリストしました。

1. 追加時の主キーの一意性の問題。複数のテーブルを分離した後、元の自己増加する主キーは一意ではなくなるため、自己増加する方法がなく、問題が発生します。解決策はあります。主キーテーブルは、現在の主キーを保存するために特別に使用されるか、他のミドルウェアが使用されます。

2. 新しいデータを追加する際の効率の問題は大きな問題ではありませんが、新しいデータを追加すると計算量が確実に増加します。この問題は無視できます。

3. クエリによって引き起こされるページングの問題。つまり、複数のテーブルに分割された場合、ページングクエリは非常に困難になります。つまり、異なる解決策が必要になることも考慮されます。

4. 関連クエリも同様に、元々はあるテーブルを別のテーブルに関連付けたり、別のテーブルをあるテーブルに関連付けたりするのは非常に簡単でしたが、今では分離後は難しくなります。

5. トランザクションの問題。トランザクションによる元の操作を完了するには、複数のテーブルで分散トランザクションを使用する必要があります。元のトランザクションは 1 つのテーブルのみをロックしていたため、今後は複数のテーブルをロックする必要がある可能性があります。 🎜🎜6. スケーラビリティの問題。実際には、データのスケーラビリティが優れていないものもあります。それは、新しいテーブルを作成して拡張できることを意味しますか? 🎜

分離の原則

以下は、実際の根拠はなく、主にインターネット上の参考文献に基づいて、いくつかの分離の原則を要約したものです (私は年収 100 万ドルの DBA ではありませんし、一度も遭遇したことはありません)大量のデータです）実際に検査に行ってください）ので、ご不明な点がございましたら、ご指摘ください。

1. 分割できない場合は分割しないでください

2. できるだけ分割できる場合は、できるだけ分割しないでください

3. 冗長すぎて意味がありません

4. 分散トランザクションの使用は避けてください。主な理由は、それが難しすぎて、その方法がわからないためです。

5. 単一のテーブル内の数千万のレコードを分割しないでください

6. 、後で分離する時間があります

7. 拡張し、結合し、分離を達成する方法を慎重に検討します

最後に、分離について話しましょう最も人気のある DAO フレームワークは MyBatis で、他にも多くのフレームワークがあります。分離は主に以下の方法で実現されます。 1. ネイティブ実装では、上記の例と同様に、ネイティブフレームワークを使用して実装を制御する必要はありません。

利点は、コントロールしやすく、主導権を握るのが簡単です。

欠点は、コードが多い、明確に理解しておく必要がある、変更するのが不便である、複雑なセグメンテーションをサポートしていない、たとえば、セグメンテーション後にいくつかのページングクエリを実行する必要があることです。前述の主な問題。

2. プラグインの実装。フレームワーク自体によって開発されたいくつかのプラグインを使用してこれらのプラグインを実装し、そのプラグインを使用してデータベースにアクセスし、直接分離を実現します。

利点は、コードが少なく、実装が簡単で、スケーラビリティが優れていることです。

欠点は、制御が難しく、分離方法が限られ、問題の解決が難しいことです。特に成熟したプラグインは見つかりませんでした。

3. ミドルウェアの実装。データベースにアクセスする前に、データベースアクセスミドルウェアを使用していくつかの操作を実行し、SQL で対応する変更を加えて分離を実現します。

利点は、結合が小さく、拡張性が高く、分散トランザクションの問題を解決できることです。

それは間違いなく、実装はより複雑で、ミドルウェアの学習が必要で、コストも高額です。故障した場合のメンテナンスも大きな問題です。。

要するに、それぞれの方法にはそれぞれメリットがありますが、コストを考慮すると、最初の方法は、上記の例のように、コストがほぼ0で、すぐに始めることができ、制御が容易です。処理はまだそのレベルに達していません。どこにでも分離点があるため、最初のオプションを選択します。こちらもおすすめです。より使いやすいプラグインやミドルウェアを見つけた場合は、コメントでお勧めできます。

まとめ

実際のプロジェクトでは、ユーザーアカウントレコードが多すぎて、さらにアカウントレコードが変更や削除なしで追加されるだけで、クエリも数件しかなかったため、ユーザーアカウントレコードを分離する必要がありました。私は、「彼らは最も単純な分離方法を選択しました」を使用し、最も単純な戦略を選択しました。上記の原則、戦略、手法、問題点の概要が皆様のお役に立ち、参考になれば幸いです。ご質問がございましたら、メッセージを残してください。すぐに返信させていただきます。スクリプトハウス Web サイトをサポートしてくださった皆様にも感謝いたします。

以上がMyBatis が Mysql データベースサブデータベースとテーブルサブデータベースを実装する方法の詳細な例の説明の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。