すべての優秀なプログラマーやアーキテクトは、以下のようなサブライブラリーのサブテーブル、モバイルインターネットの時代、ユーザーが生成した質量日々の膨大な量を、習得する必要があります。
ユーザーテーブル
Ordersテーブル
トランザクションフローテーブル
私たちは、アリペイAlipayのユーザー8億例を持って、マイクロチャネルのユーザー10億れます。注文フォームは、数千のオーダーの何百万人もの毎日、このような米国のグループのお持ち帰りなど、より誇張されています。淘宝網の総履歴受注がはるかに大規模なデータテーブルからは10億さえ千億レベルは、ライブホールドすることができなければなりません。
実際には、MySQLの単一のテーブルには10億件のデータを格納しますが、今回は比較的貧弱なパフォーマンスすることができます。MySQLの業界は、千万単一のテーブル以下最適状態の容量を認識し、それがBTREEインデックスツリーの高さは3〜5ため。
それは、テーブルを取得することはできませんので、その後、複数の場所にデータをアプローチしたかった、現在はより一般的なシナリオ3があります。
パーティション;
サブテーブルサブライブラリー;
NoSQL / NewSQL。
説明：唯一のサブライブラリー、または唯一のサブテーブル、またはサブライブラリーのサブテーブル統合プログラムは、サブライブラリーサブテーブルのプログラムを統一していると考えられます。サブライブラリー、またはサブテーブルはばかり特殊なサブライブラリーのサブテーブルであるため。NoSQLのは、ES、MongoDBのより代表的なものです。NewSQLより代表はTiDBです。
なぜのNoSQL / NewSQL？
まず第一に、なぜ私は主にRDBMSは、次のような利点を持っていると思う、第三の選択肢のNoSQL / NewSQLを選択していません。
RDBMS生態改善。
RDBMS絶対安定。
トランザクションのRDBMS特性;
私たちが主なターゲットとしての信頼性を検討する際のNoSQL / NewSQL新生児として、それはRDBMSと比較することはできません。RDBMSの数十年の開発、限りそれは選択肢のコアに格納されているソフトウェア。
現時点では、同社のコアデータのほとんどは、次のとおりにRDBMSのストレージベースの、NoSQLの/ NewSQLのストレージ・サプリメント！
MySQLのベースのインターネット企業、再び、国有企業＆銀行やその他のお金は、Oracle / DB2ベースに悪い会社ではありません！NoSQL / NewSQL宣伝どんなに高速なハードウェア、現在、大手企業は補完的なRDBMSのではなく、交換され位置決めされていません！
なぜ分割しませんか？
私たちは、パーティションテーブルスキームを見てください。このプログラムの前に、まずそれがどのように動作するかを理解します：
パーティションテーブルは、実装の基礎となる複数の関連テーブルで構成され、基礎となるテーブルは、オブジェクトへのハンドルで表されるので、我々はまた、直接各パーティションにアクセスすることができます。
各テーブルにのみパーティションテーブルインデックスに、（すべての基礎となるテーブルは、同一のストレージエンジンを使用しなければならない）、共通としてストレージエンジン管理テーブルと下部テーブルに分配各々は、それぞれ同じ基礎インデックスに結合されます。
ビューのストレージエンジンポイント、基本となるテーブルと通常のテーブルの観点から全く異なるストレージエンジンにも、これは通常のテーブルの一部またはパーティション表で知っておく必要がありません。
実際には、このプログラムは、クエリが列をシャーディングされていない場合でも、それが動作することができ、シャーディングの詳細からユーザーを保護し、悪いことではありません（ただし、この時間、一般的にパフォーマンス）。
しかし、その欠点は明白です：多くのリソースは、スタンドアロン限定されている、例えば、その上の接続数、ネットワークスループットと！
各パーティションは、独立して格納されてもよいが、総パーティションテーブルエントリは、MySQLの例であるが。その同時実行結果として非常に一般的な、インターネットの高並行性の要件のはるかに短いです！
例えばインターネットを言及した他のいくつかの欠点については：あなたは、外部キーを使用することはできません、フルテキストインデックスをサポートしていません。私は、プロジェクトやフルテキストインデックスとデータベースの外部キーの使用は、私はTucaoするのが面倒だ場合、それは欠点21世紀のではないでしょうと思います！
あなたはパーティションテーブルを使用しているのであれば、あなたのビジネスは、以下の2つの特性があります。
質量データは、（パーティションの数が限られ、記憶容量が限られている）ではありません。
並行処理負担がより少ないです。
なぜサブライブラリーサブテーブル？
一般的な方法のインターネット業界は現在、最後に導入される大量のデータを処理している：サブライブラリーサブテーブルを。
我々は大規模なコアデータに対処するためのサブライブラリーのサブテーブルのプログラムを使用しているが、独占ミドルウェアはありませんが、ここで著者は、いくつかの特定のよく知られたサブライブラリーのサブテーブルのミドルウェアです。
アリTDDL、DRDSとコバー
オープンソースコミュニティのシャーディング-JDBC（3.xのはシャーディング球として名前が変更されました）
MyCAT市民社会組織
360のアトラス。
シマウマの米国のグループ
リマーク：今Jingdongはファイナンスにおける详细でシャーディング-JDBC原作者張梁すばらしい神、。しかし、シャーディング-JDBCの著作権は、オープンソースコミュニティではなく、会社に属し、また張梁は個人的です！
他のそのような網易、58として、Jingdongは他の企業は、自社開発したミドルウェアを持っています。互いに短い戦闘では、それが繁栄すると言うことができます。
しかし、これほど多くのサブライブラリーのサブテーブルのミドルウェアは、全ての2種類に分類することができます。
CLIENTモード
プロキシモード
CLIENTモードの代表アリTDDL、オープンソースコミュニティのシャーディング-JDBC（球をシャーディングされたシャーディング-JDBC 3.xバージョンは、プロキシモードをサポートしています）
アーキテクチャ次のように：
プロキシモードの代表MyCATアリコバー、市民社会団体、アーキテクチャは次のとおりです。
しかし、クライアントモード、またはプロキシモードの両方。いくつかの重要な手順は同じです：SQLの構文解析、書き換え、ルーティング、実行、結果がマージ。
私は、クライアントモード、シンプルな構造、小さなパフォーマンスの低下、低運用・保守コストを傾向があります。
次に、一例として、いくつかの大規模な共通テーブル、どのサブライブラリーサブテーブルの床を説明します！
実際のケース
シャーディングの選択した列は、シャーディング列選択が直接全体のサブライブラリーのサブテーブルが最終的に成功したかどうかを判断しますサブライブラリーサブテーブル最初の、そして最も重要なステップ。
我々は、高トラフィックのAPIを優先して、あなたのトラフィックを分析シャーディング列のAPIを選択するための最も重要な方法は、SQL APIに対応する比較的大きな流れが抽出されていることを信じて、強くビジネスに関連したシャーディング列選択、これらのSQLの一般的な状態シャーディング列として。
OLTPシステムは、一般的なユーザーが提供していますされているような、これらの条件は、ユーザIDに対応するSQLのAPIを持って、その後、ユーザーIDは非常に良いシャーディング列です。
ここではいくつかのアイデアをメイン処理サブライブラリサブテーブルです。
シャーディングの欄には、サブライブラリーのための唯一のサブテーブルを選択します。
データベースシャーディング列サブサブテーブルの複数の複数。
サブサブテーブルデータベースシャーディングカラム+ ES。
そして、どのようにサブライブラリーサブテーブルのいくつかの実用的な例を見て。
Ordersテーブル
一般Ordersテーブルいくつかのコアフィールドを次のように
一例として、システムへアリ順序は（「企業のITアーキテクチャの道路の変換：戦略的思考のための台湾のアリババとアーキテクチャ」を参照）、それは3つの別々のシャーディング列として3つのカラムを選択しました。
即：ORDER_ID、USER_ID、merchant_code
これは、その買い手と売り手ID USER_IDとmerchant_code ID、アリの注文システムの買い手と売り手クエリトラフィックが比較的大きいため、およびクエリが高いリアルタイム要件です。サブライブラリーのサブテーブルでORDER_IDよれば、よりになりますORDER_IDクエリに基づくべきです。
それでも、それは言及されるべきで、より多くのシャーディング列のサブライブラリーのサブテーブルが冗長関係または単にインデックステーブルの冗長全額である、我々は自分自身を比較検討する必要があります。
冗長の総量より多くの記憶スペースが浪費される以下の場合、全ての合計量、2番目のクエリを必要としないという利点に対応する各列のデータテーブルをシャーディング、より良好な性能は、不利である（薄緑色フィールドがsharding-あります列）：
冗長関係インデックステーブル下記条件、データシャーディングサブライブラリサブテーブルの1つの列のみしかテーブルのシャーディング列と他のサブライブラリサブテーブルの全量です。
この利点は欠点が最初のクエリに加えて、シャーディング列、クエリの他のシャーディング列が二次のクエリを必要としている、スペースを節約することです。
（淡緑色フィールドが列をシャーディングされる）を以下に示すように、これら3つのテーブル間の関係：
フルスケールの冗長 PKの冗長テーブル
速度比較：でも、キャッシュの導入、または1つの以上のネットワークオーバーヘッドで本格的な冗長性をより速く、二次冗長クエリリレーショナルテーブルの必要性;
ストレージコストは：本格的な冗長性は、ストレージの冗長リレーショナルテーブルのコストを数回必要です。
メンテナンスコスト：フルスケールの冗長メンテナンスより高価な、それはデータの変更を必要とする、いくつかのテーブルを変更する必要があります。
概要 ：フルスケールまたは冗長インデックステーブルを選択し、これは建築の利点と両方見かけ、アリのOrdersテーブルの欠点のトレードオフである本格的な冗長性です。
ユーザーテーブル
次のようにいくつかのユーザ・テーブル・フィールドコアは、一般に：
平均的なユーザー・サインオンのシナリオのいずれかmobile_noを通じて、だけでなく、電子メールで、あなたはまた、ユーザ名経由でログインすることができます。
しかし、いくつかのAPIを関連するユーザー、およびUSER_IDが含まれているが、あなたはすべての4つのサブライブラリーのサブ列のテーブルを実行する必要があり、それは4つの列が列をシャーディングされている、です。
アカウントテーブル
一般会計のテーブルいくつかのコアフィールドを次のように
シャーディング列をすることができますACCOUNT_NOするようにAPIは、一般的な条件はACCOUNT_NOテーブルを持っているアカウントに関連付けられています。
複雑なクエリ
上記のすべての条件がSQLの実行のシャーディング列を持っています。しかし、シャーディングの列が含まれていない、そして同時に、私たちはこれらのクエリは、大量のリクエスト、無制限の冗長サブライブラリーのサブテーブルではありません注文することはできませんいくつかのクエリがあります。
そして、これらの条件SQLの無いシャーディングの欄には、どのように対処するには？
シャーディング-JDBCで、例えば、サブライブラリーサブテーブルの数は、それが実行されるサブライブラリーサブテーブルの数に必要同時ルーティングされ、その後、結果を組み合わせます。具体的にマージする方法を、あなたは、合併の原理を説明するために、ソースコードを分析する記事の著者シャーディング-JDBCシリーズを見ることができます。
明白な条件付きクエリのパフォーマンスのシャーディング列に関してこの条件クエリは、多くのことをドロップします。限り、テーブルの実装などによるダウン遅い特定の要因に数十、サブライブラリーサブテーブルの何百も、存在する場合、それはバレル理論と一致している全体のSQLの実行が遅い応答を引き起こします。
より、これらの動作条件ファジークエリシステム、またはスクリーニングの10点の条件は何ですか。この場合は、インデックスを作成するための単一のテーブルが良くない場合でも、サブライブラリーのサブテーブルの場合は言うまでもありません。
それでは、どのようにそれを行うには？今回の有名なelasticsearchは、すなわちESは便利です。サブライブラリーのサブテーブルのすべてのデータESにそれらの複雑なクエリ処理における冗長ESの全額に。
淘宝網のページを以下のすべての私の注文、それは単一のテーブルは、サブライブラリーサブテーブルに言及し、（インデックスはこのシナリオを満たすために失敗した）の問題を解決しないことができない場合でも、そこに複数のフィルタ基準は、製品のタイトルがあいまい一致することがあります。
次のようにそのため、注文テーブルは、例えば、全体の構造は以下の通りであります：
特定の条件：これは、マルチシャーディングの列ではありません最後の、より大きなコストのケースを使用するのが最善ではありませんが、上記ユーザテーブルの作者は推奨されません。
ユーザテーブルが大きな特徴を持っているため、全世界の70億の人々があなたのユーザーであり、このデータ量が大きくないので、私はより多くのシングルシャーディング列+ ES単純化されたアーキテクチャモデルを使用することをお勧めしていても、その上限値が正であります
ES + HBaseのブリーフ
それはコミュニティに表示されたプログラムの周波数のSolr + HBaseの組み合わせは、一貫性を維持するために、この記事高くなる可能性があること、事前に明確にする必要があり、すべてのフルテキストインデックス方式選択は、ESです。
ES + HBaseのとSolrの+のHBaseとして優れている、または範囲のESとSolrにはより良いこの記事を議論する必要はないされていることを、実際には多くの議論のは意味がありません。
ESのSolrこれは2つの非常に良いとよくマッチしたミドルウェアです。近年では、より人気がES：
あなたはES +のHBaseとSolrの+ HBaseのメリットに関して、単一のすべての歴史的な荷物の選択プロセスを、脇に置くならば、後者がより良い選択であることは明らかです。
Solrの+ HBaseの高集積化のレベル、我々が最も懸念しているインデックスサービスの導入、一貫性の最も重要な指標、Solrの+ HBaseのは非常に成熟したソリューション11となっているリリーHBaseのインデクサー。
深い読み
アリクラウド上のクラウドデータベースHBaseのバージョンもSolrのフルテキストインデックスは、興味のある学生は多くを学ぶためにリンクを突くことができますを意味します。
https://help.aliyun.com/product/49055.html?spm=5176.124785.631202.con1.603452c0cz7bj2
ES + HBaseの原則
サブライブラリーサブテーブル拡張を乗算し続けることができるもののだけ、データの増加量と、コアサブライブラリ+ ESプログラムポイントテーブルとしてMySQLを用いて上述したが、この時間は、圧力があり、これをここでES減アーキテクチャは徐々に問題を暴露します！
一般的な受注テーブル、スケジュールとサブライブラリーサブテーブルのテーブルの他の統合ニーズは、列の数十、または（50があると仮定して）列の数百もの優れたコアを持つことになりますが、実際にテーブル全体は10件の条件に関わる条件の指標である必要はないかもしれません（10を想定）。
このとき、インデックスESへのすべてのフィールドのデータの50列の合計量は、クラスタESへの圧力がたくさんある、フラグメンテーションの回復の後ろのESは長い時間がかかります。
最も限り条件できるだけ必要なときに、クラスタの限られた資源は、ES最も貴重なデータ検索を保存するように、今回は、圧力ESを減らすことを検討することができます
クラスタ全体ES圧力が1/5に低減されるように、インデックスのみが、ESを検索するフィールド条件に関与することができるされた（表50コアフィールド、わずか10は、フィールド条件に参加します）
古典ES + HBaseの組合せレジメンであるHBaseの50フィールドに保存されたデータの合計量、すなわち、データ記憶方式の指標孤立
私たちは皆知っているシステムでのHadoop HBaseの記憶容量は膨大であり、そののrowKeyクエリのパフォーマンスに基づいて、超高速マルチES、および条件は非常に強力な検索機能と呼ばれています。
この方式のESとはHBaseの利点は、自分の欠点を回避すると同時に、ほとんどを再生するには、ベストプラクティスのアドバンテージ避けるということができます。
このように、それらの間の相互作用は何か：これはHBaseのであるから、まず、ユーザーのクエリによって条件の入力に応じてESのrowKey値がフィルタ条件を満たして取得した後、HBaseのクエリ、後ろのクエリ時間ステップほとんど無視できるまでのrowKey値を使用現場で最高。
図の相互作用を以下に示します。
HBaseのは、検索機能を拡張しました
Solrのための特別な-HBaseのHBaseの技術コミュニティ-HBaseアプリケーションからの写真
概要
次のように最後に、いくつかのオプションが（要約するシャーディングカラムはSCと呼びます）。
-
シングルSC
その他のSC
SC +それ
SC + ES + HBaseの
該当シーン |
シングル |
一般的な |
より広範 |
非常に広いです |
クエリ適時 |
タイムリー |
タイムリー |
よりタイムリー |
よりタイムリー |
記憶容量 |
一般的な |
一般的な |
大きな |
雅量 |
コストコード |
小さな |
大きな |
一般的な |
一般的な |
アーキテクチャの複雑さ |
シンプル |
一般的な |
難しいです |
非常に複雑な |
要するに、膨大なデータの量、および同時サブライブラリーサブテーブルの一定量があるには、問題を解決するサブライブラリーサブテーブルのミドルウェアを導入する特定のものではないが、むしろ体系的プロジェクト。私たちは、それが最も得意行うために、適切なミドルウェアを行い、テーブル全体に関連する業務を分析する必要があります。
例えば、シャーディングカラムクエリが行くESをフィルタリングするために、サブテーブルサブライブラリ一部曖昧クエリまたは複数の非固定の基準を行く、大容量記憶装置は、HBaseのです。
非常に多くのことをやった後、背中には、このようなデータの一貫性の同期として、やるべき仕事がたくさんあること、および操作の期間の後、いくつかのテーブル内のデータの量と、ゆっくりとボトルネック単一のテーブルに達し、この時間は、実行する必要があります冷たいデータ移行。
要するに、サブライブラリーのサブテーブルは、非常に複雑なシステムエンジニアリングです。データの任意の処理膨大な量は、それを戦うために準備を行うには簡単なことではありません！
終わり
著者：フーリガンのブログ
出典：
https://www.jianshu.com/p/f29e73b97794
この記事では、すべての作者に属します
ロングプレスマップ2次元コード、ジャコウネコの即時懸念[技術]巣
アリ、Jingdongは、米国のグループは、バイトに基づいて上位技術専門家を打ちます
ITの人々は、「温度」技術の巣を作成します！
ます。https：//juejin.im/post/5d01035c51882506400070e9で再現