[db alg.] Wat is de grootste database?

[_Thanatos_]

Ik zat me gister af te vragen, zou het ooit voorkomen dat een tabel in een database meer dan 4Gi (4.294.967.296) records zal bevatten? En wat voor situaties zou zoiets dan in voorkomen?

Ik ben nml een prog aant schrijven die (o.a.) de gehele inhoud van iedere gewenste mysql tabel moet kunnen weergeven en moet bij voorkeur natuurlijk ook met extreem grote tabellen om kunnen gaan.

De vraag is dus of mysql zoiets aankan, welke db-servers nog meer, en aan wat voor systemen ik dan moet denken.

Hoop dat het een beetje duidelijk is.

[Verwijderd]

Databases die zoiets ooit zouden kunnen halen? ... ik denk dat je dan aan aan databases van financiele instelling moet gaan denken zoals een bank.

MySQL is voor zoiets totaal niet geschikt.

[whoami]

Bedoel je dan 4.294.967.296 records per tabel of in de ganse databank?

Denk eens na hoe lang men er over zou doen om (bij normaal gebruik van de databank) tot 4 miljard records per tabel te komen?

Ik heb nog een tijdje bij een financiele instelling gewerkt, en de gegevens in de databank namen daar toen tussen de 2 en de 3 gigabyte in beslag. (En dat zijn dus nog geen 2 miljard records)

[raptorix]

Databases die bijvoorbeeld geografisch/astronomische data bevatten komen wel eens aan dat soort getallen.

[corani]

Misschien zoiets als terraserver? Met de hele aarde in satallietfoto's, zoeken op postcode, plaatsnaam, etc..

offtopic:
_Tanatos_, wie is dat popje in je icon?

edit: Hartelijk dank... dan moet ik verder zoeken

[_Thanatos_]

Ik bedoel dus meer dan 4Gi records in één tabel.

whoami: 2 miljard records in 2-3 gigabytes? knap, want afzonderlijke records zijn meestal wel een paar honderd bytes.

Ik heb gister nog wel een mysql tabelletje gemaakt met alleen een auto_increment kolom, maar bij de 134 miljoen records ben ik maar gestopt met inserten. De database was tot 4,13GB gegroeid dus ik zou het toch niet gaan halen

offtopic:
corani: Geen flauw id, maar hier staat het orgineel

[Verwijderd]

belastingdienst heeft de grootste volgens mij

[kvdveer]

_Thanatos_ schreef op 17 november 2002 @ 18:13:
whoami: 2 miljard records in 2-3 gigabytes? knap, want afzonderlijke records zijn meestal wel een paar honderd bytes.

Lezen is ook een vak zeg... (heb je die ontkenning over het hoofd gezien?)

_Thanatos_ schreef op 17 november 2002 @ 18:13:Ik heb gister nog wel een mysql tabelletje gemaakt met alleen een auto_increment kolom, maar bij de 134 miljoen records ben ik maar gestopt met inserten. De database was tot 4,13GB gegroeid dus ik zou het toch niet gaan halen

Handmatig zul je het inderdaad niet halen. Veel wetenschappelijke projecten hebben dit soort databases, maar die gebruiken geen SQL databases meer omdat dat toch weinig waarde heeft. Alleen voor het berekenen van een gemidelde ben je op 1 ghz al snel een paar seconden bezig namelijk. Als je alle SQL overhead nog bij optelt wordt dat een beetje onhandelbaar.

Mysql kan theoretisch oneindig veel records aan, maar op een gegeven moment zul je dan zonder indexen en primary keys moeten gaan werken: die zijn namelijk wèl gelimiteerd.

[chaser]

ik heb totaal geen verstand van databases maar ik moest gelijk denken aan het echelon project van de amerikanen

Het zal aarschijnlijk nooit bekend worden maar daar zullen ze ook wel grote databases hebben

Aangezien ze daar inmens veel informatie verwerken

Nogmaals
Ik heb er totaal geen verstand van (databases dan)

[_Thanatos_]

"nog geen 2 miljard" komt over alsof het er net 1,8 miljard ofzo zijn. Vandaar.

Verder heb je idd wel een punt waar je zegt dat SQL nogal wat overhead geeft. Maar wie zegt dan ook dat het op een 1GHz bak gedraaid wordt. Ik denk dat als een database in de terabytes aan records loopt, zal het toch wel op een wat zwaardere server (of zelfs een cluster of supercomputer) draaien?

[whoami]

[nohtml]

_Thanatos_ schreef op 17 November 2002 @ 18:29:
"nog geen 2 miljard" komt over alsof het er net 1,8 miljard ofzo zijn. Vandaar.

Dat hangt er dus vanaf op welk woord je de klemtoon legt.
Wat ik bedoelde was niet 'net niet', maar dat je geen 2 milj. records hebt bij een databank van +/- 3 gb.

[whoami]

kvdveer schreef op 17 november 2002 @ 18:23:
[...]
Mysql kan theoretisch oneindig veel records aan, maar op een gegeven moment zul je dan zonder indexen en primary keys moeten gaan werken: die zijn namelijk wèl gelimiteerd.

