Hoe lang blijft de (oudere) tweakers database bestaan?

[Snowwie]

En dan doel ik eigenlijk op de echt oude content, topics uit 1999 enz.

Die zijn straks over een paar jaar 20 jaar oud.

Leuk voor nostalgie, maar is het nog wel nuttig?

_{Van mij mag het nog 100 jaar blijven staan, hou wel van een beetje nostalgie}

[NMe]

>> LA

Waarom moeite doen om iets dat niet in de weg zit weg te halen? Gewoon lekker laten staan waar het staat.

[LuNaTiC]

Ja hoe moet je anders cringen bij je eigen eerste berichten als puber?

[Snowwie]

NMe schreef op maandag 08 augustus 2016 @ 14:02:
>> LA

Waarom moeite doen om iets dat niet in de weg zit weg te halen? Gewoon lekker laten staan waar het staat.

Geen idee, database opschonen of zo

Ruimte creëren?

Alhoewel 'ruimte' moet anno 2016 toch geen probleem meer zijn.

[Dido]

LuNaTiC schreef op maandag 08 augustus 2016 @ 14:04:
Ja hoe moet je anders cringen bij je eigen eerste berichten als puber?

Daar hoef jij toch niet zo ver voor terug in het verleden?

[LuNaTiC]

Voor mijn eerste berichten wel

[AW_Bos]

Van mij part blijft het lekker staan. Ook waarover in 1998 lekker non-objectief werd geschreven is Tweakers .

nieuws: Overklokken & cachechips
nieuws: Snelheid RAM omhoog door RDRAM
nieuws: Microsoft Hotmail draait op Apache - haha!
Heerlijk speels door Femme geschreven!

Tegenwoordig not-done, maar het laat wel zien hoe Tweakers begonnen is .

[ Voor 39% gewijzigd door AW_Bos op 09-08-2016 16:20 ]

[Snowwie]

Begrijp me niet verkeerd, ik hoop dat het ook zo lang mogelijk blijft bestaan.

Het officiële standpunt van Tweakers is dus dat de database gewoon net zo lang blijft bestaan totdat.....nou ja, vul maar in..

[Puc van S.]

Snowwie schreef op dinsdag 09 augustus 2016 @ 17:35:
Het officiële standpunt van Tweakers is dus dat de database gewoon net zo lang blijft bestaan totdat.....nou ja, vul maar in..

BC4

[Craven]

Ze kunnen hoogstens aan de backend records ouder dan X jaar verplaatsen naar een archief DB op tragere storage/hardware om hiermee geld/ruimte te besparen. Dat levert echter wel weer extra complexiteit op dus ik denk niet eens dat dat opweegt tegen het gemak van alles op 1 systeem bewaren.

[Fore!]

Vanwaar de vraag eigenlijk?

Ik vertrouw de info die ik hier op tweakers vind meer dan de niet onderbouwde gezwam op andere "tech-sites".

Als je al die info nu ineens weghaalt is dat voor mij persoonlijk een probleem. Helaas werk ik niet altijd met het nieuwste van het nieuwste.

[AW_Bos]

Puc van S. schreef op dinsdag 09 augustus 2016 @ 19:14:
[...]


BC4

Wordt leuk met die replicatie van tegenwoordig over twee DC's

Maar goed, de boel wordt gerund door ervaren Tweakers, dus ik snap zelf niet waarom iemand zich moet bekommeren om de performance van Tweakers. .

Lekker laten staan, staat niet in de weg (lijkt me), leuk om terug te lezen, en verder maakt het Tweakers compleet. Stel je toch eens voor dat iemand een tijdje in coma ligt, en daardoor een flink gat in zijn herinneringen en wereldgebeurtenissen heeft. Dan voelt diegene zich ook best incompleet, lijkt me ....

[ Voor 54% gewijzigd door AW_Bos op 09-08-2016 20:05 ]

[Hero of Time]

Craven schreef op dinsdag 09 augustus 2016 @ 19:18:
Ze kunnen hoogstens aan de backend records ouder dan X jaar verplaatsen naar een archief DB op tragere storage/hardware om hiermee geld/ruimte te besparen. Dat levert echter wel weer extra complexiteit op dus ik denk niet eens dat dat opweegt tegen het gemak van alles op 1 systeem bewaren.

