ビッグデータ時代の大規模データストレージと高同時実行ソリューションの概要

1. 構造化データの保存

        インターネット アプリケーションの普及に伴い、大量のデータの保存とアクセスがシステム設計のボトルネックになっています。大規模なインターネット アプリケーションの場合、毎日数十億の PV がデータベースに非常に高い負荷をかけることは間違いありません。これは、システムの安定性と拡張性に大きな問題を引き起こしました。

• データベースを水平にシャーディングすると、単一マシンの負荷が軽減され、同時にダウンタイムによる損失を最小限に抑えることができます。
• 負荷分散戦略により、単一マシンのアクセス負荷が効果的に軽減され、ダウンタイムの可能性が減ります。
• クラスター ソリューションを通じて、データベースのダウンタイムによって引き起こされる単一ポイント データベースへのアクセス不能の問題が解決されます。
• 読み取りと書き込みの分離戦略により、アプリケーションでのデータの読み取り (読み取り) の速度と同時実行性が最大化されます。

1. データセグメンテーションとは何ですか

        データは、一連のセグメンテーション ルールを通じてさまざまな DB またはテーブルに水平に分散され、クエリ対象の特定の DB またはテーブルが、対応する DB ルーティング ルールまたはテーブル ルーティング ルールを通じて検索され、クエリ操作が実行されます。ここで言う「シャーディング」は通常「水平シャーディング」を指します。どのような分割方法やルーティング方法があるのでしょうか？次に、簡単な例を見てみましょう: ブログ アプリケーションのログを説明します。たとえば、ログ記事 (記事) テーブルには次のフィールドがあります。

Article_id(int)、title(varchar(128))、content(varchar(1024))、user_id(int)

これを行うには、user_id が 1 から 10000 までのすべての記事情報を DB1 の記事テーブルに入れ、user_id が 10001 から 20000 までのすべての記事情報を DB2 の記事テーブルに入れ、というように DBn まで続けます。同様に、サブデータベースのルールを使用して、特定の DB への逆ルーティングを行います。このプロセスを「DB ルーティング」と呼びます。

データ セグメンテーションの DB 設計を考慮すると、通常のルールと制約に違反します。セグメント化するには、データベース テーブルに冗長なフィールドが必要です。これらのフィールドは、サブデータベースと呼ばれるフィールドやタグ フィールドを区別するために使用されます。上記の記事の例の user_id フィールド (もちろん、今の例では user_id の冗長性があまり反映されていません。user_id フィールドはデータベースに分割されていなくても表示されるため、それを利用していると考えられます)それ）。もちろん、冗長フィールドの出現はサブデータベースの場面に限ったことではなく、多くの大規模アプリケーションにおいても冗長性が必要となり、効率的なDBの設計が必要となります。

2. データのセグメント化が必要な理由

        たとえば、article テーブルには 5000w 行のデータがあります。この時点で、このテーブルに新しいデータを追加 (挿入) する必要があります。挿入が完了すると、データベースはこのテーブルのインデックスを作成すると、5000 行のデータが作成されます。インデックス作成のオーバーヘッドは無視できません。しかし、逆に、このテーブルをarticle_001からarticle_100までの100のテーブルに分割すると、5000w行のデータが平均化され、各サブテーブルには500,000行のデータしかありません。このとき、50w行のみのテーブルを送信します。データの途中にデータを挿入した後にインデックスを構築する時間が大幅に短縮され、DB の実行効率が大幅に向上し、DB の同時実行性が向上します。もちろん、サブテーブルの利点はまだ知られていませんが、書き込み操作などのロック操作もあり、多くの明白な利点をもたらします。

Oracle の DB は確かに非常に成熟していて安定していますが、すべての企業が高額な使用コストとハイエンドのハードウェア サポートを負担できるわけではありません。無料の MySQL と安価なサーバー、さらには PC をクラスターとして使用して、ミニコンピューター + 大規模な商用 DB の効果を実現し、大幅な設備投資を削減し、運用コストを削減します。したがって、シャーディングを選択します 

3. データの分割方法

