Hoofdcategorieën
Device Settings

Gerucht over databaseproblemen Google

Door Matthijs Abma, maandag 16 juni 2003 21:10
Bron: ZDNet.nl, submitter: RobbertC, views: 874

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:

Google logoAnonieme 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.
Volgende 21:54 Sun Microsystems in zwaar weer
Vorige 20:54 Broadcom introduceert all-in-one netwerkprocessor
Advertentie

Reacties

«  1  2  3  4  »

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.

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 :P

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

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

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

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

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

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....

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.

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.

erg speculatief verhaal is dit. en volgens mij weten ze bij google genoeg van databases om dit probleem te voorzien, dus: niet te hebben.
64-bits databases zijn bepaald niet schaars...
broodje aap imho.

wel knap trouwens dat ze de 4GB grens gepasseerd zijn :)

't zijn geen bytes :) maar idd, dat zijn me een partij urls :P

je hebt gelijk.. 4gurls dan :)

gurls??!? hoor ik dat er gurls rondlopen daar? :P

Het is precies het aantal beschikbare IPv4 adressen (2^32). Met een truc als virtual name hosting, gaat die 1:1 relatie natuurlijk niet meer op.
Ik weet niet wat voor database ze als backend draaien, maar ik kan me niet voorstellen dat het een groot probleem wordt om naar een ID van 64 of 128 bit te gaan...

Niks met virtual hosting te maken dat is maar een klein stukje denk ik. Bij XS4All heb je onder www. xs4all.nl vele homepages /~username. Dat is een ip adres met vele duizenden homepages. Dat tikt denk ik veel zwaarder aan dan virtual hosting.

Anonieme experts en rekenwonders voorspellen Google een weinig florissante toekomst.

Ik denk dat Google zelf ook wel heeft ingezien dat dit magische getal een probleem zou gaan veroorzaken (als de geruchten waar zijn).

Dus zal Google echt wel ver van tevoren naar een oplossing hebben gezocht, ze gaan echt niet afwachten tot de database "vol" zit om zo Google om zeep te helpen, zonder goede database heeft een zoekmachine geen bestaandsrecht.

Wat die oplossing is weet ik niet, misschien een aangepast design of zelfs een compleet nieuwe manier. Dat kunnen ze in de achtergrond hebben gedaan om het te testen en nu het tijdstip bijna gekomen is kunnen ze het gaan inzetten.

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 ? :P bwaha

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

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.

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...

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

zou dat mischien de reden zijn waarom een site van mijnog steeds niet in de zoek DB voorkomt ? meta tags zijn goed en site is 2 maanden geleden aangemeld...

google doet (gelukkig) niet aan metatags..
en als er geen enkele site naar jou linkt, dan zal je onderaan de lijst verschijnen

Ik geloof hier echt helemaal niets van. Als het een unieke identifier is, is het dus een primaire sleutel. Als deze primaire sleutel niet meer mag worden dan 4 miljard (afgerond), dan gebruiken ze een database die niet erg bij de tijd is. Ik weet niet welke database-software erachter zit (heb ik nooit terug kunnen vinden op hun site; hmz, hier staat dat ze MySQL gebruiken ?!?), maar vier miljard primaire sleutels in één tabel is tegenwoordig een 'makkie'. Niet de grote van je sleutel is de limiet, maar de ruimte op je schijf (en die is tegenwoordig nagenoeg oneindig).

Denk je nou echt dat ze op een bepaald type database draaien? Ze hebben waarschijnlijk gewoon zelf het systeem van de grond af aan opgebouwd. Als ik 4 miljard paginas wil indexen pak ik daar geen SQL database voor. Google ook niet lijkt me zo.

Waarom niet? Databases zijn er toch voor gemaakt om gegevens in op te slaan. Of dat nou NAW-gegevens zijn of URLs met beschrijving, dat maakt toch niets uit; het blijven gegevens. :?

SQL is heel general purpose.. ze zouden inderdaad niet zo slim bezig zijn als ze google laten draaien op een SQL dbms..

als je zelf iets schrijft dat dedicated voor deze taak is ontworpen, dan zal je dbms mogelijk een factor 3 (natte vinger werk) sneller zijn dan de snelste "kant en klaar"-dbms

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. :)

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.

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..

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.

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.

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.

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...

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

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.

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

Als ze een check deden op alle url's waarvan een 404 ofzo terug komt, zou dat al wat ruimte kunnen schelen.

Weet je wat ook een handigheidje van Google is..
Je kunt in de cache van google terug kijken op een pagina die verdwenen is, en dit kan verdomd handig zijn.. Dus laat die pagina's met 404 d'r maar in zitten.. Het is gewoon een stukje service van hun kant..... En die service vind ik persoonlijk super!. Je kunt veel dingen terug halen die niet meer op een server staan of waar de server compleet van verdenen is..

klopt, dat is een van de meest ondergewaardeerde features van Google, IMHO.
«  1  2  3  4  »

Op dit item kan niet meer gereageerd worden.

Volgende 21:54 Sun Microsystems in zwaar weer
Vorige 20:54 Broadcom introduceert all-in-one netwerkprocessor
VNU Media logo Hosted by True

© 1998 - 2012 Tweakers.net B.V. - Alle rechten voorbehouden - Contact - Jouw privacy - Algemene Voorwaarden

Uitgever van:

Website van het jaar 2011