Hoeft niet extra complex te zijn hoor. MySQL of MariaDB heeft de mogelijkheid om tabellen over meerdere machines op te slaan. Zo zou je kunnen opgeven dat alles tot 3 jaar oud op de ene server/cluster staat en de rest op een andere. Hoef je in je code niets aan te passen, want de SQL server weet waar wat staat.

[Craven]

Hero of Time schreef op dinsdag 09 augustus 2016 @ 21:00:
[...]

Hoeft niet extra complex te zijn hoor. MySQL of MariaDB heeft de mogelijkheid om tabellen over meerdere machines op te slaan. Zo zou je kunnen opgeven dat alles tot 3 jaar oud op de ene server/cluster staat en de rest op een andere. Hoef je in je code niets aan te passen, want de SQL server weet waar wat staat.

Ok, dat het zo makkelijk was wist ik niet. Maar dan nog vraag ik me af of de extra hardware/software van die extra (goedkope) bak opweegt tegen de winst die je behaald op je high performance bak.

Je moet het toch allemaal weer onderhouden.

[Hero of Time]

Craven schreef op dinsdag 09 augustus 2016 @ 21:25:
[...]

Ok, dat het zo makkelijk was wist ik niet. Maar dan nog vraag ik me af of de extra hardware/software van die extra (goedkope) bak opweegt tegen de winst die je behaald op je high performance bak.

Je moet het toch allemaal weer onderhouden.

Uiteraard, maar als je op een gegeven moment tegen het limiet van je schijfruimte of geheugen aanloopt, is het wel fijn om te weten dat je je database kan sharden op deze manier. Normaal gesproken werk je met een replicated cluster, in master/master of master/slave configuratie en staat je hele database op elke machine. Via sharding deel je dat dus op.

De beste performance haal je als je je data direct uit geheugen kan halen omdat de database daar volledig in past. Via sharden heb je niet de beperking van 1 machine aan geheugen dat te gebruiken is. Dus als je database toch niet in het geheugen past, is het langzamer als je delen moet gaan wisselen en van disk moet lezen. Het aanroepen van een andere machine die het wel in RAM heeft is dan sneller.

[downtime]

Het is toch allemaal maar tekst? Weet iemand hoe groot die database nu is? Ik denk eerlijk gezegd dat dat helemaal niet zo spannend is.

[Hero of Time]

downtime schreef op dinsdag 09 augustus 2016 @ 22:56:
Het is toch allemaal maar tekst? Weet iemand hoe groot die database nu is? Ik denk eerlijk gezegd dat dat helemaal niet zo spannend is.

Daar vergis je je in. Elk teken is een byte. Dat gaat dan al snel oplopen. Tel maar eens hoeveel tekens jouw bericht bevat. Denk dan ook eens aan de frontpage artikelen, reviews, pricewatch entries, etc. Dan kom je al snel op een paar gig dat je in een korte tijd kan vullen. "Het is maar tekst" is de meest gemaakte fout als het gaat over schijfruimte gebruik. Het is heel goed te comprimeren, maar gewoon opslaan is niet zo efficiënt.

[downtime]

Hero of Time schreef op dinsdag 09 augustus 2016 @ 23:03:
[...]

Daar vergis je je in. Elk teken is een byte. Dat gaat dan al snel oplopen. Tel maar eens hoeveel tekens jouw bericht bevat. Denk dan ook eens aan de frontpage artikelen, reviews, pricewatch entries, etc. Dan kom je al snel op een paar gig dat je in een korte tijd kan vullen. "Het is maar tekst" is de meest gemaakte fout als het gaat over schijfruimte gebruik. Het is heel goed te comprimeren, maar gewoon opslaan is niet zo efficiënt.

Ik dacht eigenlijk alleen aan het forum. Ga ervan uit dat die wel een eigen database zal hebben. Maar denk dat je dat het meer is dan er op een doorsnee HDD past?

[Hero of Time]

downtime schreef op dinsdag 09 augustus 2016 @ 23:10:
[...]

Ik dacht eigenlijk alleen aan het forum. Ga ervan uit dat die wel een eigen database zal hebben. Maar denk dat je dat het meer is dan er op een doorsnee HDD past?