1. データのセグメンテーションは物理的に行うことができます。データは一連のセグメンテーション ルールを通じてさまざまな DB サーバーに分散され、ルーティング ルールを通じて特定のデータベースにアクセスされます。このようにして、各アクセスは単一のサーバーに直面することはありません。サーバーではなく N サーバーであるため、単一マシンにかかる負荷圧力を軽減できること。
2. データをデータベース内でセグメント化することもできます。一連のセグメント化ルールによって、データはデータベース内のさまざまなテーブルに分散されます。たとえば、article は、article_001 とarticle_002 などのサブテーブルに分割されます。いくつかのサブテーブルは水平方向に結合されます。論理的に完全な記事テーブルが作成されます。そうする目的は実際には非常に簡単です。 

        要約すると、サブライブラリはシングルポイント マシンの負荷を軽減し、サブテーブルはデータ操作の効率、特に書き込み操作の効率を向上させます。 これまでのところ、テキストをどのように分割するかという問題については触れていません。次に、セグメント化ルールを詳しく説明します。

        データの水平分割を実現するには、分割とフィールドのマーキングの基礎として各テーブルに冗長な文字が存在する必要があります。一般的なアプリケーションでは、識別フィールドとして user_id を使用します。これに基づいて、次の 3 つのサブデータベースがあります。方法とルール: 

数値セグメントで割る:

(1) user_id は区別であり、 1 ～ 1000 は DB1 に対応し、1001 ～ 2000 は DB2 に対応します。

利点: 部分的に移行可能

短所: データの分散が不均一である

(2) ハッシュ係数:

user_id をハッシュし (user_id が数値の場合は user_id の値を直接使用)、特定の数値を使用します。たとえば、アプリケーションでデータベースを 4 つのデータベースに分割する必要がある場合、user_id に数値 4 を使用します。ハッシュ値は剰余です。操作 (user_id%4)。このように、各操作には 4 つの可能性があります: 結果が 1 の場合は DB1 に対応し、結果が 2 の場合は DB2 に対応し、結果が 3 の場合は DB2 に対応します。 to DB3; 0の場合はDB4に相当し、4つのDBに均等にデータが分散されます。

長所: データが均等に分散されている

デメリット：データ移行が面倒、マシンの性能に応じたデータの割り当てができない

(3) データベース構成を認証ライブラリに保存する

user_id と DB の間のマッピング関係を個別に保存する DB を作成することです。データベースにアクセスするたびに、最初にデータベースにクエリを実行して特定の DB 情報を取得し、その後、必要なクエリ操作を実行する必要があります。

利点: 高い柔軟性、1 対 1 の関係

欠点: 各クエリの前にもう 1 つのクエリが必要となり、パフォーマンスが大幅に低下します。

        上記は通常の開発で選択する 3 つの方法ですが、複雑なプロジェクトによってはこれら 3 つの方法を組み合わせて使用​​する場合もあります。 上記の説明を通じて、サブライブラリのルールについても簡単に理解して理解することができます。もちろん、より優れた、より完全なサブライブラリ手法が存在するでしょうし、私たちは探索と発見を続ける必要があります。

分散データ ソリューションは次の機能を提供します。

(1) サブデータベースルールとルーティングルール(RRと呼ばれるRouteRule)を提供し、上記説明で述べた3つのセグメンテーションルールを本システムに直接埋め込む具体的な埋め込み方法については、以下の内容と考察で詳しく説明します。 ;

(2) データの高可用性を確保するためにクラスター (グループ) の概念を導入します。

(3) 負荷分散ポリシー (LB と呼ばれる LoadBalancePolicy) を導入します。

(4) クラスタ ノードの可用性検出メカニズムを導入して、シングルポイント マシンの可用性を定期的に検出して、LB 戦略の適切な実装を確保し、システムの高い安定性を確保します。

(5) データクエリ速度を向上させるために読み取り/書き込み分離を導入します。

大規模データ向けのストレージおよびアクセス ソリューション_思考、概要、焦点-CSDN ブログ_大規模データ ストレージ

2. 大量データと高い同時実行性を実現する主なソリューション

2.1. 大量のデータに対するソリューション:

1. キャッシュを使用します。
2. ページ静的テクノロジー。
3. データベースの最適化。
4. データベース内でアクティブな個別のデータ。
5. 一括読み取りと遅延変更。
6. 読み取りと書き込みの分離。
7. NoSQL や Hadoop などのテクノロジーを使用します。
8. 分散展開データベース。
9. アプリケーション サービスとデータ サービスの分離。
10. 検索エンジンを使用してデータベース内のデータを検索します。
11. 事業の分離。

2.2. 高い同時実行性のためのソリューション:

