背景
少し前のポイントテーブル上の2件の記事を送りました。
タイトルから見ることができ、我々は唯一のサブテーブルだった;または起因するビジネスの発展に、今のように、サブライブラリーを行っている、今では、私の心をまだリカバリディスクもはっきりと覚えて、まだ比較的スムーズに表示されます。
次のように全体のサブライブラリーのサブテーブルのプロセスについて、最初の口コミをもとであります：
全体のプロセスは、企業の発展方向の大半に沿って、またよく理解されています。
まれに事業を開始していない、これは、その後のピットを減らしますが、サブライブラリーサブテーブルに設計されるが、一部の企業は、ビジネス指向し始めています。
単一のテーブルへのビジネスがサポートすることはできませんまでは、それが自然にもサブライブラリーポイントテーブルの事を考えてみます。
だから、Benpianは、前述した内容の要約を繰り返すことになります。
ポイントテーブル
どのような状況下での適切なポイントテーブルが最初に説明しますか？
データの量を2％以上に向上させながら、データの量、特定のテーブルには、何百万、あるいは数十億に達したとき、私の経験によります。
もちろん、これらの数字は、最も重要なことは書いて、このテーブルを照会することで、クエリ率は、大幅に減少したデータベースや他の高全体のIOなど、通常の業務執行に影響を与えてきた、絶対的ではありません。
そして、それはサブテーブルのレベルになるか、我々はポイントテーブルに焦点を当てたときに、
すなわち、として均等N張テーブルに配布データのいくつかのルーティングアルゴリズムによるデータの大規模なテーブルです。
範囲
サブテーブルの戦略は、異なるシナリオについて、それぞれ、いくつかあります。
まず、第1の範囲の分割に応じて、例えば、我々は、日付によって月面の分割として保存された特定のテーブルの時間を作成することができるである。また、分割の範囲に応じて、特定のテーブルの主キーである、例えば、[1]〜10000として表に、表中の[20000から10001]など。
このようなシステムのデフォルトとしてファイリング処理を行うために必要なデータ、履歴データのクエリ機能の唯一の最後の3ヶ月なので、操作することも容易なため、サブテーブル;データは3月だけで削除する必要が直前にバックアップを保存することができます）。
欠点がある。このプログラムは良いです。
- メリットはあまり介入なしに、水平に自分延長されています。
- 欠点は、データが均一ではないかもしれないということである（月が要求をジャンプなど）が起こります。
ハッシュ
そのような日付ポイントテーブルの範囲によると、確かに簡単ですが、範囲は非常に狭いです。結局、私たちのほとんどは、時間データのクエリを取る必要はありません。
例えば、ユーザは、それは非常に一般的な要件である、彼は生成された注文のすべての情報を照会したいと考えています。
だから我々は、変更する部品表の大きさを変更する必要があり、メインアルゴリズム部品表を使用することができるhash+mod組み合わせで。
これは、古典的なアルゴリズムで、有名であるHashMapデータを格納するのと同じ方法。
ここでは、大規模なテーブル情報の元の順序が64のサブテーブルに分割されると仮定する。
ここではhash、我々は均一のデータをハッシュを通じてのような、ハッシュサブテーブルの操作を行うために必要と繰り返さないフィールドです。
このフィールドは、プラスチック自体であり、このステップでは繰り返さないことにする場合はもちろん、直接、省略することができるModサブテーブル添字ができる与えます。
サブテーブルの数を選択します
ポイントテーブル番号（64）豪華である場合については、これはない特定の数は、ビジネスニーズ、推定されたデータの増分に応じて、標準値に設定されています。
私の個人的な経験に基づいて、良い点の少なくとも小さなリストを確保する必要性は、単一のテーブルの後のデータは、事業開発の数年以内に（例えば千万に達すると）過大表示されません。
その後の小さなテーブルがボトルネックに達した場合、私はそれが非常に苦痛で、サブテーブルの拡張を行うために必要な、すべての後、可能な限りのポイントテーブルの数を、データベース内の許容範囲を拡大する傾向です。
今、私はここまで経験していないので、これは、関連のプレゼンテーションではありません。
しかし、選挙の数は盲目ではない、とHashMapとしてもお勧めお奨めのこと2^nなので、拡張が簡単に可能な限り少しのデータを移行することができるとき。
レンジ+ハッシュ
もちろん、そこにアイデアがある、RangeとHashあなたは混在させることができます。
例えば、我々は、ハッシュポイントテーブルを使用し始めたが、あなたは、このような64 256テーブルからの拡張として、拡張を行う必要がありますので、各サブテーブルのデータが得られ、巨大なデータの増加は、すぐに、ボトルネックに達しました。
あなたはデータのノンストップの移行は拡大が、でも停止したときに行うことは非常に困難であるかどうしかし、どのくらいの時間が停止していますか？言ってはいけません。
我々は可能なのであればMod、テーブル上の月面ベーシスポイントに細分化、によってRangeそのスケーラビリティ、物事は、後続のデータ移行と考えていないだろう。
誰もがそれのアイデアへの参照であるためには理論的に可能このように、私は実際には、使用していません。
迷惑なデータ移行
あなたはポイントテーブルの最初のステップを完了する準備ができているときのサブテーブルのルールがあるだけで、実際のトラブルは、データの移行、あるいはむしろ、どのようなビジネスへの影響を最小限に抑えながらデータ移行を行うことです。
ポイントテーブルを行うために始めているので、このステップでは、確かに、データ移行捕虜でない限り。
現在、ご参考のために私たちの練習を終え、次の下で：
- 表ラインデータ上の全ての点が書かれたクエリがポイントテーブルに向けられていると、元の大きなテーブル内のデータは、ポイントテーブルに移行するビジネス上のそれ以外の場合は大きな影響を与えました。
- 私たちは、それが移行を完了するのに約4〜5日かかる、およそ2億移行テーブルの推定値、自らの移行プログラムを書きます。
- それは、この時間は、以前のデータは、ユーザーには見えないので、ビジネスは明確に受け入れられないことを意味しています。
- このステップを、行の変換にサブテーブル新しく作成されたサブテーブルに書き込まれたすべてのデータが、過去のデータの操作もいとこに行くので、少ないデータ移行：だから我々は、互換性のある治療をしました。
- ただ、データ移行が完了した後に一度新しいデータが十分に長い時間（私たちは2ヶ月ですが）生成された決定を、ルーティングの操作データ、ほぼすべての操作は、ポイントテーブルに向け、次に起動し、データベースからデータを移行される前に行われる必要があります元ルーティングの決定を削除します。
- 最後に、すべてのデータポイントは、ライティングテーブルから生成されました。
この時点で全体のサブテーブルの動作が完了する。
互換性のあるビジネス
ポイントテーブルの後、他のビジネスニーズにも対応しながら、今、このようなオリジナルのレポートサービスとして、ページングクエリし、我々はそれに対処する方法を見て。
レポートの形式
まず報告は、取得するにはノーポイントテーブル間の前にテーブルを照会、今表と異なるのは、Nテーブルとなります。
だから、元のクエリは、パフォーマンスがマルチスレッドのクエリテーブルのデータポイントを利用して、集約することができます考慮して、すべてのポイントのテーブルを介して変更する必要があります。
しかし、唯一の頼りにJavaデータまたはその非現実的な大量の統計分析を行うために、初めは過去にも対応することができ、フォローアップは、に対処するためのビッグデータプラットフォームを費やす必要がありました。
お問い合わせ
さらに別のクエリ、確かに元のクエリページングは結局、データ・ページの数百万は本当に重要ではありません、使用することはできません。
唯一のポイントテーブルのフィールドを照会することによって提供することができ、注文IDのサブテーブルに従っているような、そのクエリは、それ以外の場合は、すべてのテーブルをトラバース伴うだろう、このフィールドを持参する必要があります。
これはなしていない限り、すべてのサブテーブルの出会いの後にも問題があるMySQLようにリレーショナルデータベース。
サブライブラリー
サブフォームの後に単一テーブル圧力を解決することができるが、圧力は、データベース自体を削除しませんでした。
私たちは、パーティションテーブルの後と増加した書き込みで、データベース全体IO、とされていないもの「他の形式」と、ビジネス関係の結果のデータベース「他のテーブル」ので、一ヶ月以内に完了しました。
それは、これは非常に価値のあるものである、ビジネス全体に影響を与えた非必須データの数につながりました。
だから我々は、新しいデータベースに一人でそれをいくつかのテーブルを入れて、完全に既存事業から分離されました。
これにはいくつかの改修を伴うだろう。
- アプリケーション自体ではなく、これらのデータの独立した調査を呼び出す記述しなければならない
Dubboサービスを、移行サービスによって、テーブルの上に動作します。 - データ移行を行う延期ので、彼らは、クエリは、現在のライブラリ内の古いデータを照会する場合は互換性は、新しいデータが呼び出す必要があるときにサブテーブルのクエリに基づいて、そうする必要が
Dubbo検索するためのインターフェイスを。 - これらのテーブルは、クエリ変換する必要がクエリに関連したいくつかの
Dubboインターフェイスは、メモリ内にスプライシングすることができます。 - データの量は確かに非常に大きい場合、同期することができる
Dubboメッセージキューへのインタフェースのスループットを向上させるために書込み変換器です。
巨大な今、我々はビジネスのこの種のデータの量には影響を与えません見てますが、別のデータベースに移動した後、データベース全体がIO大幅に減少し、ビジネスは正常に戻っています。
概要
最後に、我々は定期的に移行するNヶ月前に、過去のデータのアーカイブ操作、データによるステップを実行する必要がありますHBASEことを保証するために、このような記憶MySQLデータが許容範囲内に維持されます。
彼らはビッグデータに依存しているクエリアーカイブされたデータは、サービスを提供します。
サブライブラリーのサブテーブルは、オンライン情報のほとんどが良いタイヤ工場の前に車の中で、非常にまれな練習操作です。
そして、私たちのシーンのほとんどが高速道路上で発生した「自動車事故」それを信じて、タイヤを変更するには車に走りました！
メッセージを議論する我々はコメント欄を歓迎するより良い方法があります。
親指を共有し、私にとって最大のサポートです