[MySQL cluster] (Te) hoog geheugengebruik *

[seweso]

Een externe leverancier heeft voor ons een mysql cluster-server ingericht maar de database gebruikt teveel geheugen. Nu zeggen zei dat wij de database verkeerd hebben opgebouwd en deze moeten verbouwen. Zelf denk ik dat als je over schakelt naar een cluster-server het niet logisch is dat je je database kleiner moet maken, je wil juist een schaalbaardere oplossing.

Onze externe leverancier beweert dat TEXT velden altijd 65K aan ruimte innemen ongeacht hoe ze gevuld zijn én dat de gehele database altijd in het geheugen word geladen. Dat klinkt mij erg vreemd in de oren, heeft iemand hier ervaring mee?

Ik heb trouwens hier dezelfde vraag in een beetje oud topic gevonden, daarnaast ging het over een andere versie van mysql en lag het probleem (ogenschijnlijk) ergens anders.


Mysql versie = MySQL 4.1.10a-Max

[seweso]

Niemand?

[Brahiewahiewa]

Hoeveel geheugen is "teveel geheugen"?
En hoe verhoudt 't zich ten opzichte van de hoeveelheid fysiek geheugen?

seweso schreef op woensdag 18 mei 2005 @ 12:05:
Niemand?

Hallo zeg. 't Is hier geen helpdesk met een SLA

[ Voor 47% gewijzigd door Brahiewahiewa op 18-05-2005 12:07 ]

[seweso]

Brahiewahiewa schreef op woensdag 18 mei 2005 @ 12:06:
Hoeveel geheugen is "teveel geheugen"?
En hoe verhoudt 't zich ten opzichte van de hoeveelheid fysiek geheugen?
[...]
Hallo zeg. 't Is hier geen helpdesk met een SLA

Ooh ja dat is inderdaad wel handig om te vermelden. De database gebruikt nu een gigabyte aan geheugen (ram). En dat is ongeveer 2x zo veel als de database groot is. Het stomme is dat ik bij een geclusterde database niet kan zien hoe groot de database is. Dus als ik de database ga verkleinen dan heb ik totaal geen middelen om te zien of het gelukt is.

Ik heb nu het idee om de grote text velden die in de database zitten te zippen met COMPRESS en UNCOMPRESS. Maar ik vraag me af of dat goed gaat werken.

offtopic:
Ik zie got zeker niet als helpdesk, ik zoek hier een second opinion omdat ik helaas niet zo'n goed gevoel krijg bij het verhaal van de leverancier in kwestie.

[TrailBlazer]

Ik heb totaal geen verstand van DB's alleen een databsae van 500 MB op een cluster draaien. Voor redundantie kan ik het me voorstellen maar voor performance

[jochemd]

seweso schreef op woensdag 18 mei 2005 @ 11:29:
Een externe leverancier heeft voor ons een mysql cluster-server ingericht maar de database gebruikt teveel geheugen. Nu zeggen zei dat wij de database verkeerd hebben opgebouwd en deze moeten verbouwen. Zelf denk ik dat als je over schakelt naar een cluster-server het niet logisch is dat je je database kleiner moet maken, je wil juist een schaalbaardere oplossing.

Onze externe leverancier beweert dat TEXT velden altijd 65K aan ruimte innemen ongeacht hoe ze gevuld zijn én dat de gehele database altijd in het geheugen word geladen. Dat klinkt mij erg vreemd in de oren, heeft iemand hier ervaring mee?

Heb jij enig idee wat MySQL Cluster is en hoe het werkt? Ga gewoon de handleiding en de whitepapers lezen, daar staan de antwoorden gewoon in.

[_-= Erikje =-_]

MySQL cluster laad momenteel de GEHELE database in het geheugen en afhankelijk van redundantie dus 2x

How much RAM do I need? Is it possible to use disk memory at all?

Currently, Cluster is in-memory only. This means that all table data (including indexes) is stored in RAM. Therefore, if your data takes up 1 gigabyte of space and you wish to replicate it once in the cluster, you'll need 2 gigabytes of memory to do so. This in addition to the memory required by the operating system and any applications running on the cluster computers.

You can use the following formula for obtaining a rough estimate of how much RAM is needed for each data node in the cluster:

(SizeofDatabase * NumberOfReplicas * 1.1 ) / NumberOfDataNodes

MAW, als je dus 2 storage nodes/SQL nodes hebt en een database van 1 gbyte heb je dus per storage node grofweg een gbyte ram nodig, waarbij de totale database dus inderdaad 2 gbyte gebruikt vanwege de replica.
MySQL cluster gebruiken wij nog niet ivm het memory only gebeuren, als beide machines vastlopen kun je een SQL dump terug gaan zetten...

[ Voor 19% gewijzigd door _-= Erikje =-_ op 18-05-2005 13:42 ]

[igmar]

seweso schreef op woensdag 18 mei 2005 @ 11:29:
Mysql versie = MySQL 4.1.10a-Max

