大規模なウェブサイトアーキテクチャを設計・構築する際に考慮すべき10の課題

ここでは、PHP、JSP、または .NET 環境については説明しません。アーキテクチャの観点から問題を見ています。実装言語は問題ではありません。言語の利点は、品質ではなく実装にあります。どの言語を選択するかに関係なく、アーキテクチャは必ず対処しなければならないものです。

1.大量データの処理

ご存知のとおり、比較的小規模なサイトでは、データの量はそれほど多くないため、選択と更新によって直面している問題を解決できます。負荷自体はそれほど大きくなく、せいぜいいくつかのインデックスを追加することで解決できます。大規模なウェブサイトの場合、1 日のデータ量は数百万に達することがあります。多対多の関係が適切に設計されていない場合、初期段階では問題はありませんが、ユーザー数が増えるにつれて、データ量は指数関数的に増加します。現時点では、テーブルの選択と更新のコスト（複数テーブルの結合クエリは言うまでもありません）は非常に高くなります。

2.データ同時処理

ある時点で、2.0 の CTO はキャッシュという魔法の剣を手に入れます。キャッシュに関しては、同時実行性が高く、処理量が多い場合にも大きな問題となります。キャッシュはアプリケーション全体でグローバルに共有されます。ただし、変更を加えたときに、2 つ以上のリクエストが同時にキャッシュの更新を要求すると、アプリケーションがクラッシュします。このとき、適切なデータ同時処理戦略とキャッシュ戦略が必要です。

さらに、データベースのデッドロックの問題もあります。普段は感じないかもしれませんが、同時実行性の高い状況ではデッドロックの可能性が非常に高く、ディスク キャッシュが大きな問題となります。

3.ファイル保存の問題

ファイルのアップロードをサポートする一部の 2.0 サイトでは、ハード ディスクの容量がどんどん大きくなっているのはありがたいことですが、ファイルをどのように保存し、効果的にインデックスを作成するかについて、さらに検討する必要があります。一般的な解決策は、ファイルを日付と種類別に保存することです。ただし、ファイル ボリュームが膨大で、ハード ディスクに 500G の些細なファイルが格納されている場合、ディスクの Io はメンテナンスや使用中に大きな問題になります。帯域幅が十分であっても、ディスクが応答しない可能性があります。この時点でアップロードが伴うと、ディスクはすぐにいっぱいになります。

おそらく、RAID と専用ストレージ サーバーを使用すれば現在の問題は解決できるでしょうが、さまざまな場所からのアクセスの問題もあります。サーバーは北京にあるかもしれませんが、雲南省や新疆チベット自治区でのアクセス速度をどう解決すればよいのでしょうか。分散ストレージを使用する場合、ファイル インデックスとアーキテクチャをどのように計画すればよいのでしょうか。

したがって、ファイルの保存は非常に難しい問題であることを認めなければなりません。

4.データ関係の処理

多対多の関係が満載の第 3 正規形に準拠したデータベースを簡単に計画し、INDENTIFY COLUMN の代わりに GUID を使用することができます。ただし、多対多の関係が満載の 2.0 時代では、第 3 正規形は真っ先に放棄されるべきものです。複数テーブルの共同クエリを効果的に最小限に抑える必要があります。

5.データのインデックス作成の問題

ご存知のとおり、インデックス作成はデータベースクエリの効率を向上させる最も便利で、安価で、簡単な方法です。しかし、UPDATE が多い場合、更新や削除のコストが想像を絶するほど高くなります。集中したインデックスの更新が完了するまでに 10 分もかかるという状況に遭遇したことがあります。サイトにとって、これは基本的に耐えられないことです。

インデックスと更新は天敵です。問題 A、D、E はアーキテクチャを作成する際に考慮しなければならない問題であり、最も時間がかかる問題である可能性もあります。

6.分散処理

2.0のウェブサイトはインタラクティブ性が高いため、CDN導入の効果は基本的に0です。コンテンツはリアルタイムで更新され、定型的に処理されます。さまざまな場所でのアクセス速度を確保するには、データの同期と更新をいかに効率的に実現するかという大きな課題に直面します。さまざまな場所にあるサーバー間のリアルタイム通信は、検討しなければならない課題です。

7. Ajaxの長所と短所の分析

AJAX は成功と失敗の両方の原因です。AJAX は主流のトレンドとなり、突然、XMLHTTP に基づく post と get が非常に簡単であることがわかりました。クライアントはサーバーにデータを取得または投稿し、サーバーはデータ要求を受け取った後にデータを返します。これは通常の AJAX 要求です。しかし、AJAX を処理する際にパケットキャプチャツールを使用すれば、データの返却や処理が一目で分かります。大量の計算を必要とする一部の AJAX リクエストに対しては、Web サーバーを簡単に停止できるパケット ディスパッチャーを構築できます。

8.データセキュリティの分析

HTTP プロトコルの場合、データ パケットはプレーン テキストで送信されます。暗号化を使用できると言えるかもしれませんが、G 問題の場合、暗号化プロセスはプレーン テキストである可能性があります (たとえば、QQ は暗号化を簡単に判別し、それと同じ暗号化および復号化方法を効果的に記述できることがわかっています)。サイトのトラフィックがそれほど大きくない場合は、誰も気にしませんが、トラフィックが増加すると、いわゆるプラグインといわゆる大量メッセージが次々と現れます（最初のQQの大量メッセージから手がかりがわかります）。おそらく、これを実現するために、より高レベルの判断や HTTPS さえも使用できると満足して言えるでしょう。これらのプロセスを実行すると、膨大な量のデータベース、IO、CPU コストがかかることに注意してください。一部の大量メッセージの場合、基本的に不可能です。著者はすでにBaidu SpaceとQQ Spaceでグループメッセージングを実現しています。みんなが試してみれば、実はそれほど難しいことではありません。

9.データ同期とクラスタ処理の問題

データベース サーバーの 1 つが過負荷になった場合は、データベース ベースの負荷とクラスタリングを実行する必要があります。これは最も厄介な問題かもしれません。ネットワークベースのデータ転送では、データベースの設計によってはデータの遅延が発生する可能性があります。これはひどく避けられない問題です。この場合、数秒または数分の遅延内で効果的な相互作用を確保するために、他の手段を使用する必要があります。たとえば、データのハッシュ化、セグメンテーション、コンテンツ処理などの問題です。

10.データ共有チャネルとOPENAPIの動向

OpenAPI は避けられないトレンドになっています。Google、Facebook、Myspace から国内のキャンパスまで、誰もがこの問題を検討しています。これにより、ユーザーをより効果的に維持し、ユーザー間の関心を高め、より多くの人が最も効果的な開発を行うのを手伝うことができます。このとき、効果的なデータ共有プラットフォームとデータオープンプラットフォームが不可欠になります。オープンインターフェースでのデータのセキュリティとパフォーマンスの確保も、真剣に検討しなければならない課題です。