1. アプリケーションファイルと静的リソースファイルの分離。
2. ページのキャッシュ。
3. クラスターと分散。
4. リバースプロキシ。
5. CDN；

3. 大規模データのソリューション

3.1. キャッシュの使用

        Web サイトのアクセス データの特徴のほとんどは、ビジネス訪問の 80% が 20% のデータに集中するという「28 番目の法則」として示されています。

たとえば、ある期間では、Baidu の検索ホット ワードは少数の人気のある単語に焦点を当てている可能性があり、またある期間では、新浪微博でも、誰もが注目している少数のトピックに焦点を当てている可能性があります。

        一般に、ユーザーはデータ エントリ全体のごく一部しか使用しません。Web サイトがある程度の規模に発展し、データベース IO 操作がパフォーマンスのボトルネックになる場合、キャッシュを使用してこの一般的なデータのごく一部をメモリにキャッシュすることが非常に重要です。これを選択すると、データベースへの負荷が軽減されるだけでなく、Web サイト全体のデータ アクセス速度も向上します。

        キャッシュを使用する方法は、Map や ConcurrentHashMap を使用するなど、プログラム コードを通じてデータをメモリに直接保存する方法と、Redis、Ehcache、Memcache などのキャッシュ フレームワークを使用する方法です。

        キャッシュ フレームワークを使用するときに注意する必要があるのは、キャッシュをいつ作成するか、およびキャッシュの無効化戦略です。

キャッシュを作成するにはさまざまな方法があり、自社のビジネスに応じて選択する必要があります。たとえば、ニュース ホームページ上のニュースは、初めてデータが読み取られるときにキャッシュする必要があります。比較的クリック率の高い記事の場合は、記事の内容をキャッシュできます。

メモリ リソースが限られているため、キャッシュの作成方法の選択は検討する価値のある問題です。さらに、キャッシュの無効化メカニズムも慎重に検討する必要があり、無効化時間を設定したり、人気のあるデータの優先順位を設定したり、異なる優先度に応じて異なる無効化時間を設定したりすることで設定できます。

データを削除するときは、キャッシュの削除を考慮する必要があり、キャッシュを削除する前にデータがキャッシュの有効期限に達しているかどうかも考慮する必要があることに注意してください。

キャッシュを利用する場合には、キャッシュサーバーに障害が発生した場合に、N台以上のサーバーで同じデータをキャッシュしたり、分散配置でキャッシュデータを制御したりするなど、フォールトトレラントな処理を行うことも考慮する必要があります。の場合は、自動的に Go を他のマシンに切り替えます。または、ハッシュの整合性を通じて、キャッシュ サーバーが通常の使用を再開してキャッシュ サーバーに再指定されるまで待機します。ハッシュ整合性のもう 1 つの機能は、分散キャッシュ サーバーの下にデータを配置し、未使用のキャッシュ サーバーにデータを分散することです。

3.2. ページ静的テクノロジー

以下の図に示すように、従来の JSP インターフェイスを使用すると、フロントエンド インターフェイスの表示がバックグラウンド サーバーによってレンダリングされ、解析および実行のためにフロントエンド ブラウザに返されます。

もちろん、現在ではフロントエンドとバックエンドの分離が提唱されており、フロントエンドのインターフェイスは基本的に HTML Web ページのコードであり、Angular JS または NodeJS によって提供されるルートはデータを取得するためにバックエンド サーバーにリクエストを送信します。その後、ブラウザでデータをレンダリングすることで、バックエンド サーバーの負荷が大幅に軽減されます。

これらの静的HTML、CSS、JS、画像リソースなどはキャッシュサーバーやCDNサーバーに配置することもできますが、一般的にはCDNサーバーやNginxサーバーが提供する静的リソース機能が最もよく利用されます。

• ルール 1: HTTP リクエストを可能な限り最小限に抑えます。
• ルール 2: CDN を使用します。
• ルール 3: Expires ヘッダーを追加します。
• ルール 4: Gzip を使用してコンポーネントを圧縮します。
• ルール 5: スタイル シートを先頭に置きます。
• ルール 6: スクリプトを一番下に置きます。
• ルール 7: CSS 式は避けてください。
• ルール 8: 外部の JavaScript と CSS を使用します。
• ルール 9: DNS ルックアップを減らす
• ルール 10: 最小限の JavaScript。
• ルール 11: リダイレクトを避ける。
• ルール 12: 重複したスクリプトを削除します。
• ルール 13: ETag の構成
• ルール 14: Ajax をキャッシュ可能にする。

