kml:

thinkupstudio:

thinkupstudio:

gkojax:

Googleは1つの検索クエリーに対し、1000台のマシンを使って0.2秒で処理している - GIGAZINE
検索したいフレーズを入れれば即座に結果を返してくれるあのGoogleですが、その1フレーズを処理するため、実に1000台ものサーバを使い、わずか0.2秒で超高速処理していることが、WSDM 2009にて明らかになりました。基調講演を行ったのはGoogleフェローであるJeff Dean氏で、2008年6月における「Google I/O」カンファレンスでは700~1000台のサーバで0.5秒以下の時間がかかると言っていましたが、今回の講演ではユーザーの気づかないところでGoogleは着実に進化し続けていることも明らかになりました。
知られざるGoogleの裏側の最新情報は以下から。
 Geeking with Greg: Jeff Dean keynote at WSDM 2009
Single Google Query uses 1000 Machines in 0.2 seconds
まず1999年から2009年現在までにおけるこの10年間のGoogleの成長のわかりやすい例から。
・今はかつてよりも1000倍のクエリーを処理している ・マシンの処理能力は1000倍になった ・以前は1000ミリセカンドかかっていたが今は200ミリセカンドまで高速化された ・ページのアップデート検知に至っては10000倍に達しており、最初は反映まで数ヶ月かかっていたが今はページが更新されて数分で反映される
また、Jeff Dean氏によると、Googleは検索インデックスを数年前にすべてメモリ上に置いており、検索しようとしている人にほとんど瞬間的に検索結果を見せるため、各クエリーごとに以前のような2、3ダースのマシンではなく、数千台のマシンが連携して処理しているとしています。
Googleはこの数年間に渡ってさまざまなインデックス圧縮技術を開発しており、解凍に必要とされる交替作業の数を最小化するためにポジションの4つのデルタを一まとめにしたフォーマット上で最後に解決したと話しています。
また、Googleは彼らのそのデータがディスクのどこに置かれているかにも注意を払っており、ハードディスクの中でもより高速にデータを読み出すことができるディスクの外周部にすぐに読み出す必要のあるデータを配置、ディスクの内周部にはコールドデータ(すぐに読み出す必要のない、読み出し頻度の低いデータのこと)や短いデータを置いているそうです。
また、通常サーバ用途においては、エラーを自分で訂正できる通常より高い価格のECCメモリを使うのに対し、Googleはノンパリティのメモリを使っているため、エラーから回復するためのプログラムを自作し、ディスクスケジューラも自作。Linuxのカーネルもニーズを満たすために何度も修正を加えてきたとのことです。
物理的なサーバについても、最初期はケース無しの自作サーバ、それから通常のラックに収めるようなサーバになったが、今はまたケース無しのカスタムサーバに戻っているとのこと。
これが最初の頃のサーバ
Jeff Dean氏いわく、Googleはこの10年間に7つのメジャーなリアーキテクチャ(再構築)をロールアウトしており、これらの変更はしばしば完全に異なるインデックスフォーマットやGFSやBigTableのようなまったく新しいストレージシステムになることもあったとのこと。これらすべてのロールアウトにおいて、Googleはもしうまくいかなかった場合には直ちにロールバックするということも行っていたそうです。いくつかのロールアウト時には新しいデータセンターでは新しいコードが動き、古いデータセンターでは古いコードが動きっぱなしで、データセンター間のトラフィックをスイッチすることもあったとのこと。
また、Googleは検索しているユーザーが気づかないような小さな変更と実験、新しいコードのテストを常に行っており、それらの実験はすばやく、かつ静かに行われるため、ユーザーは何が変わったか気づくことはできないだろうとしています。
言語の壁についても引き続きGoogleは取り組み続けており、単に1文を翻訳するためにマルチテラバイトモデルとなっているGoogleの機械翻訳システムが100万もの自動照合を行っているとのこと。Googleの目標は、あなたがどの言語を話すことに決めているかにかかわらず、出入りできるすべての言語で情報を得られるようにすることであるとしています。
(via petapeta)

kml:

thinkupstudio:

thinkupstudio:

gkojax:

Googleは1つの検索クエリーに対し、1000台のマシンを使って0.2秒で処理している - GIGAZINE

検索したいフレーズを入れれば即座に結果を返してくれるあのGoogleですが、その1フレーズを処理するため、実に1000台ものサーバを使い、わずか0.2秒で超高速処理していることが、WSDM 2009にて明らかになりました。基調講演を行ったのはGoogleフェローであるJeff Dean氏で、2008年6月における「Google I/O」カンファレンスでは700~1000台のサーバで0.5秒以下の時間がかかると言っていましたが、今回の講演ではユーザーの気づかないところでGoogleは着実に進化し続けていることも明らかになりました。

知られざるGoogleの裏側の最新情報は以下から。


Geeking with Greg: Jeff Dean keynote at WSDM 2009

Single Google Query uses 1000 Machines in 0.2 seconds

まず1999年から2009年現在までにおけるこの10年間のGoogleの成長のわかりやすい例から。

