Bekijk Volledige Versie : Snelheid SQL database
Hallo, ik heb een vergelijkingssite die nu in de richting gaat van 1 miljoen producten. Ik heb nu nog een shared host. De bezoekers kunnen nu een webshop selecteren en zien dan de producten. Wanneer ik een menu aan wil maken om bijvoorbeeld schoenen van alle webshops te laten zien kun je koffie gaan halen voor de resultaten zichtbaar worden.
Ik vraag mij af waar de snelheid van de SQL database van afhankelijk is. Is dat de CPU of het RAM geheugen? Ik wil overstappen op een VPS als de SQL database daarmee sneller gaat worden.
Het gaat om een Joomla 3.x website. Bij database type staat: MySQLi
Hoi,
meer CPU en meer RAM helpt altijd, echter uit mijn ervaring is dat minder dan 10% van de 'winst' welke je kan behalen qua snelheid.
Meeste winst zit hem in optimalisatie van je database en je code.
Daarom zou ik je adviseren om eerste optimalisatie toe te passen. Ik weet niet of je my.cnf zelf mag wijzigen (wellicht niet gezien je op shared hosting zit) - maar database zelf kan je ook sterk optimaliseren.
Op een VPS zal je hoe dan ook meer vrijheid hebben om nog betere optimalisatie toe te passen, alsmede meer debug informatie (waar de knelpunten zijn in je code) op te sporen.
Dat hangt af van het type gebruik van de database. Als er veel read's zijn dan kan je het beste genoeg geheugen ruimte reserveren voor caching. Zijn er veel write's dan komt naast het geheugen ook nog je storage om de hoek kijken, denk in dat geval aan een goede SAN of op zijn minst SSD of een BBU.
Je kan zeker veel winst halen door je database instellingen te tweaken (en dan niet met gratis tooltjes, maar puur kijken naar je gedragspatroon en talloze mysql flags). Daarnaast is storage een van de belangrijkste dingen voor een database. Je kan beter voor lokale SSD storage gaan of PCIE SSDs voor nog lagere latency. Wij hebben zelf ook wel klanten met websites met meer dan een miljoen producten en dat werkt prima op zware dedicated MySQL servers. Een VPS kan een optie zijn, maar kies dan niet voor een random budget VPS, dan is je shared hosting waarschijnlijk sneller.
Bedankt voor de reacties. Hier kan ik zeker wat mee. Ik ga mij eerst even verdiepen in dedicated MySQL servers.
systemdeveloper
17/09/15, 22:27
Dat is leuk om je in te verdiepen, maar dat maakt je db niet sneller. De schoten voor open doel zoals de juiste indexen maken (wat in sommige gevallen best wel eens lastig kan zijn) of meer ram/cpu daargelaten is het optimaliseren van een db een subtiel samenspel van al die aspecten.
De eerste fase is meestal zorgen dat je een goed genormaliseerde database hebt met de juiste (compound) indexen en queries die daar ook op zijn afgestemd. Vervolgens moet je zorgen dat je genoeg ram hebt voor mysql (index/table/etc cache, querycache, wat buffers) en zorgen dat je een beetje snelle cpu hebt.
Heb je hier nog niet genoeg performance mee, dan moet je echt gaan optimaliseren.
Daarin ga je eigenlijk een paar dingen van de normalisatie platslaan en soms informatie redundant opslaan (iets wat in de normalisatie fase taboe is) om je aantal joins te verminderen en eventueel je gegevens in de indexcache te stoppen zodat je in bepaalde gevallen geen io meer hebt richting data tabellen maar alleen op je index tabellen.
Ook kun je hier denken aan cache aspecten (memcache bv) of het laden van standaard tabelletje in een MEMORY tabel. Soms zelfs via een cronjob genereren van tussentabellen ter ondersteuning van vaak uitgevoerde queries. Stel dat je bv kunt zoeken op vaste prijs ranges (stom voorbeeld, maar ja) van 0-100, 101-200, 201+, dan kun je een tabel maken met referenties naar alle producten in die range. Dan hoeft je query geen miljoen prijzen te vergelijken, maar dan kun je direct op de juiste set gegevens instappen waardoor mysql het veel rustiger krijgt. (product-id's vergelijken gaat veel sneller dan een range van floating waarden tenslotte.