3.3. データベースの最適化

        ほとんどの Web サイトのパフォーマンスのボトルネックはデータベース IO 操作にあるため、データベースの最適化は Web サイト全体のパフォーマンスの最適化の最も基本的な部分です。キャッシュ テクノロジーは提供されていますが、データベースの最適化には依然として真剣に取り組む必要があります。通常、企業には独自の DBA チームがあり、データベースの作成やデータ モデルの確立などを担当しますが、データベースの最適化を理解していない少数の人々とは異なり、データベースの最適化に関する記事をインターネットで見つけて自分で調べることしかできません。データベース最適化のアイデアの体系を形成しませんでした。

データベースの最適化に関しては、テクノロジーをお金と交換する方法です。データベースを最適化する方法は数多くありますが、一般的な方法は、データベース テーブル構造の最適化、SQL ステートメントの最適化、パーティショニング、サブテーブル、インデックスの最適化、直接操作の代わりにストアド プロシージャを使用するなどに分類できます。

3.3.1、テーブル構造の最適化

        データベースの開発仕様や利用スキル、設計や最適化については、以前いくつかの記事でまとめましたが、面倒なのでアドレスを直接載せておきますので、必要な方はご覧ください。仕様と使用スキル: http://blog.csdn.net/xlgen157387/article/details/48086607
b
) 数千万のデータベース クエリにおいて、クエリ効率を向上させるにはどうすればよいでしょうか? : http://blog.csdn.net/xlgen157387/article/details/44156679

        また、データベース テーブルを設計するとき、外部キーを作成する必要がありますか? 外部キーを使用する利点の 1 つは、カスケード削除操作を簡単に実行できることです。ただし、データ ビジネス操作を実行するとき、私たちは皆、データを確実に保存するためにさまざまな手段を使用します。読み取り操作の一貫性を考えると、外部キーを使用して MySQL を関連付けてカスケード削除操作を自動的に完了するよりも、自分で削除操作を行うものを使用する方が安心だと感じます。

3.3.2、SQLの最適化

        SQLの最適化は主にSQL文の処理ロジックの最適化が目的であり、インデックスと併用する必要もあります。また、SQL ステートメントの最適化では、特定のビジネス メソッドを最適化することもでき、ビジネス ロジック操作を実行するデータベースの実行時間を記録して、ターゲットを絞った最適化を行うこともできます。たとえば、次の図はデータベース操作呼び出しの実行時間を示しています。

SQL 最適化に関するいくつかの提案は以前に整理されています。次のページに移動してください。

a) MySQL パフォーマンス最適化の 19 ポイントの分析: http://blog.csdn.net/xlgen157387/article/details/50735269

b) MySQL バッチ SQL 挿入のさまざまなパフォーマンスの最適化: http://blog.csdn.net/xlgen157387/article/details/50949930

3.3.3 サブテーブル

        サブテーブルとは、大きなテーブルを特定のルールに従って独立した記憶領域を持つ複数のエンティティ テーブルに分解することです。サブテーブルと呼ぶことができます。各テーブルは、MYD データ ファイル、.MYI インデックス ファイル、.frm テーブル構造の 3 つのファイルに対応します。ファイル。これらのサブテーブルは、同じディスク上または異なるマシン上に分散できます。データベースの読み取りおよび書き込み操作中に、事前に定義されたルールに従って、対応するサブテーブル名を取得して操作します。

たとえば、
ユーザー テーブルにはユーザーの多くの役割があり、ユーザーは学生、教師、企業などのタイプを列挙することでさまざまなカテゴリに分類できます。このようにして、カテゴリに従ってデータベースを分割できます。その場合、クエリを実行するたびに、ユーザーのタイプに応じてより狭い範囲がロックされるようになります。

ただし、テーブルを分割した後、完全な順序をクエリする必要がある場合は、複数テーブル操作を使用する必要があります。