Jaren geleden waren er idd twee aparte databases voor de frontpage en forum, iig voor gebruikersregistratie. Dat is samengevoegd, waardoor je nu geen aparte gebruikersnaam en wachtwoord hebt voor het forum en frontpage. Hoe het verder zit, ehm, er zijn een paar .plans geweest die uitleggen hoe de boel eruit ziet qua servers. Er zijn meerdere database servers, maar dat is volgens mij een groot cluster ipv fp en got gescheiden.

Gezien de enorme historie van Tweakers, 18 jaar alweer, zal 't denk ik niet passen op een enkele 6 TB schijf, als dat is wat je bedoelt. Niet dat je dat ook maar zou willen, want als de schijf stuk gaat, is je database foetsie.

[Dirk]

Over de Tweakers databases: reviews: Sql-optimalisatie: één grote versus veel kleine queries en reviews: Praktisch geheugenbeheer in Java bij Tweakers.net laten zien hoe ermee om wordt gegaan. reviews: Tweakers' serverpark anno 2015 geeft een beeld van de hardware.

Een ruim jaar geleden was de database dus 219 GB groot, dat valt wel mee.

[ Voor 6% gewijzigd door Dirk op 09-08-2016 23:24 ]

[MarcoC]

Hero of Time schreef op dinsdag 09 augustus 2016 @ 23:20:
[...]

Jaren geleden waren er idd twee aparte databases voor de frontpage en forum, iig voor gebruikersregistratie. Dat is samengevoegd, waardoor je nu geen aparte gebruikersnaam en wachtwoord hebt voor het forum en frontpage. Hoe het verder zit, ehm, er zijn een paar .plans geweest die uitleggen hoe de boel eruit ziet qua servers. Er zijn meerdere database servers, maar dat is volgens mij een groot cluster ipv fp en got gescheiden.

Gezien de enorme historie van Tweakers, 18 jaar alweer, zal 't denk ik niet passen op een enkele 6 TB schijf, als dat is wat je bedoelt. Niet dat je dat ook maar zou willen, want als de schijf stuk gaat, is je database foetsie.

Een paar terabyte voor Tweakers valt toch wel mee? Voor minder dan €1.000 kan je redundant bijna twintig jaar Tweakers-historie byte-voor-byte opslaan. Verwaarloosbaar bedrag .

Dirk schreef op dinsdag 09 augustus 2016 @ 23:23:
Over de Tweakers databases: reviews: Sql-optimalisatie: één grote versus veel kleine queries en reviews: Praktisch geheugenbeheer in Java bij Tweakers.net laten zien hoe ermee om wordt gegaan. reviews: Tweakers' serverpark anno 2015 geeft een beeld van de hardware.

Een ruim jaar geleden was de database dus 219 GB groot, dat valt wel mee.

219GB zelfs maar, dat vind ik echt wel meevallen .

[ Voor 29% gewijzigd door MarcoC op 09-08-2016 23:27 ]

[NMe]

Volgens mij lopen jullie allemaal een beetje hard van stapel, er is nog helemaal geen noodzaak tot allerlei kunst- en vliegwerk.

[downtime]

Dirk schreef op dinsdag 09 augustus 2016 @ 23:23:
Over de Tweakers databases: reviews: Sql-optimalisatie: één grote versus veel kleine queries en reviews: Praktisch geheugenbeheer in Java bij Tweakers.net laten zien hoe ermee om wordt gegaan. reviews: Tweakers' serverpark anno 2015 geeft een beeld van de hardware.

Een ruim jaar geleden was de database dus 219 GB groot, dat valt wel mee.

Ik heb die links snel even gescand maar zo te zien kunnen die DB servers de hele database bijna in RAM houden. Netjes.

[Snowwie]

Dirk schreef op dinsdag 09 augustus 2016 @ 23:23:
Een ruim jaar geleden was de database dus 219 GB groot, dat valt wel mee.

Praten we dan alleen voor tekst, of ook over foto's die tweakers in hun fotoalbum hebben staan?

219GB is een lachertje.

[Craven]

Hero of Time schreef op dinsdag 09 augustus 2016 @ 22:48:
[...]

Uiteraard, maar als je op een gegeven moment tegen het limiet van je schijfruimte of geheugen aanloopt, is het wel fijn om te weten dat je je database kan sharden op deze manier. Normaal gesproken werk je met een replicated cluster, in master/master of master/slave configuratie en staat je hele database op elke machine. Via sharding deel je dat dus op.

