PDA

Bekijk Volledige Versie : SQL performance verhogen



Rev00
29/11/10, 14:57
Beste WHT'ers,

Momenteel draai ik 3 colo DELL servers dedicated als MySQL(5) server met de nodige tweaks in my.cnf om er per machine ongeveer 2000 q/sec te halen. Deze machines draaien allemaal dezelfde DB schema's maar met inhoudelijk andere data.

Echter zit ik momenteel met een uitdaging. Er moet een soort centrale tabel komen waar inserts (log) en selects (check log) op plaats vinden die vervolgens door alle machine's te raadplegen is. De verwachte query's zijn ongeveer 4000 q/sec op deze tabel, omvang 10-15M rows, 7-8 collommen (~3GB data).

Er zou natuurlijk gewoon een tabel gemaakt kunnen worden met 3x mysql master-to-master specifiek op die tabel in sync blijft, echter met dit query volume vraag ik me af hoe het syncen van deze data voor impact heeft op de performance.

Verder kan de select evt. nog komen te vervallen door een unique constraint en bij falen -> check log = false, en bij een succesvolle insert check log = true.

Wie heeft er suggesties dit elegant op te lossen?

IP2internet
14/12/10, 17:57
Kun je niet een vierde machine toevoegen en deze tabel van deze machine af draaien? Is dat mogelijk?

wonko
15/12/10, 16:29
als je de load wil spreiden kan je even kijken naar de mogelijkheden met sharding/partitioning.

Rev00
15/12/10, 16:31
Ik heb al een mooie tool in elkaar gezet met mysql proxy + memcached + mysql replication die op de achtergrond sync-ed :)

Wido
15/12/10, 18:02
Ga je niet eerder tegen tabel locking aanlopen door de vele INSERT's? Is het MyISAM of InnoDB btw? Dan heb je table vs row-locking.

Rev00
16/12/10, 00:07
MyISAM met INSERT DELAYED INTO. Code execution draait gewoon netjes door zonder te wachten op evt. table locking en mysql handeld de rest vrij snel/goed af.

PreServer
16/12/10, 00:26
als het echt alleen inserts en select zijn zou je is moeten kijken naar de Archive Storage Engine http://dev.mysql.com/tech-resources/articles/storage-engine.html

Rev00
16/12/10, 07:58
als het echt alleen inserts en select zijn zou je is moeten kijken naar de Archive Storage Engine http://dev.mysql.com/tech-resources/articles/storage-engine.html

Goede tip, bedankt! Kan er alleen niet duidelijk aan op maken (hun doen table scan voorbeeld) of indexen dan nog zin heeft op de velden waar je de query op doet, lijkt mij namelijk wel nuttig... Weet jij dat toevallig?

Update:



We also talked about how Archive doesn't support indexes at this time:

mysql> create index my_index on test_archive (client_transaction_id);
ERROR 1069 (42000): Too many keys specified; max 0 keys allowed

One special thing to note about Archive tables and indexes is that, if you want to alter another storage engine table to be an Archive table, you must first drop any indexes that have been defined on the table.


Eens zien of dit op een tabel met 20-30M rows nog een beetje presteerd...

Rev00
16/12/10, 08:42
Dat werkt dus totaal niet:



CPU and IO utilization of the last 01 min: 41.00
CPU and IO utilization of the last 05 min: 17.50
CPU and IO utilization of the last 10 min: 6.80


Geen auto increments en selects op die table onmogelijk traag. Ik hou het wel bij die geknutselde proxy + memcached ;)

QBell
16/12/10, 09:33
Is er een reden dat je dit per se in (My)SQL wil doen?
Andere databases zijn voor deze performance meer geschikt en schalen ook nog beter (zoals mongodb, die is perfect voor logtabellen).

Anders zou het zaak worden om zelf je primary key te generen (dmz nanoseconds). Dit om geen dubbele keys te genereren zodra 1 van de masters uit valt.

Hou er ook rekening mee dat mysql-proxy heel instabiel word als je hier 6000+ p/s doorheen gooit.

Ervaring?
Neuhhh, voor een aantal sites doe ik tussen de 6 & 8000 q/s X 4 slaves + 1 master.
De grootste bottlenek hierin zijn de HDD's en de queries zelf (index gebruik). Alle machines zijn uitgerust met minimaal 64GB aan geheugen om zoveel mogelijk indexen te kunnen cachen.

Rev00
16/12/10, 09:52
Deels zo gegroeid, op de log tabellen worden vanuit PHP een aantal rapportages gedraaid voor het management.

Zal eens een dev machine met mongodb uitrusten en zien of ik daar wat mee kan, verder zijn deze servers ook vrij redelijk, raid10 op 15k sas schijven en 32gb ram p/stuk memory.

thanks voor de tip iig!

Dreas
16/12/10, 10:16
Probeer ook eens MariaDB. Een MySQL fork, met een hoop zinvolle patches. Kan je gewoon je huidige MySQL mee vervangen.

QBell
16/12/10, 15:54
Probeer ook eens MariaDB. Een MySQL fork, met een hoop zinvolle patches. Kan je gewoon je huidige MySQL mee vervangen.

MySQL leent zich niet zo voor groot aantallen in queries.
Er zitten nogal wat performance penalty's op het creƫren en onderhouden van indexen en als je die niet gebruikt worden je penalty's nog groter.