・今はかつてよりも1000倍のクエリーを処理している
・マシンの処理能力は1000倍になった
・以前は1000ミリセカンドかかっていたが今は200ミリセカンドまで高速化された
・ページのアップデート検知に至っては10000倍に達しており、最初は反映まで数ヶ月かかっていたが今はページが更新されて数分で反映される

また、Jeff Dean氏によると、Googleは検索インデックスを数年前にすべてメモリ上に置いており、検索しようとしている人にほとんど瞬間的に検索結果を見せるため、各クエリーごとに以前のような2、3ダースのマシンではなく、数千台のマシンが連携して処理しているとしています。

Googleはこの数年間に渡ってさまざまなインデックス圧縮技術を開発しており、解凍に必要とされる交替作業の数を最小化するためにポジションの4つのデルタを一まとめにしたフォーマット上で最後に解決したと話しています。

また、Googleは彼らのそのデータがディスクのどこに置かれているかにも注意を払っており、ハードディスクの中でもより高速にデータを読み出すことができるディスクの外周部にすぐに読み出す必要のあるデータを配置、ディスクの内周部にはコールドデータ(すぐに読み出す必要のない、読み出し頻度の低いデータのこと)や短いデータを置いているそうです。

また、通常サーバ用途においては、エラーを自分で訂正できる通常より高い価格のECCメモリを使うのに対し、Googleはノンパリティのメモリを使っているため、エラーから回復するためのプログラムを自作し、ディスクスケジューラも自作。Linuxのカーネルもニーズを満たすために何度も修正を加えてきたとのことです。

物理的なサーバについても、最初期はケース無しの自作サーバ、それから通常のラックに収めるようなサーバになったが、今はまたケース無しのカスタムサーバに戻っているとのこと。

これが最初の頃のサーバ

Jeff Dean氏いわく、Googleはこの10年間に7つのメジャーなリアーキテクチャ(再構築)をロールアウトしており、これらの変更はしばしば完全に異なるインデックスフォーマットやGFSやBigTableのようなまったく新しいストレージシステムになることもあったとのこと。これらすべてのロールアウトにおいて、Googleはもしうまくいかなかった場合には直ちにロールバックするということも行っていたそうです。いくつかのロールアウト時には新しいデータセンターでは新しいコードが動き、古いデータセンターでは古いコードが動きっぱなしで、データセンター間のトラフィックをスイッチすることもあったとのこと。

また、Googleは検索しているユーザーが気づかないような小さな変更と実験、新しいコードのテストを常に行っており、それらの実験はすばやく、かつ静かに行われるため、ユーザーは何が変わったか気づくことはできないだろうとしています。

言語の壁についても引き続きGoogleは取り組み続けており、単に1文を翻訳するためにマルチテラバイトモデルとなっているGoogleの機械翻訳システムが100万もの自動照合を行っているとのこと。Googleの目標は、あなたがどの言語を話すことに決めているかにかかわらず、出入りできるすべての言語で情報を得られるようにすることであるとしています。

(via petapeta)

185 notes

  1. westworld55 reblogged this from d-d-d and added:
    Geeking with Greg: Jeff Dean keynote at WSDM 2009
  2. macro55 reblogged this from ichikatyann
  3. karate-style reblogged this from budda
  4. crhg reblogged this from budda
  5. papertips reblogged this from stereo-graphica
  6. stereo-graphica reblogged this from ichikatyann
  7. ichikatyann reblogged this from damofujiki
  8. damofujiki reblogged this from exentrico
  9. invoke reblogged this from budda
  10. pingdommm reblogged this from budda
  11. budda reblogged this from skoei
  12. skoei reblogged this from ginzuna
  13. zibbs reblogged this from rock-the-baby
  14. kimi17 reblogged this from yukko
  15. surf319 reblogged this from kagurazakaundergroundresistance
  16. yurutime reblogged this from darylfranz
  17. nodoi reblogged this from kagurazakaundergroundresistance
  18. tabasou reblogged this from kens-notepad
  19. kens-notepad reblogged this from atm09td
  20. maumau-ru reblogged this from yukko
  21. exentrico reblogged this from superneet
  22. p704i reblogged this from darylfranz
  23. orekane reblogged this from ginzuna
  24. catlemutyration reblogged this from yukko
  25. mamemomonga reblogged this from yukko
  26. yukko reblogged this from s1100146pi314
  27. s1100146pi314 reblogged this from darylfranz
  28. joecoolz reblogged this from darylfranz
  29. seapomeranian reblogged this from atm09td
  30. motsuku reblogged this from himmelkei
  31. hakojiro reblogged this from rock-the-baby
  32. atm09td reblogged this from darylfranz
  33. superneet reblogged this from arkhamhpl
  34. arkhamhpl reblogged this from darylfranz
  35. himmelkei reblogged this from springdawn
  36. mononofu reblogged this from rock-the-baby
  37. springdawn reblogged this from syumari
  38. peroriroku reblogged this from ftnk