3.3.4、パーティション

        データベースのパーティショニングは、DBA やデータベース モデラーにとって馴染みのある物理データベース設計手法です。パーティショニング テクノロジはさまざまな効果をもたらしますが、その主な目的は、特定の SQL 操作で読み書きされるデータの総量を減らし、応答時間を短縮することです。

        パーティションはサブテーブルに似ており、ルールに従ってテーブルを分割します。違いは、サブテーブルは大きなテーブルをいくつかの独立したエンティティ テーブルに分解するのに対し、パーティショニングはデータ セグメントを複数の場所 (同じディスク上または異なるマシン上に存在できる) に分割することです。パーティション化後も、表面上はテーブルのままですが、データは複数の場所にハッシュされています。データベースの読み取りおよび書き込み時には、大きなテーブルの名前が引き続き操作され、DMS によってパーティション化されたデータが自動的に編成されます。

        テーブル内のデータが非常に大きくなると、データの読み取りとデータのクエリの効率が非常に低くなり、データを別のデータ テーブルに分割して保存するのは簡単ですが、テーブルを分割した後の操作がさらに面倒になります。これは、同じ種類のデータを異なるテーブルに配置した場合、データを検索するときにこれらのテーブル内のデータを簡単にクエリする必要があるためです。CRUD操作を行うには、対応するテーブルをすべて検索する必要がありますが、異なるテーブルが含まれる場合は、テーブルをまたいだ操作が必要となり、やはり非常に面倒です。

        この問題はパーティショニングによって解決できます。パーティショニングとは、テーブル内のデータを一定の規則に従って異なる領域に分割して格納することです。このようにして、データ クエリを実行するときに、データ範囲が同じ領域にある場合は、データをデタッチすることができます。この方法は、データ量が少なくなり、動作速度が速くなり、プログラムに対して透過的であり、プログラムを修正する必要がありません。

3.3.5. インデックスの最適化

        インデックスの一般原理は、データが変更されたときに、あらかじめ指定されたフィールドの順序に並べてテーブル状の構造に格納することで、検索インデックス フィールドが条件付きレコードの場合、対応するレコードをインデックスポインタから素早く検索され、対応するデータをテーブルから取得するため、速度が非常に高速です。

ただし、クエリ効率は大幅に向上しましたが、追加、削除、変更時にデータが変更されるため、対応するインデックスを更新するのはリソースの無駄でもあります。

        インデックスの使用の問題については、問題に応じて異なる議論を行う必要がありますが、特定のビジネス ニーズに応じて適切なインデックスを選択することは、パフォーマンスを向上させるための当然の対策です。

読むことをお勧めする記事:

a) データベース インデックスの役割、メリット、デメリット、およびインデックスの 11 の用途: http://blog.csdn.net/xlgen157387/article/details/45030829

b) データベースのインデックス作成の原理: http://blog.csdn.net/kennyrose/article/details/7532032

3.3.6. 直接操作の代わりにストアドプロシージャを使用する

        ストアド プロシージャ (Stored Procedure) は大規模なデータベース システム内にあり、特定の関数を完了するための一連の SQL ステートメントがデータベースに保存され、最初のコンパイル後に呼び出しを再度コンパイルする必要がなく、ユーザーが名前を指定します。ストアド プロシージャを作成し、それを実行するためのパラメータを指定します (ストアド プロシージャにパラメータがある場合)。ストアド プロシージャはデータベース内の重要なオブジェクトであり、適切に設計されたデータベース アプリケーションではストアド プロシージャを使用する必要があります。

操作プロセスが比較的複雑で呼び出し頻度が比較的高い業務では、記述されたSQL文をストアドプロシージャに置き換えることができ、ストアドプロシージャを使用すると、一度変更するだけで済み、一部の複雑な操作を一度に実行できます。ストアドプロシージャ

3.4. データベース内のアクティブなデータを分離する

        前述の「第28法則」と同様に、Webサイト上には大量のデータが存在するものの、頻繁にアクセスされるデータは限られているため、これらの比較的アクティブなデータを分離して保存することで処理効率を向上させることができます。

実際、キャッシュを使用するという以前のアイデアは、データベース内のアクティブなデータを分離し、一般的なデータをメモリにキャッシュするという明白なユースケースです。

別のシナリオとしては、たとえば、Web サイトには数千万人の登録ユーザーがいますが、頻繁にログインするユーザーの数は 100 万人だけで、残りのユーザーは基本的に長期間ログインしていない場合です。ユーザー」は個別に分離されているため、他のログイン ユーザーをクエリするたびに、これらのゾンビ ユーザーのクエリ操作が無駄になります。

3.5. バッチ読み取りと遅延変更

        一括読み込み・遅延修正の原理は、データベースの操作作業を軽減して効率を向上させることです。