MySQL MAX is geen MySQL, maar onder water gewoon SAPDB. En zoals Erikje aangeeft : Die laad inderdaad alle tabellen in memory.

[_-= Erikje =-_]

MySQL MAX = MySQL met alle opties, alleen gebruik je met cluster een andere storage engine

[jochemd]

TrailBlazer schreef op woensdag 18 mei 2005 @ 13:09:
Ik heb totaal geen verstand van DB's alleen een databsae van 500 MB op een cluster draaien. Voor redundantie kan ik het me voorstellen maar voor performance

MySQL NDB Cluster is ook exclusief een redundantie oplossing. Qua performance zijn er een aantal redenen om aan te nemen dat die zelfs slechter is dan die van de gewone MySQL:
- de MySQL query cache werkt niet met MySQL Cluster
- bepaalde indexen / datatypes werken niet (FULLTEXT, GIS etc.)
- de storage nodes kunnen niet aan predicate filtering doen (heel veel netwerk I/O zodra het geen select van unieke key query is)

Verder is MySQL Cluster een main memory database dus als er iets is waar hij juist niet geschikt voor is is dat grote databases: je hebt al snel 3 maal de grootte van je database aan RAM nodig.

[seweso]

jochemd schreef op woensdag 18 mei 2005 @ 13:35:
[...]
Heb jij enig idee wat MySQL Cluster is en hoe het werkt? Ga gewoon de handleiding en de whitepapers lezen, daar staan de antwoorden gewoon in.

Je huurt een externe partij in zodat je zelf daar niet druk om hoeft te maken. Dit is gewoon iets waar je niet achter wil komen op het allerlaatste moment als je net de database in gebruik wil gaan nemen. De leverancier heeft volgens mij het principe 'trial-and-error' toegepast. Eigenlijk had vantevoren gekeken moeten worden naar een alternatieve database. Nu is voor mijn gevoel zomaar Mysql gekozen omdat het oude systeem daar ook onder draaide.

Het gekke is ook dat ik in de lijst met limitaties in een mysql cluster niet duidelijk kan terugvinden dat de gehele database in het geheugen word geladen. Er staat wel dat het geheugen een begrenzende factor is maar dat is altijd wel op één of andere manier het geval.

Verder vraag ik me af wat jullie van de bewering vinden dat alle textvelden 64K groot zijn en in een cluster-server in feite een vaste veld-lengte hebben. Daar kan ik namelijk ook niks over vinden.

[jochemd]

seweso schreef op woensdag 18 mei 2005 @ 14:02:
[...]
Je huurt een externe partij in zodat je zelf daar niet druk om hoeft te maken.

GoT is niet een door jou ingehuurde externe partij. Handleiding lezen is standaard voor heel GoT, en dat geldt nog eens extra voor Professional Networking & Servers.

Verder vraag ik me af wat jullie van de bewering vinden dat alle textvelden 64K groot zijn en in een cluster-server in feite een vaste veld-lengte hebben.

Dat klopt deels.

quote: http://dev.mysql.com/doc/...r-limitations-in-4-1.html

# In MySQL 4.1 and 5.0, all Cluster table rows are of fixed length. This means (for example) that if a table has one or more VARCHAR fields containing only relatively small values, more memory and disk space will be required when using the NDB storage engine than would be for the same table and data using the MyISAM engine. We are working to rectify this issue in MySQL 5.1.
(..)
#The maximum permitted size of any one row is 8k, not including data stored in BLOB columns. We expect to increase this to approximately 32k in MySQL 5.1.

Je zou je leverancier kunnen vragen of ze zelf een speciale versie van MySQL Cluster hebben gecompileerd met een limiet van 64k.

[seweso]

De rauwe sql dump van de database is maar 70 Mb!!! Ingepakt 7 Mb. De hardware leverancier blijft zeggen dat de database te groot is en hij wil me wel laten zien hoe je een database hoort te maken. Oftewel dat ik iets verkeerd heb gedaan en dat de fout dus bij mij ligt.

[jochemd]

seweso schreef op woensdag 18 mei 2005 @ 17:12:
De rauwe sql dump van de database is maar 70 Mb!!!

Met 1 GB gebruikt je cluster dus 14 maal zo veel RAM als dat je dump groot is. Dat is toch niet zo gek?

De hardware leverancier blijft zeggen dat de database te groot is en hij wil me wel laten zien hoe je een database hoort te maken. Oftewel dat ik iets verkeerd heb gedaan en dat de fout dus bij mij ligt.

Misschien heb je ook wel iets verkeerd gedaan. Wat voor kwaad kan het om op zijn aanbod in te gaan?

[Xandrios]

seweso schreef op woensdag 18 mei 2005 @ 12:05:
Niemand?

Absoluut niet de bedoeling dit kicken. ajb niet doen in 't vervolg.

[Verwijderd]

Move PNS > SA +titelfix