ホームページ >バックエンド開発 >PHPチュートリアル >Douban アーキテクチャ変更共有セッションの概要_PHP チュートリアル
Douban アーキテクチャ変更共有セッションの概要_PHP チュートリアル
- WBOYオリジナル
- 2016-07-13 17:17:24792ブラウズ
重要なポイントは次のとおりです:
現在PCサーバーは23台あります
1日あたりのPV数は約2,000万です。登録ユーザー数は300万人。
ほとんどのテーブル データには数千万行があります。
5 人のアルゴリズム チーム。さらに、フルタイムとパートタイムを含む合計 11 人の開発者がいます (以前、Bai Xing.com がテクノロジーを共有していたとき、開発者はわずか 10 人でした)。2006 年には、毎年約 120 万件の動的リクエストがありました。日。現時点での主なボトルネックはディスク i/0 です。ベンチャーキャピタルを獲得し、ハードウェア機器を購入する資金を用意してください。 2 台の iu サーバー (デュアルコア、4g メモリ) を購入します
1 台はアプリケーション サーバーとして使用され、もう 1 台はデータベース サーバーとして使用されます。デュアルライン IP コンピューター ルームに移行し、DNS を使用して異なるネットワーク セグメントの IP アドレスを解決します。どのネットワーク セグメントがテレコムに属しているかを確認します) セグメントは Netcom であり、自分で分析できます)。講演の最後に述べられたコンピューター室の調整を読んだ後、これは実際には回り道であると感じました。DNS 分析の側面を解決するには、適切なコンピューター室を選択することができます (後で、データ分散に IP セグメントに依存するのは信頼できないと結論付けました)。 )
具体的にはどうすればいいですか? 複数回線対応のコンピューター室(教育ネットワーク、Tietongなど)に置きます
そうするとその必要はありません。複数の IP セグメントを自分で割り当てる (つまり、アクセスするユーザーが Telecom か China Netcom かなどを判断する)。
メモリ キャッシュを使用するための 2 つの原則 (Douban は memcached を使用します):
1. より多くのリソースを消費する必要があるデータの場合
2. 再利用する必要があるデータ。 1 回だけ使用する必要がある場合、たとえリソースを消費しても、キャッシュにスローする意味はあまりありません
理解してください: メモリ キャッシュにもメモリが必要であり、無駄にする必要はありません。再利用する必要がない場合は、メモリに放り込むのは無駄です (結局のところ、メモリは安くはなく、Douban のメカニック ヒット率は非常に高いのです)。これもかなりのストレスから解放されます。
innodb は行レベルのストレージをサポートしているため、優れた同時アクセスのサポートを備えています。 myisam を使用するか innodb を使用するかに関係なく、そのビジネス特性は次のとおりです: 読み取りを多くして書き込みを少なく、myisam を使用、書き込みを多くし読み取りを少なく、innodb を使用します
データベースのセグメント化に関して: 現在は機能に従って分割されています (著者は説明していません)詳細には、機能モジュールに応じて分割する必要があります) 機能モジュールに関連するテーブルはライブラリに配置されます)、前述したように、古典的な mysql マスター/スレーブ アーキテクチャが使用されます。したがって、各ライブラリは実際には 3 回繰り返されます (メイン ライブラリと補助ライブラリだと彼は言いました)。 mysqlスレーブサーバーは3台になるはずです
データベースを分割した後、複数のライブラリを操作し、カーソルを使用して特定のライブラリと特定のテーブルを取得します。パラメータを渡します（詳細はわかりません）
データベースのマスター/スレーブレプリケーションの遅延の問題は、常に一般的な問題です。
ハードドライブの購入は教訓です。最初は、ディスクをアップグレードすることは不可能なので、より良いディスクを購入するためにより多くのお金を投資するほうがよいでしょう。それまでにウェブサイトはそれを保持できなくなります。まだ変わらなければなりません。そうですね、最初は、ビジネスが急速に発展すると交換する必要があるため、より多くのお金を出して高速ディスクを購入することをお勧めします。たとえ高価であっても、ディスクは無駄にはなりません。
1 日あたり 200 万件の動的リクエストに関して、Douban 氏は、静的な小さなファイル サービス (ユーザー アバター、カバー写真) がディスク i/0 をボトルネックにしていると述べました。以前は、私が愚かですべての写真を保存していました。このディレクトリの下には数十万の小さなファイルがあります（これは ls コマンドを使用できなくなる直接的な原因となり、使用するとすぐにサーバーが停止します）。ディレクトリ。各ディレクトリを 10,000 個のファイルに分割します。
専任のデータマイニングチームを擁します。アルゴリズム チームは行列計算を実行し、その結果をフロントエンドのクエリと表示のために mysql に入力します。
Douban の fs は、画像ストレージ用に特別に開発されました。実はこの仕組みはAmazonのものをベースにしており、書き込み時にはデータのコピーが3つ書き込まれます。
ディスクのランダム シークはスループットよりも重要です。当時のパフォーマンスのボトルネックはディスクのシーク速度でした (これは、大量の画像アクセスによって引き起こされるディスク ヘッドの位置決めによって引き起こされる遅延に似ています)。タオバオの画像ファイル システムの以前の分析と同様)
その後、すべての myisam テーブルが innodb テーブルに変更されました。
Innodb のキャッシュ: プロセス内 (つまりメモリ内) で自己管理されますが、myisam のキャッシュはファイルに基づいています (オペレーティング システムによって制御されます)。以前は、myisam テーブルと innodb テーブルの両方が使用されていたため、2 種類のテーブルがメモリをめぐって互いに競合し、効率的ではありませんでした。すべてのインデックスは innodb ストレージ エンジンによって置き換えられます (これについてはよく理解していませんが、メモリをより有効に活用するための考慮事項であることだけは理解しています)
アプリケーション サーバーの障害: nginx には独自の機能が付属しています。
写真のトラフィックは大きなコストになっています。天津コンピューター室に移行する方が安いからです。キャビネットは比較的安価で、すべてのデータ マイニング データと画像データをそこに移動できます。
北京と天津に2つのコンピュータールーム。それぞれが mysql のマスター/スレーブ構造を構築します。
検索: 以前は mysql の全文インデックスを使用していました。その後、sphinxを使うように移行され(これはmysqlのストレージエンジンとしてmysqlと組み合わせて使われていました)、その後xapinになりました
なぜsphinxを使わなかったのでしょうか？詳しい説明はありません
MogileFS を使用して画像を保存し、その後開発された doubanfs ストレージを使用します。移行の理由: Mogilefs にはパフォーマンスのボトルネックがあります。mogilefs はメタデータ (名前空間およびファイルの場所) を mysql に保存するため、データベースの行数が増加するにつれて速度が低下します。多数の小さなファイルをデータベースから読み取る必要があるため、速度にも影響します。当時の行数は非常に急速に増加しており、当時のボトルネックは mysql データベースでした。
大きなフィールドはデータベースのパフォーマンスに影響します。実際、データテーブルの行数はそれほど多くありません。それは広大なフィールドの影響です。大きなテキストフィールドは削除され、私が開発したdoubanDBに保存されます（Amazonのdymamoを参考にして簡略化されたキーバリューデータベースです）。基盤となるストレージは tokyocabinet に基づいています。その後、doubanfs が doubandb に基づいて書き換えられ、画像を保存するために実装されました。
デュアルマスターソリューションを使用してください。これにより、書き込みと読み取りの両方が同じマスターに対して行われ、読み取られたデータが最新であるため、レプリケーション遅延の問題が解決されます。以前は、マスターから書き込んでからスレーブから読み取ると、lvs のデプロイでデータ遅延が発生しました。
以前はメッセージキューとしてspreadを使用していましたが、その後代わりにrabbitMQを使用しました
============================= ==== =======================
要約: そのアーキテクチャと技術的ソリューションをコピーすることは現実的ではありません。彼の間違いとその背後にある設計思想から学ぶことによってのみ、私たちは本質を学ぶことができます（主に、なぜそのようになっているのか、そしてそれがどのような考慮事項に基づいているのかを理解することができます）。
サブライブラリは、まず機能的な観点から領域を分割します。まだ水平分割を行う必要はありません。関数関連のテーブルをライブラリまたは別のサーバーに配置するために必要な段階です。
マシンがメモリを過剰に消費することはありませんが、一般的なメモリがボトルネックになることがよくあります (多数の接続と計算データがメモリ不足につながる可能性があります)。 Memcached は安くありません (ネットワーク i/0、CPU を消費します)。 memcached に何を入れるか注意してください。
データベースの結合操作を避ける (これは、以前 Shi Zhan が共有した観点と似ています。結合操作を減らし、データの複数の取得に分割することを好みます。Facebook のアーキテクチャでは、JOIN 操作を行わないことにも言及しています)
全体的な印象としては、Douban から学んだデータベース体験はサブデータベースに関するものであると言えます。訪問レベルは水平方向に分割する必要はなく、データベースに分割したり、ビジネス機能に応じて分割したりできます。ビジネス関数モジュールに関連するテーブルは同じライブラリに分割されます。次に、データベース サーバー上でマスターとスレーブの同期を実行して、データのホット バックアップを維持します。
業界におけるシャーディングのアプリケーションシナリオは、基本的に読み取りアプリケーションが比較的重く、トランザクションのセキュリティ要件が高くない状況です。
sata*3 を確認したところ、450G は 1 つあたり 1,000 元以上かかります。
SATAハードドライブは故障率が比較的高いため、SCSIハードドライブに交換しました。
画像ストレージまたは小さなファイルストレージの場合、大容量（トラフィックコスト、ストレージコスト）のため、独自のファイルシステムを開発しました
画像ストレージがストレージにデータベースに依存している場合、データ量が大きい場合、確かにボトルネックになるでしょう（タオバオの画像ファイルシステムが画像の保存ファイル名にメタデータの一部を隠すのも不思議ではありません）
質問: 北京と天津はコンピュータルームを越えて、両側のmysql、またはデータマイニングプログラム間でデータを同期します。天津から北京へ データ書き込みの速度はどれくらいですか？
情報を確認したところ、一般に専用の光ファイバーネットワークチャネルの使用が必要であることがわかりました。
www.bkjia.com