バッチ読み取りは、各データベース要求操作にリンクの確立と解放が必要であり、依然としてリソースの一部を占有しているため、複数のクエリを 1 つの読み取りに結合することです。バッチ読み取りは非同期で読み取ることができます。

遅延変更は、同時実行性が高く、頻繁に変更されるデータに対するものです。変更のたびに、データはまずキャッシュに保存され、次にキャッシュ内のデータが一定の間隔でデータベースに保存されます。プログラムは同時にデータを読み取ることができます。データベースおよびキャッシュからデータを読み取ります。

3.6、読み取りと書き込みの分離

        読み取りと書き込みの分離の本質は、アプリケーション プログラムの読み取りおよび書き込み操作を複数のデータベース サーバーに分散し、それによって単一データベースへのアクセス圧力を軽減することです。

読み取りと書き込みの分離は、通常、マスターとスレーブのデータベースを構成することで行われ、スレーブ データベースからデータを読み取り、データベースの追加、変更、削除を実行してマスター データベースを操作します。

関連記事をご覧ください:
a) MySQL5.6 データベースのマスター/スレーブ (マスター/スレーブ) 同期のインストールと構成の詳細: http://blog.csdn.net/xlgen157387/article/details/51331244
b) MySQL マスター/スレーブ レプリケーションの概要共通トポロジ、原理分析、およびマスター/スレーブ レプリケーションの効率を向上させる方法: http://blog.csdn.net/xlgen157387/article/details/52451613

3.7. NoSQL や Hadoop/HBase などのテクノロジーの使用

        NoSQLは、非構造化された非リレーショナルデータベースであり、その柔軟性により、リレーショナルデータベースのルールや規制を打ち破り、柔軟な運用が可能であり、また、NoSQLはデータを複数のブロックに格納するため、ビッグデータの運用速度が向上します。もかなり速いです

3.8. 分散配置データベース

        強力な単一サーバーでは、大規模な Web サイトで増え続けるビジネス ニーズを満たすことはできません。データベースが読み取りと書き込みによって分離された後、1 つのデータベース サーバーが 2 つ以上のデータベース サーバーに分割されますが、それでも成長し続けるビジネス ニーズを満たすことはできません。分散展開データベースは、Web サイト データベースを分割する最後の手段であり、単一のテーブル内のデータが非常に大きい場合にのみ使用されます。

分散データベースの展開は理想的な状況です。分散データベースは、テーブルを異なるデータベースに保存し、それらを異なるデータベースに配置します。このようにして、リクエストを処理するときに、複数のテーブルを呼び出す必要がある場合、複数のサーバーで同時に処理することができます。これにより、処理効率が向上します。

分散データベースの簡単なアーキテクチャ図は次のとおりです。 

3.9. アプリケーションサービスとデータサービスの分離

        アプリケーションサーバーとデータベースサーバーを分離する目的は、アプリケーションサーバーとデータベースサーバーの特性に合わせて最下層を最適化することで、それぞれのサーバーの特性をより良く活用することです。アプリケーション サーバーは、ある程度のディスク容量を必要とします。アプリケーション サーバーはそれほど多くのディスク容量を必要としないため、分離することは有益であり、サーバーの障害や他のサービスが使用できなくなることを防ぐこともできます。
 

3.10. 検索エンジンを使用してデータベース内のデータを検索する

        非データベース クエリ テクノロジである検索エンジンを使用すると、Web サイト アプリケーションの拡張性と分散性がより適切にサポートされます。

Solr などの一般的な検索エンジンは、「新華辞典」を使用してキーワードを検索するのと同じように、逆索引方式を通じてキーワードとドキュメント間のマッピング関係を維持します。まず、辞書のディレクトリを調べてから、辞書を見つけます。 . 特定の場所。

検索エンジンは、キーワードとドキュメントの特定のマッピング関係を維持することで、検索対象のデータを迅速に見つけることができ、従来のデータベース検索方法と比較して効率は依然として非常に高いです。

Solr と MySQL のクエリ パフォーマンスの比較に関する記事:
Solr と MySQL のクエリ パフォーマンスの比較: http://www.cnblogs.com/luxiaoxun/p/4696477.html?utm_source=tuicool&utm_medium=referral

3.11. 事業の分割

        結局のところ、なぜビジネスを分割するのかというと、依然として不合理なビジネス データ テーブルを使用して別のサーバーに展開し、Web サイトのニーズを満たすために対応するデータを検索しているのです。各アプリケーションは、指定された URL を使用して接続し、さまざまなサービスを取得します。

