×

Help Tweakers weer winnen!

Tweakers is dit jaar weer genomineerd voor beste nieuwssite, beste prijsvergelijker en beste community! Laten we ervoor zorgen dat heel Nederland weet dat Tweakers de beste website is. Stem op Tweakers en maak kans op mooie prijzen!

Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door Arjen van der Meijden

Lead Developer

Sql-optimalisatie

En grote versus veel kleine queries

Door , 206 reacties

Inleiding

In de afgelopen periode hebben we bij Tweakers diverse belangrijke stukken code herschreven. Eerder dit jaar is ons vernieuwde reactiesysteem geïntroduceerd, en in april en mei zijn we bezig geweest om het karmasysteem te herschrijven.

Daarbij is niet alleen de functionaliteit aangepakt, ook de prestaties van de componenten zijn opnieuw bekeken. Bij beide systemen zijn de prestaties bij het gebruik van de database dominant voor de totale benodigde tijd. Een goede vorm om de data op te slaan, met de juiste indices, en het efficiënt uitlezen van de gegevens zijn dus erg belangrijk. Voor beide voorbeelden gebruiken we onze centrale MySQL-database.

Op internet zijn allerlei uitspraken over de snelheid van sql-databases te vinden. In de afgelopen jaren zijn er bijvoorbeeld allerlei NoSQL-databases verschenen en vaak worden dan een of meer negatieve aspecten genoemd die met een dergelijke nieuwe database beter gaan. Vaak wordt gesteld dat het voldoen aan alle vier de componenten van acid de prestaties en schaalbaarheid in de weg zit. Daarbij worden dan vooral consistency en isolation zwakker uitgewerkt in die systemen.

Ook de complexe queries die met sql mogelijk zijn, worden genoemd; die mogelijkheid zou slecht zijn voor de prestaties en bovendien helemaal niet nodig zijn. Het kunnen join-en van tabellen en de mogelijkheden voor subqueries zijn de vaste voorbeelden daarbij. Het gaat dan soms zelfs zover dat in één adem geadviseerd wordt om die zaken ook te vermijden als je wél sql blijft gebruiken. Het zou dan eveneens slecht zijn voor de prestaties en lastig te verenigen zijn met sharding-functionaliteit. Het advies is dan om de queries zo simpel mogelijk te houden en liefst alleen via de primary key in een tabel te zoeken. Complexe handelingen, zoals het combineren van data, kunnen tenslotte ook in de applicatielaag gedaan worden.

Als je een object relational mapper gebruikt, zoals Doctrine, dan wordt dat advies effectief standaard opgevolgd. Bij een orm moet er meestal zelfs moeite gedaan worden om van dat model af te wijken. Een join gebruiken betekent vaak extra code toevoegen.

Hoewel het altijd verstandig is om code eenvoudig te houden, is het wel zonde als daardoor grote prestatiewinsten blijven liggen. De adviezen over sharding van data zijn tenslotte alleen relevant als dat echt gebruikt wordt. Als er geen sharding wordt gebruikt, is het juist handig om data uit diverse queries in de database al te koppelen. Dat kan flink wat overhead schelen; denk aan de losse round-trips van query en data, rechtenchecks en allerlei aanverwante handelingen die dan in de database minder vaak gedaan hoeven te worden.

Er is daarbij natuurlijk wel verschil tussen de diverse platforms. Op sommige platforms, waaronder veel soorten applicaties in java-applicatieservers, kunnen orm's gegevens in het geheugen van de applicatie cachen. In zulke gevallen worden al round-trips bespaard, maar dat valt of staat dan met de effectieve hitratio van de cache en de kwaliteit van de synchronisatie met de database. De hier gegeven adviezen gelden vooral voor toepassingen waarbij dergelijke caches niet praktisch zijn, zoals meestal bij php het geval is.

Wat ons betreft valt de database van Tweakers met 219GB trouwens niet in de orde van grootte om over te stappen op sharding of andere technieken om verscheidene servers tegelijk te gebruiken. Overigens hebben we er wel op diverse manieren voor gezorgd dat de MySQL-database niet voor alle gegevens gebruikt hoeft te worden. We hebben er bijvoorbeeld voor gekozen om bepaalde stukken data in MongoDB op te slaan of in memcached te cachen en veel van de informatie wordt via onze Java-omgeving opgevraagd.

In dit artikel beschrijven we twee toepassingen waarbij de databaseprestaties voor ons belangrijk waren. Daarbij laten we stapsgewijs een aantal optimalisaties zien die significante verbeteringen in de prestaties gaven. Bedenk wel dat dit artikel niet gaat over het plaatsen van de juiste indices of het optimisaliseren van de instellingen van een database. Dit is een parallelle taak waarbij bekeken wordt of de database wel optimaal ingezet wordt, maar een goed geoptimaliseerde tabelstructuur en database zijn uiteraard ook belangrijk voor goede prestaties.


Apple iPhone X Google Pixel 2 XL LG W7 Samsung Galaxy S8 Google Pixel 2 Sony Bravia A1 OLED Microsoft Xbox One X Apple iPhone 8

© 1998 - 2017 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Hardware.Info de Persgroep Online Services B.V. Hosting door True

*