No je to trošku zvláštní, že jim to takhle umřelo. Upřímně řečeno si myslím že to asi moc nezvládli. Seznam používá FreeBSD a Debian pak hodně MySQL databázi. Otázkou je jakou verzi. Starší verze byli dost háklivé na výpadky (to ani souborový systém s žurnálem nezachrání - jaká databáze není háklivá na výpadek energie :) neznám). Chyba byla asi v tom že nedošlo k řízenému shutdownu na serverech.
Jenom se musím pochlubit že mám také server v TTC a ten vydržel, jeho uptime je stále nezměněn. Takže někdo umí a někdo ne.
Ale nezávidím to těm deseti technikům to asi muselo bejt hodně ošklivý. Tlak ze všech stran ať to funguje.
Každé kolečko se nakonec poláme i kdyby bylo sebelepší.
A že by to seznam nepřežil :) toho bych se nebál i kdyby
to nefungovalo dva, tři dni tak se stejně nic nezmění.
No na všechno :)
2x IDE disky se používají v té jejich server farmě na vyhledávání prostě www.google.com search jede na IDE diskách
cca 12 datacenter spojených 10Gbit linkama rozsypaných po světě
No je tam dost šílenej systém replikace dat, kterej sem nepochopil. Pokud někdo ví sem jedno ucho, ale ta matematika je pro mě asi nezvladatelná :)
Příjde vám google amatérské? Všechno není jenom o HW
MySQL(InnoBase) používají asi na nějaké ty doprovodné služby (podrobněji to nevím jenom vím že je uváděné jako používaný software)
Vyhledávat v MySQL samozřejmě nejde... ale to ani v ORACLE, ten je totiž ještě pomalejší.
Takže to používají na data, která mohou snadno nahradit :-). Když jeden počítač umře, mají dalších deset. Když umře všech deset tak to znova naindexují z Internetu. To je trochu jiná situace.
Mají to strašně složitý :(
Google je v podstatě takovej skynet :)
Je to nová filosofie úplně odlišná od všech ostatních
V jejich případě nezáleží na hardware, ale na síle myšlenky,
kterou museli velmi dobře zaplatit.
Úplně unikátní je sítový souborový systém, který se replikuje mezi všechny servery v síti (proto ty 10Gbit spojení)
Výsledky vyhledávání se skládají z fragmentů dat uložených v datacentru tedy cca 10000 serverů.
Když je v tom integrován gmail tak to musí být asi hodně složitý a žádné informace se neztrácejí
Muzete mi rici jake diskove pole je pripojeno ke kazdemu serveru? Kdyz je ten FS replikovan mezi vsechny servery?-) Co takhle si to nejprve nastudovat... Google na to ma ofic. technicky dokument, ktery je verejne pristupny.
Trochu je to shrnuto zde http://en.wikipedia.org/wiki/Google_platform, pokud o to máte opravdu hlubší zájem a nechcete to jen takto povrchně, projděte si odkazované články nebo si zkuste takové články najít, je jich na webu docela dost a v každém se dozvíte o pár zajímavých informací více. Vždy to ale bude stav techniky, který měl Google před nějakou dobou, protože datacentra rostou jako houby po dešti a přeci jen - Google rád mluví a je rád vidět v médiích, ale to podstatné si pečlivě střeží. Neskutečná je třeba i ta vypilovanost uložení těch mnoha tun HW , např. má Google dokonce patent na takové jednoduché uložení/vedení ethernet kabelů, aby nepřekážely a přepojení/výměna zabrala co nejméně času [US pat. 6,870,095], zkrátka přemýšlí se tam na každém kroku o hodně víc než ve firmách, které jen tupě kopírují.
Tak a teď si srovnejmě kolik lidí pracuje na GFS a kolik na aplikaci Centra a popřemýšlejte o tom jak by vadalo srovnání rizik, které podstupuje Google a která Centrum.
A jeste jedna dulezita vec: Stejne nad temi daty musi byt nejaka aplikace, ktera je spravuje (viz moje odpoved vyse), takze pouzitim diskoveho pole se tem rizikum nevyhnete.
Par tisic konkurentnich modifikacnich operaci nebo pouze read-only? Mozna byste se divil, jak rychle dochazi MySQL dech pri opravdove praci nad SQL bazi...
Myslím že je škoda se dohadovat o tom jestli MySQL je horší než nějaké jiné komerční produkty. Sám mám 1TB dat v MySQL a 30GB v ORACLE a rychlejší se jeví MySQL. Dokonce jsem zažil jak chybně zvolený dotaz úplně zmrazí ORACLE (CPU 100%) odezva ostatních tablespace otřesná. MySQL bezproblémů odbaví dotaz v jiné databázi (zátěž CPU cca 80%)
Místo standardní 0.001s to ale trvalo obrovských 0.7s
Oracle nicméně odpovídal v řádu mnoha sekund
Všechno je relativní...
No je pravda že používám verzi 5, ještě na okraj MySQL běží na kuse šrotu (P4 2.4GHz, IDE disk)
ORACLE má HP Proliant Xeon s 10k disky 1.5TB RAID5
Takže ani nesrovnávám rovnocenný hardware na tu workstajšnu bych se ORACLE bál spustit :)
Každopádně v něčem je rychlejší ORACLE v něčem MySQL
ORACLE se vyznačuje tím že je v něm ukrutnej bordel (jak starej hrad v karpatech) spousta věcí postrádá logiku
Přenositelnost mezi jednotlivými verzemi je bídná (fungovalo vám to v 9i? v 10g nebude :)
Nezkoušel někdo IBM DB2? Vypadá mnohem lépe, alespoň na můj první subjektivní dojem