Hoe groot is DB van Tweakers.net eigenlijk?

[Verwijderd]

dat vroeg ik me nou eens af..

Weet iemand dat?

[Verwijderd]

groot ?

[ShadowBumble]

hehehe kijk maar naar de topics en user hoeveelheid en je kunt ongeveer wel een schatting maken..........groot dus

[Verwijderd]

Hoeveel MB, ben ik ook wel eens benieuwd ja?

[Verwijderd]

Laten we gokken!

[Verwijderd]

plm. 1,3 mln posts van gem. een tekentje of 300.

zeg zo'n 400MB

[razor-x]

Volgens mij was hij 4 gig

[Verwijderd]

Ze hebben laatst grote schoonmaak gehouden gewoon een heel deel weg gekiept

[Rappie]

Op donderdag 21 juni 2001 17:51 schreef Mr.WWW het volgende:
Ze hebben laatst grote schoonmaak gehouden gewoon een heel deel weg gekiept

LOL

ik schat 5 gieg

[TiG]

Ik heb wel is ergens gelezen dat ie 2GB was.

Correct me if I'm wrong.

[jelmervos]

Ik gok 1 GB.

[bartvb]

Ik ga mee met MREn..

Heb ff op mijn forum (met 100k posts) zitten kijken en daar:

code:

+---------------------------------+
| sum(length(post_text))/count(*) |
+---------------------------------+
|                 345.03 |
+---------------------------------+

dus iets over de 500MB ofzo inclusief extra tables (users, sessions, etc, etc) en indices..

[Verwijderd]

PS. ik had het dus even alleen over GoT

[MAZZA]

Op donderdag 21 juni 2001 17:51 schreef razor-x het volgende:
Volgens mij was hij 4 gig

Dat heb ik een t.net medewerker ook ergens zien zegen

[ACM]

De laatste keer, dat ik deze vraag zag (ergens in H&W) zei kees daarop: ~4Gig. (de dumpfiles worden samen ~4gig dus)

[brammetje]

is redelijk

[RobzQ]

Toch knap een db van 4 gig is niet niks en de snelheid heeft er weinig onder te lijden.

[Onno]

Op donderdag 21 juni 2001 18:55 schreef ACM het volgende:
De laatste keer, dat ik deze vraag zag (ergens in H&W) zei kees daarop: ~4Gig. (de dumpfiles worden samen ~4gig dus)

GoT zal ongeveer 1GB zijn, zit daar dan nog 3GB van tw.n bij? Lijkt me erg veel...

[El Jefe]

Groot genoeg tot nu toe

[RobzQ]

Hij is laatste wel weer een stukje kleiner geworden

[Annie]

Wat voor dump? De complete sql scripts + inserts? Dan geloof ik best dat de bestanden flink groot worden.

Maar hoe groot zijn de db-files? Dat is denk ik interessanter.

[Michael]

Op donderdag 21 juni 2001 17:59 schreef bartvb het volgende:
Ik ga mee met MREn..

Heb ff op mijn forum (met 100k posts) zitten kijken en daar:

code:

+---------------------------------+
| sum(length(post_text))/count(*) |
+---------------------------------+
|                 345.03 |
+---------------------------------+

dus iets over de 500MB ofzo inclusief extra tables (users, sessions, etc, etc) en indices..

Of je doet 'show table status like '<TABLENAME>\G', zie http://www.mysql.com/doc/S/H/SHOW_TABLE_STATUS.html

[bartvb]

Hey, da's een handige:

code:

mysql> show table status like 'posts_text'\G
*************************** 1. row ***************************
         Name: posts_text
         Type: MyISAM
     Row_format: Dynamic
         Rows: 100794
 Avg_row_length: 357
    Data_length: 36052696
Max_data_length: 4294967295
   Index_length: 1140736
    Data_free: 0
 Auto_increment: NULL
    Create_time: 2001-06-01 02:04:52
    Update_time: 2001-06-21 20:04:36
     Check_time: NULL
 Create_options: 
      Comment: 
1 row in set (0.01 sec)

357 bytes per posting dus

[ACM]

Op donderdag 21 juni 2001 19:24 schreef Onno het volgende:
GoT zal ongeveer 1GB zijn, zit daar dan nog 3GB van tw.n bij? Lijkt me erg veel...

Ik herhaal ook alleen maar wat kees mij verteld hoor...

[Femme]

De gezipte tar van alle databases (incl. en fok en indexes e.d.) is 870MB. Ongezipt is het meer dan 3GB.

[Onno]

Daar stond net nog "meer dan 4GB".

[ACM]

Op donderdag 21 juni 2001 20:24 schreef Onno het volgende:
Daar stond net nog "meer dan 4GB".

Ssssjt (ik zag het ook )

Maar ik zal deze thread even in mijn FAQ zetten

[Femme]

Het is 3,1GB totaal

t.net: 372MB
GoT: 971MB
stats: 288MB

[Verwijderd]

hmmmm.... niet slecht, als ik zie dat ie nog aardig snel gaat...

[Gerco]

Op donderdag 21 juni 2001 20:30 schreef Femme het volgende:
Het is 3,1GB totaal

t.net: 372MB
GoT: 971MB
stats: 288MB

Misschien kan ik slecht rekenen, maar dat is geen 3.1GB, eerder 1631MB

[marteltor]

Was ie veel groter voor de crash?

[Devian]

beschouw dit als niet geplaatst

[bartvb]