Hoezo gelimiteerd? De enige limiet die ik kan bedenken op een PK is, als de range van het gebruikt datatype voor die PK 'op' is.

[jochemd]

Theoretische limiet voor een default PostgreSQL installatie is rond de 1.8 E+12 dacht ik.

[Slein]

Ik zou zeggen de database van het internet archief (http://www.archive.org/ , de "wayback machine"). 10 miljard webpagina's, zeggen ze zelf...
Een goeie tweede zou dan de db van Google zijn, het hele (halve?) internet in een database.

[_Thanatos_]

Maar wie zegt dat archive.org al die webpagina's in een database heeft gezet?

[Verwijderd]

Wat dacht je van de volgende databases:
- AirMiles Database...... Hoeveel records zouden daar per DAG alleen al bij komen??
- BEANET (Pinpas automaten in winkels) ..... Hoeveel pin transacties per dag zijn er denk je??

[Verwijderd]

DE grootste db van NL is die van de belastingdienst.

[_Thanatos_]

Beanet zou idd in de miljarden records kunnen lopen, maar alleen als ze alles eeuwig bewaren. Ik kan me voorstellen dat ze transacties niet langer dan 5 jaar bewaren, en dan wordt 4 miljard records wel lastig heb ik het idee... stel dat 8.000.000 mensen gemiddeld 5 keer per week een pin-transactie doen. dat vijf jaar lang. Dan zit je pas op 10,8 miljard. (Ja das meer dan 4 mrd, maar dan moet je dus wel 40 mln transacties per week halen, en dat gebeurd volgens mij never nooit niet...)

Maar ff wat anders dan, wat voor database server zouden ze gebruiken? Vast geen MySQL

[Pooh]

Er zijn wel grotere databases dan dat jullie hier noemen.
* PoohBear werkt bij een bedrijf dat aandelenbeurs-data levert. Een aandeel als microsoft of cisco wordt toch zo'n 10x per seconde verhandeld. Een volledige trade-history daarvan (van 10 jaar bijvoorbeeld) zou 10*3600*12(uur)*250(werkdagen)*10 = 1G aan records opleveren. Nu slaan wij zulke informatie inderdaad niet op (sommige van de grote bedrijven die ons data leveren wel, maar niet in een database... je kunt zulke informatie op cd bestellen), maar er lopen echt wel freaks (analisten die willen weten wat er op een bepaalde dag in 't verleden met een aandeel gebeurde) rond die zulke informatie graag zouden hebben. Op dit moment zijn daarvoor de technische mogelijkheden te beperkt, maar als de wet van Moore nog een paar jaar standhoudt, denk ik dat die 4G limiet echt te klein is.

Ik weet niet precies hoe groot onze (oracle) database is, 'k zal eens informeren.

edit: Even navragen leverde me de volgende informatie op:
-We hebben van ongeveer 2 miljoen instrumenten (aandelen, opties, indices, etcetera) informatie... de informatie per instrument verschilt nogal...
-De grootste tabel heeft ongeveer 1G aan records. (maar wordt vrijwel nooit gebruikt).
-De grootste gebruikte tabel heeft ongeveer 100M aan records

[PhoneTech]

Poohbear schreef op 18 november 2002 @ 15:03:
Er zijn wel grotere databases dan dat jullie hier noemen.
* PoohBear werkt bij een bedrijf dat aandelenbeurs-data levert. Een aandeel als microsoft of cisco wordt toch zo'n 10x per seconde verhandeld. Een volledige trade-history daarvan (van 10 jaar bijvoorbeeld) zou 10*3600*12(uur)*250(werkdagen)*10 = 1G aan records opleveren. Nu slaan wij zulke informatie inderdaad niet op (sommige van de grote bedrijven die ons data leveren wel, maar niet in een database... je kunt zulke informatie op cd bestellen), maar er lopen echt wel freaks (analisten die willen weten wat er op een bepaalde dag in 't verleden met een aandeel gebeurde) rond die zulke informatie graag zouden hebben. Op dit moment zijn daarvoor de technische mogelijkheden te beperkt, maar als de wet van Moore nog een paar jaar standhoudt, denk ik dat die 4G limiet echt te klein is.

Ik weet niet precies hoe groot onze (oracle) database is, 'k zal eens informeren.

edit: Even navragen leverde me de volgende informatie op:
-We hebben van ongeveer 2 miljoen instrumenten (aandelen, opties, indices, etcetera) informatie... de informatie per instrument verschilt nogal...
-De grootste tabel heeft ongeveer 1G aan records. (maar wordt vrijwel nooit gebruikt).
-De grootste gebruikte tabel heeft ongeveer 100M aan records

Op wat voor een computer draait dat? En zit de snelheid er nog een beetje in??

[Verwijderd]

volkomen onrelevant overigens, maar gezien de mate waarin ik en de mensen in mijn omgeving zie pinnen zie ik dit zeker wel gebeuren. Ik pin gemiddeld 3 keer per dag ofzo.

[JaQ]