たとえば、大規模なショッピング Web サイトでは、ホームページ、ショップ、注文、購入者、販売者などをさまざまなサブビジネスに分割します。一方で、ビジネス モジュールは開発のためにさまざまなチームに分割されます。データベース テーブルは、 1 つのビジネス モジュールで使用されるデータベース サーバーに障害が発生しても、他のビジネス モジュールのデータベースの通常の使用には影響しません。さらに、いずれかのモジュールへのアクセス数が急増した場合、このモジュールで使用されるデータベースの数をビジネス ニーズに合わせて動的に拡張できます。
 

4. 高い同時実行性のためのソリューション

4.1、アプリケーションファイルと静的リソースファイルは分離されています

        いわゆる静的リソースとは、Webサイト内で使用されるHtml、Css、Js、Image、Video、Gifなどの静的リソースのことです。アプリケーションと静的リソース ファイルの分離も、フロントエンドとバックエンドの分離の一般的なソリューションです。アプリケーション サービスは対応するデータ サービスのみを提供し、静的リソースは指定されたサーバー (Nginx サーバーまたは CDN サーバー) にデプロイされ、フロントエンド インターフェイスが提供されます。 Angular JS を通じて作成されるか、Node JS によって提供されるルーティング テクノロジーがアプリケーション サーバーの特定のサービスにアクセスして、対応するデータを取得し、フロントエンド ブラウザーでレンダリングします。これにより、バックエンド サーバーの負荷が大幅に軽減されます。

たとえば、Baidu のホームページで使用されている写真は、別のドメイン ネーム サーバーに展開されています。

4.2. ページキャッシュ

        ページ キャッシュは、アプリケーションによって生成される、データがほとんど変更されないページをキャッシュするため、毎回ページを再生成する必要がなく、CPU リソースを大幅に節約できます。キャッシュされたページをメモリー。

Nginxが提供するキャッシュ機能を利用することもできますし、専用のページキャッシュサーバーであるSquidを利用することもできます。

4.3. クラスターと分散

4.4. リバースプロキシ

http://blog.csdn.net/xlgen157387/article/details/49781487

4.5、CDN

        CDN サーバーは実際にはクラスター ページ キャッシュ サーバーであり、その目的はユーザーが必要とするデータをできるだけ早く返すことであり、一方ではユーザーのアクセス速度を高速化し、他方では負荷も軽減しますバックエンドサーバーへの負荷。

CDNの正式名称はContent Delivery Network、つまりコンテンツ配信ネットワークです。基本的な考え方は、データ伝送の速度と安定性に影響を与える可能性のあるインターネット上のボトルネックやリンクを可能な限り回避し、コンテンツ伝送をより速く、より安定させることです。

CDNは、ネットワーク上にノードサーバーを配置し、既存のインターネットを基盤としたインテリジェントな仮想ネットワーク層を構成し、ネットワークトラフィック、各ノードの接続状況、負荷状況、距離などに応じてリアルタイムに応答します。時間などの包括的な情報により、ユーザーのリクエストはユーザーに最も近いサービス ノードにリダイレクトされます。ユーザーが必要なコンテンツを近くで入手できるようにし、インターネットネットワークの混雑状況を解消し、Webサイトへのアクセスの応答速度を向上させることを目的としています。

つまり、CDNサーバーはネットワーク事業者のコンピュータルームに設置され、ユーザーに最も近いデータアクセスサービスを提供し、ユーザーがウェブサイトサービスを要求すると、ネットワークプロバイダーのコンピュータルームからデータを取得することができます。ユーザーに最も近い。テレコム ユーザーはテレコム ノードを割り当て、チャイナ ユニコム ユーザーはチャイナ ユニコム ノードを割り当てます。

CDN のリクエストの割り当て方法は特殊で、通常の負荷分散サーバーによるリクエストの割り当てではなく、ドメイン名を解決する際に特別な CDN ドメイン名解決サーバーによって割り当てられます。

CDN の構造図は次のとおりです。
 

V. まとめ

もちろん、大規模な Web サイト アプリケーション向けの大量のデータと高い同時実行性のソリューションは、これらの手法やテクノロジに限定されず、成熟したソリューションが多数あり、必要に応じて自分で学ぶことができます。