De beste performance haal je als je je data direct uit geheugen kan halen omdat de database daar volledig in past. Via sharden heb je niet de beperking van 1 machine aan geheugen dat te gebruiken is. Dus als je database toch niet in het geheugen past, is het langzamer als je delen moet gaan wisselen en van disk moet lezen. Het aanroepen van een andere machine die het wel in RAM heeft is dan sneller.

Als je tegen hardwarelimieten aan loopt dan is het inderdaad een hele handige functie.

NMe schreef op dinsdag 09 augustus 2016 @ 23:31:
Volgens mij lopen jullie allemaal een beetje hard van stapel, er is nog helemaal geen noodzaak tot allerlei kunst- en vliegwerk.

TS wilde ook alleen weten of zijn jeugdsentiment bewaard blijft . Aangezien we nu pas op 219GB zitten denk ik niet dat dat een issue gaat zijn.

Snowwie schreef op woensdag 10 augustus 2016 @ 00:38:
[...]

Praten we dan alleen voor tekst, of ook over foto's die tweakers in hun fotoalbum hebben staan?

219GB is een lachertje.

219GB is best wel wat hoor, considering dat je hem in geheugen geladen wilt hebben. Het is niet zomaar 219GB die je ergens op spinning disks in raid 1 hebt staan.

Foto's staan ergens anders verwacht ik. Als dat ook nog in die DB zit dan is hij wel wonderbaarlijk klein.

[zeef]

Snowwie schreef op maandag 08 augustus 2016 @ 14:01:
En dan doel ik eigenlijk op de echt oude content, topics uit 1999 enz.

Die zijn straks over een paar jaar 20 jaar oud.

Leuk voor nostalgie, maar is het nog wel nuttig?

_{Van mij mag het nog 100 jaar blijven staan, hou wel van een beetje nostalgie}

Wie het verleden niet kent, zal geen greep krijgen op de toekomst.

[AW_Bos]

Craven schreef op woensdag 10 augustus 2016 @ 07:35:
[...]

Foto's staan ergens anders verwacht ik. Als dat ook nog in die DB zit dan is hij wel wonderbaarlijk klein.

Foto's staan toch gewoon op de fileserver, neem ik aan?

[Delerium]

Ik hoop dat na mijn dood mijn nabestaanden door al mijn reacties een beeld kunnen schetsen van wie ik ook alweer was. Of niet natuurlijk, maar ik zie het toch half als een soort nalatenschap.

Dus waarom trashen?

[ACM]

zeef schreef op woensdag 10 augustus 2016 @ 10:19:
[...]

Wie het verleden niet kent, zal geen greep krijgen op de toekomst.

Resultaten uit het verleden bieden geen garantie voor de toekomst.

Ik kan ook met gezegdes juridische uitspraken strooien

Hoedanook, wat NMe zegt sluit het beste aan op de situatie. Zodra we het idee hebben dat de inhoud van de forumdatabase een technische belemmering zou kunnen gaan vormen, gaan we aan de slag om daar een oplossing voor te zoeken. Of dat dan sharding, data verwijderen of een compleet andere database wordt kunnen we nu dan ook nog niet zeggen.

Het is ook nog maar de vraag of onze eerste problemen ontstaan bij het forum. De reacties vormen bijvoorbeeld wel de grootste tabellen (44GB + 24GB voor de 'ruwe tekst'), maar bij lange na niet degene met de meeste records ("slechts" 38.982.542 op dit moment). Soms zijn tabellen met veel records een groter probleem dan die met veel data. We hebben bijvoorbeeld ook een tabel met 378M records (en 26GB), misschien vormt die wel eerder een probleem.

[Kees]

En zabbix heeft een tabel met 460 miljoen records in zijn database staan (op een aparte server)

De database was vanacht tijdens de backup 220G bytes groot in platte tekst, en neemt nu zo'n 324G bytes in op de diskarray. De volgende dbserver krijgt dus meer dan 256GB geheugen

Er is vooralsnog geen sprake van het verwijderen van content, hooguit archiveren of op een andere manier bewaren.

[ Voor 17% gewijzigd door Kees op 20-08-2016 11:34 ]