Ik heb zelf aan een datawarehouse gewerkt binnen een verzekeringsbedrijf. Deze database was rond de 2.5 terrabyte. Dit was wel een Oracle database. Het leuke van Oracle is dat je je data in datafiles hebt staan en 1 tabel kan je verspreiden over meerdere datafiles. Voor zover ik weet is er dus geen maximale grote. Ik kan wel vertellen dat je heel en heel erg goed over indexes na moet gaan denken bij dermate grote databases. MySql zou in het geval van een dermate groot beest geen optie voor mij zijn. (1 tabel = 1 fysiek bestand als ik me niet vergis. Op de meeste filesystems heb je automagisch de 2 GB filelimiet, dus per tabel)

[_Thanatos_]

Maar hoeveel records heeft die database van 2,5TB dan? ik gok em op een record of 5-6 miljard?

Op de meeste filesystems heb je automagisch de 2 GB filelimiet, dus per tabel

Op de meeste filesystems die op een server gebruikt worden (Ext2,3 of NTFS) is de de bestandsgrootte praktisch onbeperkt (16EB geloof ik op NTFS v5).

[Annie]

_Thanatos_ schreef op 18 november 2002 @ 17:43:
Op de meeste filesystems die op een server gebruikt worden (Ext2,3 of NTFS) is de de bestandsgrootte praktisch onbeperkt (16EB geloof ik op NTFS v5).

Bij gebruik van raw partitions heb je hier toch ook geen last meer van?

_{als ik iets raars zeg dan brandt me maar af , ben niet zo'n serverkenner}

[jochemd]

DrFrankenstoner schreef op 18 November 2002 @ 17:29:
..
1 tabel = 1 fysiek bestand als ik me niet vergis.

Je vergist je.

[Verwijderd]

PhoneTechnician schreef op 18 November 2002 @ 16:36:
[...]


Op wat voor een computer draait dat? En zit de snelheid er nog een beetje in??

Tja de computer kan niet snel genoeg zijn wat dat betreft maar de vraag of beter gezegt het gewenste resultaat / antwoord uit de DB moet je goed stellen.

Een mooie passende quote is: "The query that dims the light."

Heb ik een keer van: van der Lans (DB-expert) meegekregen tijdens een lezing van hem.

[Database freak]

Denk bijvoorbeeld aan een database die alle pagerequests per visitor van een website logt. Ik denk b.v. aan de Microsoft site (daar doen ze dit nl dacht ik ook op SQL Server ) 1 mln visitors per dag 3 page request/user, 365 dagn per jaar = 1.095.000.000; binnen 4 jaar hebben ze jou aantal. Uitgaande van 100 bytes per record (mogelijk met integer foreign key velden), zou deze table 104Gb zijn.
Hoe een verzekeringsmaatschappij aan zo'n database kan komen (DrFrankenstoner Frankenstoner ) is mij een raadsel. Dat zou nl. betekennen dat ze daar 3 mln record per dag 365 dagen per jaar record in hun mainframes hebben moeten zitten ramellen voor 4 jaar lang! ( Of 40 jaar 365 dagen per jaar 300.000 records per dag; kan natuurlijk ook )

[NaliXL]

Verwijderd schreef op 18 November 2002 @ 23:06:
Een mooie passende quote is: "The query that dims the light."

Een beetje uitleg is hier misschien op zijn plaats? Query - Light... Ik zie het verband niet helemaal.....

[momania]

NaliXL schreef op 19 november 2002 @ 10:57:
[...]

Een beetje uitleg is hier misschien op zijn plaats? Query - Light... Ik zie het verband niet helemaal.....

Bij een foute query, wordt er misschien een toegangspad gekozen waar je niet op zit te wachten waarbij tablescans je om de oren vliegen en tijdelijke tabellen als paddestoelen uit de grond schieten... probeer dat maar eens in te beelden bij zo'n grote DB..

[_Thanatos_]

Oftewel een query die zo zwaar is, dat de server zoveel vermogen gaat trekken, dat de lampen ff dimmen. Net als wanneer je je monitor degausst, dan heb je dat effect ook (alleen heeft dat weer een andere oorzaak volgens mij)

Trouwens, een tablescan is toch niet zo erg? Als je maar goeie indices hebt...

[Annie]

_Thanatos_ schreef op 19 November 2002 @ 11:38:
Trouwens, een tablescan is toch niet zo erg? Als je maar goeie indices hebt...

Het principe van een goede index is juist dat je een table scan (full, that is) wil vermijden. Waarschijnlijk een babylonische spraakverwarring; je bedoelt hetzelfde, maar zegt het anders.

[jochemd]

_Thanatos_ schreef op 19 November 2002 @ 11:38:

Trouwens, een tablescan is toch niet zo erg? Als je maar goeie indices hebt...

Als je indices gebruikt is er sprake van een indexscan, geen tablescan. Een tablescan betekent per definitie dat je geen index gebruikt.

[Kool]

Op de Stanford universiteit in de VS hebben ze een DB die dik 500 terabyte is. Hier slaan ze alle interessante botsingen van deeltjes in een deeltjesversneller in op.

http://www.cnn.com/2002/T...18/stanford.database.idg/

Dit is een van de grootste databases die bekend is. volgens dit bericht althans.