データトラフィックが非常に大きい場合には、単一のデータベースでは、単一のライブラリが充填されたがあるかもしれないときに、データベースにもより頻繁に読み書きもサポートすることはできません、単一のライブラリのボトルネックioのタッチされている、あなたはサブライブラリーを考慮する必要があります。
ここで最適化する方法を、ライブラリを分割する方法について話をします：
最初のみデータベースAでは、以降のデータベースBを添加
データテーブルは、タイムスタンプフィールドとタイムスタンプフィールド、およびデータのクエリ条件がある場合は、私たちは年という名前db_2019により、データベースに、例えば、作成されたデータの時間範囲に基づいて、サブライブラリーは、2020年には新しいライブラリdb_2020を生成することができますので、ビジネスの終わりに読み取りおよび書き込みデータは、タイムスタンプ条件取得年、年に応じて動作し、適切なデータベースを選択したとき。
しかし、この方法の上に異なるデータベースの負荷にリードが均一でない、この特定のビジネスシナリオにのみ適しており、このようにして、古いデータはほとんど読まれないことがあり、新しいデータがより頻繁に読み込まれます。だから、それをスライスする任意のより良い方法があるでしょうか？答えはイエスです。ほぼすべてのテーブルは、キーが数値型である場合、キーは、方法は、キー100のようなデータベースの数を法として、データベースは数2で断片化することができる、キー・フィールドを持つことになり、その後、100％2 0を得、これは、0のデータベースインデックスに格納する必要があります。キーが文字列である場合、デジタルモジュロの方法によって、対応するデータベース、デジタルCRC32（値）によって算出することができます。
コース内の場合は、データベースではありません十分には、我々はどのように行う、再膨張する必要がありますか？
停止は、新しいデータ移行ロジックスライスに合わせて、ライン上の新しいサービス・ロジックからスライスを取ります。問題はありません、いくつかの時間のためのビジネスをシャットダウンすることができた場合、これは安全な方法です。事業は、ダウンタイム、またはのみ行うにはどのようにデータベースの短時間の停止に許され、その後、拡張、またはどのようにスムーズにそれのビジネスに影響を与えることなく、データベースの移行を行うために余裕がない場合は？
次の手順によって行うことができます
オプション1：
- データ移行の必要性、二重書き（元のデータベースを書き込み、データベースを移動する）：変更されたデータベース・ロジックを書きます
- 移行スクリプトを書く：ターゲット・データベースに元のデータベースからデータを移動します
- データベースのデータを元のデータベースかどうかをチェックし、目標と一致している（移行の瞬間に発生した可能性がある元のデータベースのデータを削除し、ターゲット・データベースがまだ書かれている）、削除、不要なデータ・ターゲット・データベース。
- 変更データベースの断片化ロジックは、書き込みロジックが除去ビス
- 各データベースの冗長データを削除
データベースのダブルポイントより良いライブラリ拡張プログラムの場合
オプション2：
- 元のデータベースとデータベース設計のデュアルマスター同期への移行
- データベースの断片化を修正するためのロジック
- 各データベースの冗長データを削除
読者がより直感的な理解を得ることができるように、チャートの背中を見つけるためにいくつかの時間を追加します。
いくつかの質問があります。
一つの問題：プログラムは、成功、書き込みに失敗したことを書くために二重の時間を作る場合、どのように対処しますか？
第二の問題：サブライブラリー、クエリデータをページングする方法？
その後、私は記事のより大きな長さを記述しますがどのようにクロスデータベースページングクエリデータを分析します。