タオバオの技術発展レビュー（V）Java時代：堅固な岩のように

すでに何人かの読者から、IOE を削除する方法についての質問が寄せられています。心配しないでください。IOE を削除するにはまだ長い道のりがあります。 Xingdian と彼のチームがミニコンピュータを購入した後、私たちは Oracle を使い始めました。Qigong は DBA グループを率いて SQL とストレージを最適化し、Xingdian は数人のアーキテクトを率いてデータベースのスケーラビリティを調査しました。 Oracle自体はクローズドシステムです。Oracleを拡張するにはどうすればいいでしょうか？今流行りの用語で言えば、「データベースとテーブルを分割する」ということです。

Oracle サーバーの処理能力には上限があり、接続プールの数も制限されており、クエリ速度は容量に反比例することがわかっています。簡単に言えば、データ量とクエリ数が数億に達すると限界に達します。この制限を突破する最も簡単な方法は、より多くの Oracle データベースを使用することです。しかし、クローズド システムを拡張するのは、分散システムを拡張するほど簡単ではありません。ユーザー情報はID別に2つのデータベース（DB1/DB2）に格納し、商品情報と販売者情報は対応する2つのデータベースに格納し、商品カテゴリなどの共通情報は3つ目のデータベース（DBcommon）に格納します。これを行う目的は、データベースの容量を増やすだけでなく、災害復旧を提供することでもあります。データベースに障害が発生した場合でも、Web サイト全体のデータの半分は引き続き操作できます。

データベースがこのように分割されると、アプリケーションに問題が発生します。私が購入者で、購入した製品が DB1 と DB2 の両方にある場合、「購入した製品」を確認したいときにアプリケーションは何をすればよいでしょうか。2 つのデータベース内の対応する製品を個別に照会する必要があります。時間順に並べ替えるにはどうすればよいでしょうか? 2 つのライブラリで「購入したアイテム」をすべて見つけて、アプリケーションで結合します。ページングをどう処理するか？キーワードクエリをどう処理するか？これらのことをプログラマーに任せると大変なことになるので、Xingdian が Taobao のアーキテクチャで最初に取り組んだのは、この問題を解決することでした。彼は、Taobao の Oracle 時代に使用されてきたデータベース ルーティング フレームワーク DBRoute を作成しました。その後、ビジネスが発展するにつれて、このデータベース パーティショニングの 2 番目の目的である災害復旧は達成されなくなりました。評価、苦情、レポート、お気に入り、マイタオバオなど、多くの領域は DB1 と DB2 に同時に接続する必要があります。いずれかのデータベースに障害が発生すると、Web サイト全体に障害が発生します。

前の記事で述べたように、EJB の採用は実際には Sun のエンジニアとの妥協の結果でした。彼らが去った後、EJB は徐々に無視されるようになりました。 2005 年と 2006 年に、Spring は非常に人気を博しました。Spring は、EJB のファクトリ モードを Spring のリフレクション (IoC) モードに置き換えただけで、システム全体の多くのコードが合理化されました。

前回の記事でも触れましたが、データベースへの負担を軽減し、検索の効率を上げるために、検索エンジンを導入しました。データ量は増え続け、2005年には商品数は1,663万点、PVは8,931万点、登録会員数は1,390万人に達しました。これにより、データとストレージに大きな負担がかかり、データ量が大きくなるほどパフォーマンスが低下しました。システムのパフォーマンスを向上させる他の方法はありますか? キャッシュや CDN (コンテンツ配信ネットワーク) など、使用できるトリックがいくつかあるはずです。

9,000 万回のアクセスのうち、製品詳細ページへのアクセスが何件あるか想像できますか? このページにアクセスすると、すべてのデータは読み取り専用になります (すべてデータベースから読み取られ、データベースに書き込まれることはありません)。これらの読み取り操作がデータベースからメモリに移動されると、データベースにとってどれほどありがたいことでしょう。当時、私たちのアーキテクトである Duolong は、Berkeley DB をベースにしたオープンソースのキャッシュ システムを見つけ、めったに変更されない読み取り専用情報を大量にそこに保存しました。実は、当初のキャッシュ システムは比較的弱く、商品の詳細をすべてキャッシュに入れていませんでした。まず販売者の情報を入れ、次に商品の属性を入れていました。商品の詳細フィールドが大きすぎて収まりきらなかったのです。商品詳細といえば、この分野はかなり恐ろしいです。ある人が計算したところによると、Taobaoの印刷された商品詳細の平均長さは5メートルです。実際、システムのどこに置いても人気がありません。私が Taobao に入社してプロジェクト マネージャーとして最初に取り組んだプロジェクトは、商品の詳細を商品テーブルから移動することだったことをはっきり覚えています。このフィールドは大きすぎます。商品情報を照会する場合、詳細を表示する必要のない人が多くいます。商品価格や送料と同じテーブルに配置されているため、テーブル全体の照会速度が低下します。 2005 年に、製品の詳細をデータベース内の別のテーブルに入れました。その後、この大きなフィールドはデータベースから削除され、データベースは再び有用になりました。