Ik zat me net af te vragen of zo'n dump (met die insert commando's enzo) nou veel groter is dan de raw-data maar dat valt reuze mee:

Dump: 39.623.758
Raw: 36.052.696

[Onno]

Op donderdag 21 juni 2001 20:33 schreef Gerco het volgende:

[..]

Misschien kan ik slecht rekenen, maar dat is geen 3.1GB, eerder 1631MB

Fok.

[Femme]

Misschien kan ik slecht rekenen, maar dat is geen 3.1GB, eerder 1631MB

Fok! zit er idd nog in en verder wat test/knutsel/dev troep.

[Verwijderd]

Hoe hou je dat ihn zo snel?

[Verwijderd]

Hoe hou je dat zo snel

Dit vind ik dus een goede (zinnige) vraag.

[brammetje]

mysql is gewoon een goede database

[Onno]

Op donderdag 21 juni 2001 21:45 schreef KixAss456 het volgende:
Hoe hou je dat ihn zo snel?

Als je indices goed kiest en handige queries gebruikt wordt een database niet snel langzaam hoor...

[JaQ]

indexes en goed je code controleren op full-table-scans.. (dat is toch tweaken?? )

Een beetje DBA heeft goeie explain-plan scripten liggen... (een echt goeie heeft ze liggen, die ook je create index-statements maken) (ik kan je helaas alleen de oracle-scripten leveren)

[Verwijderd]

LOL

[ACM]

Op donderdag 21 juni 2001 23:26 schreef DrFrankenstoner het volgende:
(ik kan je helaas alleen de oracle-scripten leveren)

Ik hou me aanbevolen

[Verwijderd]

Op donderdag 21 juni 2001 23:26 schreef DrFrankenstoner het volgende:
(ik kan je helaas alleen de oracle-scripten leveren)

Waarom? Het is toch allemaal SQL?

code:

CREATE INDEX indUsers ON tblUsers (Username,Password);

[Verwijderd]

Op vrijdag 22 juni 2001 09:39 schreef KixAss456 het volgende:

[..]

Waarom? Het is toch allemaal SQL?

code:

CREATE INDEX indUsers ON tblUsers (Username,Password);

Dat dacht ik dus ook

[raptorix]

Moet je niet aangeven wat voor index? En hoe zit het met de fillfactor?

[ACM]

Op vrijdag 22 juni 2001 09:57 schreef Gordijnstok het volgende:
Dat dacht ik dus ook

Heren:

Een beetje DBA heeft goeie explain-plan scripten liggen... (een echt goeie heeft ze liggen, die ook je create index-statements maken)

Voor mysql is dat niet echt van toepassing vermoed ik, maar voor oracle?

[CyberSnooP]

MySQL heeft een EXPLAIN commando, en daarmee kun je een heel end komen met optimaliseren (schijnt). Ik kan het zelf niet, heb het nooit gedaan, maar de MySQL-Manual geeft best wat aardige tips.

Verder zijn het allemaal losse tabellen, en als er dus een nieuwsposting wordt opgehaald wordt alleen die nieuwsposting-tabel (=file) geopend.. Of de rest dan kei groot is of niet, dat maakt MySQL nix uit.

[ACM]

Op vrijdag 22 juni 2001 18:27 schreef CyberSnooP het volgende:
Verder zijn het allemaal losse tabellen, en als er dus een nieuwsposting wordt opgehaald wordt alleen die nieuwsposting-tabel (=file) geopend.. Of de rest dan kei groot is of niet, dat maakt MySQL nix uit.

Wat bedoel je hiermee??
Dat Femme voor elke nieuwsposting een nieuwe TABLE maakt???
Lijkt me heeel erg sterk.
Bovendien maakt het wel uit, of er veel of weinig files open zijn (mijn systeem is regelmatig onbruikbaar geworden, doordat ie meer dan 4096 (was toen limiet) files wilde openen )
Maar vooral met file-caching maakt het uit denk ik.

[CyberSnooP]

Op vrijdag 22 juni 2001 18:29 schreef ACM het volgende:
Wat bedoel je hiermee??
Dat Femme voor elke nieuwsposting een nieuwe TABLE maakt???
Lijkt me heeel erg sterk.

Of Femme een tabel maakt per nieuwsposting weet ik net zo min als jij.. maar daar ging ik niet van uit.

Ik bedoel dat de database uit allerlei verschillende delen bestaat, dus als je uit een deel het e.e.a. wilt halen, maakt het niet uit dat de rest van de database groot is. Met als voorbeeld een nieuwsposting, want die staan vast en zeker in een tabel.

Ik denk dat MySQL (of databases in het algemeen) pas langzaam worden als tabellen heel groot worden, en niet als je een grote database hebt.

[ACM]

Op vrijdag 22 juni 2001 18:52 schreef CyberSnooP het volgende:
Ik denk dat MySQL (of databases in het algemeen) pas langzaam worden als tabellen heel groot worden, en niet als je een grote database hebt.

Dat is zeker een van de redenen waar (vooral mysql, maar ook andere) databases sloom van (kunnen) worden.
indices zijn er om dat enigszins op te vangen, maar geoptimaliseerde indices zullen het nog veel beter op kunnen vangen.

Grote databases maakt opzich idd niet uit. Maar als jij 100000 tables gaat lopen maken, moet je niet denken (en ik denk niet dat je dat doet ) dat het net zo snel is als 100 (verder even grote) tabellen