Gerucht over databaseproblemen Google

Sinds enkele dagen duiken er op het internet geruchten op dat de database van Google vol zou zijn, zo meldt ZDNet.nl. Het unieke identificatiegetal voor een URL in de Google-database bestaat uit vier bytes. Er kunnen dus maximaal 4.294.967.296 verschillende adressen worden opgeslagen. De geruchten dat deze grens bijna bereikt is, zijn gebaseerd op foutjes die ontstonden na het samenstellen van de maandelijkse Pagerank. Verschillende pagina's stonden ineens onverklaarbaar laag op deze lijst. Het is dus mogelijk dat niet alle URL's opgeslagen kunnen worden en dat de links op deze pagina's ook niet meetellen bij het bepalen van de Pagerank. Dit zou de oorzaak kunnen zijn van de lage positie van de verschillende websites:

Anonieme experts en rekenwonders voorspellen Google een weinig florissante toekomst. De database van de zoekmachine zou vol zitten en nieuwe websites kunnen niet meer opgenomen worden. En mocht er nog ruimte over zijn, dan zal deze binnenkort vollopen.

Reacties (103)

[Anoniem: 18226]

Dit is toch gewoon kwestie van de code aan passen zodat ze meer adressen kunnen opslaan?

Dan lijkt mij dat Google nog wel ff op nr 1 blijft staan als beste search engine.

[bitflusher]

code aanpassen is een ding, maar je database omzetten zeker zo'n grote als google is ff iets anders. ik denk niet dat elke dba-er daar zomaar zijn vingers aan wil branden

[bitflusher]

he nou ben ik misschien gek maar als je naar google toe gaat zie je onderaan dit staan:

©2003 Google - Zoekt in 3,083,324,652 webpagina's

nou ben ik misschine geen rekenwonder maar volgens mij kunnen ze er zo nog een derde bij gooien

[Nick|IA]

Bovendien worden bij de webpagina's niet de webdocumenten als PDF's en DOC's meegeteld, en vergeet je de afbeeldingen, nieuws e.d.

[Anoniem: 75573]

Niet noodzakelijk. Als ze idd een autonumber gebruiken dan is het mogelijk dat ze in de loop der jaren ondertussen 1/4 van hun entries hebben opgekuist zodat ze het maximum van hun primary keys wel bereikt hebben. Dat wil dus zeggen dat er in totaal ooit 4 miljard entries waren maar door de slechte er uit te filteren, schieten er nog 3 miljard over (bijvoorbeeld).

[TheOneLLama]

Denken er dan echt zoveel mensen hier dat Google een PHP scriptje met MySQL database en "autonummering" is?

Je gaat het hele internet toch niet indexeren in een SQL database!!

[Atmosphere]