今のところ、商品詳細ページ全体がキャッシュされています。鋭い目を持つ読者は、商品詳細がすべて「読み取り専用」の情報ではないことに気付くかもしれません。このページには「ビュー」と呼ばれる情報があります。この数値は、ページが更新されるたびにデータベースに「書き込まれます」。この高頻度でリアルタイムに更新されるデータはキャッシュできるのでしょうか。キャッシュを使用しない場合、1 日に数十億回の書き込みが行われるデータベースはどうなるのでしょうか。間違いなくクラッシュします。どうすればいいでしょうか？ 親愛なる...まだお答えできません（下の画像は広告ではなく、ページビューデータがどこにあるかを示すためのものです）

CDN の作業は比較的独立しており、他のシステムと同様に、当初は商用システムも採用していました。その後、トラフィックが増加するにつれて、商用システムではワークロードを維持できなくなったため、LVS の創設者である張文松博士がチームを率いて Taobao 独自の CDN ネットワークを構築しました。この記事の紹介で、タオバオのCDNシステムは800Gbps以上のトラフィックをサポートしていると述べました。比較のために、CDNを専門とする国内上場企業であるChinaCacheの紹介を見てみましょう。「ChinaCacheは中国初の専門CDNサービスプロバイダーであり、顧客にネットワークコンテンツの迅速な配信ソリューションをフルレンジで提供しています。情報産業部からライセンスを受けた最初のCDNサービスプロバイダーとして、ChinaCacheは現在、全国50以上の大中都市に300近くのノードを持ち、ネットワーク処理能力は合計500Gbpsを超えています。そのCDNネットワークは、中国電信、中国網通、中国移動、中国聯通、中国鉄道、中国教育研究ネットワークなどの大手事業者をカバーしています。」 - このように、世界でもトップクラスのCDNを誇るタオバオの強みを見ることができます。さらに、CDN には多数のサーバーが必要なため、大量のエネルギーを消費します (どれくらいでしょうか? 2 年前に計算したところ、Taobao での取引で消費される電力は卵 4 個を調理するのに十分な量であることがわかりました)。過去2年間、張文松氏のチームは低電力サーバーの研究に取り組んでおり、グリーンコンピューティングの分野で多くの先駆的な研究を行ってきました。 Taobao CDN の開発については、特別な章を割いて説明する必要があります。一足先に知りたい場合は、著者の張文松氏へのインタビューをお読みください: http://qing.weibo.com/1866752224/6f4460e033000jme.html

キャッシュを初めて使用した当時を振り返ると、私はまだ初心者で、データベースの内容が更新されたときにキャッシュ システムに通知するのを忘れるという典型的なミスを頻繁に犯していました。その結果、テスト時に、変更したデータがページ上で変更されていないことがわかりました。その後、いくつかのページのコードに取り組んでいて、CSS と JS を修正していたところ、ユーザーがローカルにキャッシュした情報が更新されず、ページが乱雑になってしまいました。フォーラムで誰かがこのことについて話していたので、Ctrl + F5 でページを更新し、スクリプト ファイル名をすばやく変更してページを再公開するように指示しました。 ctrl+F5の使い方を学んだメンバーは私をとても尊敬していましたが、私は恥ずかしく、恥ずかしい思いをしました。

技術の発展には自然に起こるものもあれば、予期せず起こるものもあります。 2007 年までに、当社はすでに数百台のアプリケーション サーバーを所有していましたが、それらのサーバー上の Java アプリケーション サーバーは WebLogic でした。これは非常に高価で、サーバー自体よりもさらに高価でした。 Duolong はしばらくの間、JBoss を研究し、WebLogic を置き換えれば多額の費用を節約できると主張しました。その年、Lao Ma は最初の「Nethero カンファレンス」を開催しました。このカンファレンスに参加したヒーローの 1 人は、前述の Zhang Wensong でした。また、JBoss チームで働いていたヒーローもいました。このヒーローも引き留めておいたので、JBoss の使用にさらに自信を持つことができました。

データベースのパーティショニング、EJB の放棄、Spring の導入、キャッシュの追加、CDN の追加、オープンソースの Jboss の採用など、これらのさまざまな変更は、従うべきルールがないように見えますが、実際にはすべて容量の増加、パフォーマンスの向上、コストの節約のために行われています。これらはメジャーバージョンの変更ではないため、バージョン 2.1 と呼びましょう。構成の観点から、このバージョンには 3 つの脚があります。はるかに安定しているのではないでしょうか。

アーキテクチャ図は次のとおりです。

次回のエピソードのプレビュー: クリエイティブ テクノロジー分散ファイル システム TFS、分散 KV キャッシュ タイル、検索エンジンのアップグレード

オリジナルURL: http://blog.sina.com.cn/s/blog_633219970100ybfx.html?tj=1

タオバオの技術発展レビュー（IV）：Java時代の復活

原題：タオバオの技術発展レビュー（V）Java時代：盤石

キーワード: 淘宝網、インターネット技術、技術開発、開発、Java、時代、堅固、読者、ウェブマスター、ウェブサイト、ウェブサイトの宣伝、金儲け