Als het goed is hebben ze een eigen Web-server (gebasserd op Apache/TomCat, en eigen DB-servertje (gebasserd op MySQL)

[Anoniem: 46747]

Iedereen die ook maar iets van FullText indexering en zoeken weet die zal je zeggen dat de "zoek" database van google zeer waarschijnlijk niet in SQL gerealiseerd is. Jouw zoek-opdracht aan google word niet in een 1 of andere super SQL-query vertaald ofzo...

Maar voor pure dataopslag of andere backend-databases zou google best eens een sql server kunnen gebruiken...

[PolarBear]

MySQL, ze hadden toch zeker wel voor een echte DB gekozen..

[Anoniem: 55396]

nja dat zou geen probleem moeten zijn; opschonen en hernummeren hoeft een database niet voor down.

dus ik neem aan dat ze dat wel regelmatig doen.

[EfBe]

Die database is so intens groot, die gebruikt sowieso 64bit addresses (het rdbms). Als je dat al aan ziet komen zie je een key van 4 bytes die volloopt ook aankomen. Als je 6000 servers hebt staan dan weet je echt wel dat 4bytes voor een unique key niet echt volstaat.

En het kan aan mij liggen, maar volgens mij is het gebruiken van een autonumber field als id voor een url bepaald niet je van het qua database design. autonumber fields (of sequenced fields) zijn voor de echte SQL cracks niet echt de 1e keus voor unique keys (lees Joe Celko's boeken) en zeker niet wanneer je een unieke identifier voor een page al beschikbaar hebt: de URL.

iets voor de zwartkijkers: interview met een van de google oprichters: http://www.linuxgazette.com/issue59/correa.html

Ik heb niet echt het idee dat deze meneer een overlopende 4-byte ID over het hoofd zou zien, laat staan zn R&D staff.

[Anoniem: 75573]

Ik dacht dat het wel een stuk interessanter was om een integer als primary key te hebben ipv een karakterveld dat in principe een paar honderd tekens lang kan zijn.
Wat voor redenen geeft die Joe dan wel? Ik ga me mezelf niet een SQL-expert noemen, verre van, maar ik ben er wel dagelijks mee bezig en een autonumber is verdomd handig als je niet met gedistribueerde systemen zit waar replicaties aan te pas komen.

[EfBe]

Autonumber fields geven niet een unieke ID aan de entiteit, wel in de tabel maar niet op het semantische vlak. Autonumber fields lopen ook altijd door, ookal delete je er een paar (behalve in een paar brakke databases) dus, heb je 1, 2, en 3 en je delete 2 dan is de volgende nieuwe niet 2 maar 4. Beter is om iets unieks dat al in de entiteit zit te gebruiken als key. En een number als key zegt niets voor performance, want het zoeken gaat toch op keyword - rank basis, waarbij daarna pas de URLs worden gezocht. Je zoekt dus in andere data dan je url. Maar je kunt ook een hash nemen van de url, ik noem maar iets. Autonumbers zijn leuk, maar er kleven grote nadelen aan.

[Anoniem: 75573]

Ik ben er mij volledig van bewust dat er gaten ontstaan maar ik ben er vrij sterk van overtuigd dat een integer als PK (niet noodzakelijk een autonumber) een stuk performanter is dan een een karakterveld van een paar honderd tekens; hashing tabel of niet.

[ATS]

Ja, een autonummer veld in je huis-tuin-en-keuken general-purpose DBMS wel ja... Ik denk dat ze bij Google wel zelf een speciale database neergezet hebben. Lijkt me dat je dat efficiënter kan krijgen dan een GP dbms. Dan is het ook niet zo moeilijk om dat 'autonummer probleem' op te lossen: gewoon de gedelete keys in een pool gooien die gebruikt wordt door de code die een nieuwe key moet aanleveren, en je kan ze hergebruiken. Ik zie het probleem niet.

[Anoniem: 2141]

met autonummering (auto_increment of sequences) heb je altijd gaten (na het verwijderen van records).. waardoor je veeeel te snel op je maximum zit
met de url als primary key zal je nooit een maximum bereiken..

nadeel is wel dat een string compare in de regel langer duurt dan een numerieke vergelijking..

[Nick|IA]

Voor de goede orde: Google heeft inmiddels 15.000 servers, verspreid over meerdere serverparken in (volgens mij) meerdere landen. Bezoekers alleen zorgen voor 230 miljoen queries per dag...

[Munters]

Oei, dan krijgen we binenkort een nieuw bericht uit die anonieme bronnen:
2^32 / 230 miljoen = binnen 18 dagen zal google ophouden te bestaan....

[Anoniem: 55396]

sequenced fields zijn *de* oplossing als je de ruimte hebt om alle mogelijke keys linear op te slaan; iets dat Google makkelijk kan hebben. Dan kan je uit een key direct de computer/harddisk bepalen waar de data opstaat.

Met de URL als PK kan dat niet; dat zou dan ook een tragere situatie opleveren.

Wie die Joe ook is, voor dit soort applicaties kan een sequenced field goed de snelste oplossing zijn.

[TheOneLLama]

Als ze al iets draaien wat je een RDBMS kan noemen, wat ik toch zeer betwijfel.

[Anoniem: 5721]

Anonieme experts voorspellen het einde van Google... sja, zeker anonieme experts van andere zoekmachines, die de superioriteit van Google niet kunnen hebben, en dan maar met modder gaan gooien? Want waarom zou zoiets niet op te lossen zijn en meteen 'het einde' van Google betekenen? Naast het feit dat er inderdaad genoeg eigen experts bij Google in dienst zijn die zoiets echt wel hadden zien aankomen...

[Marcelloz]

Ik zal het maar toegeven: die anonieme expert dat was ik

[Anoniem: 9473]

Als je op zo'n cache linkje wijst dan staat er een ID achtige string bestaande uit ongeveer 12 alfanumerieke tekens wat dus ongeveer 36^12 verschillende ID's geeft.

Tenzij google intern dubbele caches gebruikt, lijkt me het gerucht onzin. Ook zou ik het gek vinden dat je databases van gecachede paginas groter zou zijn dan de database van webpaginas.

[Mardoek69]

Neem daar nog bij dat google verschil maakt in hoofdletters en kleine letters, kom je dus aan 72^12 dat is :19,408,409,961,765,342,806,016 Kortom een hele hoop. Als ze zo'n ID al gebruiken voor de Cache ID, wat voor ID's worden er verder dan nog gebruikt. Plus dat dit veld een char veld is kan het dus zijn dat het ook uit te breiden is(b.v.) 50 velden waar er nu nog maar 12 van gebruikt worden(nu alleen spaties die gestript worden)

[Anoniem: 2141]

tijd voor opterons -> snelle 64 bit unsigned integers -> 18.446.744.073.709.551.616 urls

[pven]

Op Geek.com stond ooit een bericht dat het geen Itaniums worden, dus Opterons is blijkbaar toch een serieuze optie.

[jesternl]

Sterker nog, dat bericht stond zelfs op Tweakers
Tweakers.net artikel

[_Thanatos_]

Uhm, de P1 kan al met 64-bit integers omgaan... het is alleen van de compiler afhankelijk of hier gebruik van gemaakt wordt.

[SG]

Yep maar 64bitters doen dat sneller in één slag ipv in twee delen met overhead.
64bitters zijn met 64bit integers veel sneller.

[Anoniem: 58853]

Wie zegt dat Google op Intel Procs draait??? Lijkt me zo dat dat die DB draait op een multi-proc Unix doos. En dan waarschijnlijk een dikke Ultra-Sparc of hoger....

[Anoniem: 65268]

Google zegt dat zelf in dit artikel: http://www.computer.org/micro/mi2003/m2022.pdf

[Munters]

Google draait echt niet op een Sun hoor.
Google is zo groot dat draait sowieso distributed. En als je dan toch naar distributed moet, dan neem je de goedkoopste oplossing -> google draait dus op ca 15000 linux/x86 servers.
Is gewoon goedkoper (en eenvoudiger op te schalen) dan 250 superdome o.i.d. servers.

En die servers zijn trouwens ook niet allemaal gelijk. Je hebt natuurlijk de index/pagerank servers om de database op te bouwen en het systeem waar je zoekopdracht doorheen gaat.

En jouw zoekopdracht wordt ook al niet door 1 server afgehandeld. Iedere server heeft zijn eigen beperkte taak. Als een server documenten gevonden heeft bij jouw zoekopdracht, doet deze er verder niets mee, maar stuurt het resultaat intern door. Daar neemt een "snippet" server het over, en haalt een aantal relevante stukjes tekst uit de documenten om dit aan jouw te presenteren.

[voodooless]

Google draait gewoon op kleine goedkope x86 machines, als er een uitvalt kan die zonder dat er data verlogen gaat worden uitgewisseld, en dan hobbelt het rusig weer verder.

Het probleem is niet de architectuur van de machine, maar de opbouw van de tabellen. het ID van de URL is gewoon maar 4 bytes groot. Ze moeten er dus wat bytes achterplakken, dat houd echter in dat alle records en tabelen waar dit ID in voorkomt, bijgewerkt moeten worden, en dat is een gigantische klus.

[waslijn]

Anonieme experts en rekenwonders voorspellen Google een weinig florissante toekomst.

Haha, Google is opgericht door een tweetal experts op wiskunde gebied. Het hele bedrijf draait op het optimaliseren en perfect laten draaien van enorm grote databases en zoekmachines en dan zou dit een groot probleem vormen . Denk dat dit erg wilde speculaties zijn en dat die zogenaamde experts de plank volledig misslaan.

[Anoniem: 63944]

Als je wat meer wilt weten over de zoekmachine B-): toevallig afgelopen zaterdag volkskrant magazine een 5-tal pagina's over google en zijn oprichters (die er overigens nog steeds werken). Mijn conclusie nav dit (niet technische) artikel: ze programmeren zelf een database met alles erop en eraan, zoals velen van jullie al suggereren.

[Sjaaky]

Voor iedereen die meer wil weten over de inner workings van Google:The Anatomy of a Large-Scale Hypertextual Web Search Engine.
Ik zal alvast verklappen dat ze geen standaard dbms van de plank hebben gepakt.

edit:
Oh dat was al bekend, maar ik had slecht tot reactie 50 gelezen

[Anoniem: 2141]

Anonieme experts en rekenwonders voorspellen Google een weinig florissante toekomst.

wat .. ontzettend .. sneu klinkt dat..

zijn zeker de "anonieme experts" en "rekenwonders" (wonderen dacht ik, magoe ?) van ZDNet.nl ? bwaha

[memphis]

mijn idee, Google staat natuurlijk al een tijdje onder druk van de andere concurenten betreffende de zoekmethodes enzo. Het zou mij niets verbazen dat het een vorm van zwartmakerij is.

[cyble]

gewoon 2 editors van t.net: "tga denk nie goe" , de ander: "neuh denk 't ook nie" de editor noteerd: "Anonieme experts en rekenwonders..."