Optimera mysql - monsterserver!

Hej!
Jag visste inte riktigt hur jag skriva rubriken men jag arbetar en hel del med ganska stora databaser. Det är mellan 5-10 miljoner rader och dom joinas och det ena och det andra.

Jag skulle vilja ha förslag på hårdvara, mjukvara och metoder inom databasdesign på hur man kan snabba upp allt. Jag kör med Wamp i Windows på en rätt bra dator.

Jag har sökt en del om detta innan, t.ex. att man ska ställa in saker i mysql my.ini. Och skillnaden mellan dom olika databasmotorerna. Men jag har inte hittat någon riktigt bra guide som sammanställer det mesta.

I alla fall, jag skulle vilja ha tips/rådgivning/länkar så att jag kan snabba upp mina querys och helt enkelt skapa en monsterserver som gärna får ta upp allt mitt ram-minne och köra slut på min processor.

Den allmänna meningen verkar vara att LAMP > WAMP.

Min egen erfarenhet från databastuningar säger att det har inte jättemycket med vad för hårdvara maskinen är bestyckad med som är avgörande i de allra flesta fall utan det handlar snarare om hur frågorna själva är ställda som avgör hur väl en databas funkar.

Här är iaf MySQLs egna tuning-förslag:

https://dev.mysql.com/doc/refman/5.5...imization.html

Hittade nåt annat här med:

http://www.slideshare.net/osscube/my...ng-top-10-tips

Med min rekommendation är ändå att du kollar en benchmark på dina frågor och sedan börjar du skruva på hur frågorna är ställda istället.

Du skulle eventuellt kunna införa partitionerade tabeller i din databas med, vet dock inte om dessa har jättestor betydelse om din databas endast huserar på en maskin dock.

https://dev.mysql.com/doc/refman/5.5...-overview.html

Tack så mycekt för era svar!

Först och främst, på jobbet har vi tänkt installera någon *nix dist, blir förmodligen Ubuntu, och sen utgår vi där ifrån.

Sen, tack för länkarna. Ska kolla in detta! Om vi jämför t.ex. servern vi har sidan på så kanske det tar t.ex. 1 min att utföra en query medans det tar 5-10 min på min egna dator. Här handlar det ju inte om att queryn är tunad utan hur servern är optimerad.

Men jag ska kolla in länkarna och sen återkommer jag.
Mvh

Nu skriver jag lite allmänt för att din fråga är ganska tunn och det behövs mer information för att skriva mer om hur du ska gå tillväga för att lösa ett specifikt problem.

Jag hoppas att ni kör på innodb som motor, annars har ni skjutit er själva i foten enligt mig.
Sedan gällande en server så kan varje komponent vara en bottleneck. För en server så är som du säkert redan vet, processor, minne och disken viktigast. Vad som är problemet i ditt fall är svårt att säga då jag inte vet vad ni kör på för burk, hur indexeringen ser ut osv.

Här är några tips du kan följa:
https://www.percona.com/blog/2014/01...-installation/

Har själv optimerat servrar som kör på några miljoner records med flera joins osv så utan att veta exakt hur din query ser ut eller vad för slags hårdvara du kör på osv så är 1-10 minuter sjukt lång tid för en query.

Tack för länken, ska kolla in den. Ja 10 minuter är lång tid och det är också därför jag vill ha tips på hur jag förbättrar allt. Mina tabeller ligger på runt 10 miljoner rows. Och dessa joinas och det ena och den andra, men sen så används dom också flitigt av våra kunder och det är också därför det segas ner.

Men jag återkommer när jag jag gått igenom länkarna.

Mina fem öre för att få sql-frågor att leverera svar snabbare:

* Indexera lagom mycket. Ett index kostar prestandamässigt dubbelt så mycket vid skrivningar, som vid läsningar, så att bara slentrianmässigt slänga på index kan straffa sig vid insert/update/delete-sql. Men har man fler läsningar än skrivningar mot den tabellen, är det oftast ingen fara

* Vid skrivningar låses tabeller för läsning, vilket kan få till synes enkla läsfrågor att ta tid att leverera ett svar. Så har du krångliga, tidskrävande skrivningar till databasen, som sker ofta, kan det vara en faktor att titta på.

* Om möjligt, när du skriver dina select-satser, joina ihop tabellerna så att varje join i sig, skapar så litet resultatset som möjligt. Vad menar jag med det då? Jo, har du tre tabeller som du ska joina ihop, på 10, 100 och 1000-rader, så börja med de minsta tabellerna. Då får du ett internt resultatset på 1000 rader. Hade du istället tagit de två största tabellerna hade du haft ett resultatset som varit hundra gånger större. Visst, när du joinar ihop alla tre tabeller, så har du lika stort resultatset oavsett hur du gör, men jag finner att det går snabbare att gå från minsta till störst. Att lägga på where-vilkoren på joinarna istället, kan också snabba upp frågan.

* Försök att inte joina ihop för många tabeller samtidigt. Kan slöa till det. Istället för

SELECT *
FROM tabell1 t1
JOIN tabell2 t2 ON ...
JOIN tabell3 t3 ON ...
JOIN tabell4 t4 ON ...
JOIN tabell5 t5 ON ...
JOIN tabell6 t6 ON ...

kan följande gå snabbare

SELECT *
FROM tabell1 t1
JOIN tabell2 t2 ON ...
JOIN tabell3 t3 ON ...
JOIN (SELECT *
FROM tabell4 t4
JOIN tabell5 t5 ON ...
JOIN tabell6 t6 ON ...) t7 ON...

Verkar som den då hanterar de interna resultatsetten mycket bättre.

* Är det så att användarna ofta ställer samma frågor som får samma svar? Cacha resultatet och använd det istället.

1 minut för att köra en query? Du får nog börja indexera dina databaser bättre

De databaser jag arbetar med är inte indexerade. Så det får jag ta och kolla upp.
Grymt svar! Tack så mycket! Vad menar du med att casha resultatet? Menar du att jag sparar det i en variabel istället för att hämta den från databasen varje gång?

Mer tips, vad som helst. Mjukvara, hårdvara, optimering, queries(?). Allt uppskattas!

Först lite kort om inte-WAMP.
Du kan vinna mycket på att gå över till Linux och använda postgresql istället för mysql.

Postgresql har ett större och trevligare community än mysql, som kan hjälpa dig med optimeringar. Postgresql planerar också dina queries bättre än vad mysql gör.

Det är när databaserna blir stora som postgresql brilljerar när det gäller schema och database management.

Mysql.
Med MySQL behöver du byta "kärnan" för att få en kärna som är anpassad efter dina behov. Du tittar på MariaDB och allt vad de heter och ser om du enkelt kan byta ut en av dem och få ökad prestanda. (En av anledningarna till varför jag gick över till Postgresql).

Det första du ska göra är att skriva om queries givetvis. Det är det första du gör. I alla databashanterare kan du köra något kommando som "testar" dina queries, visar hur de planeras. Där kan du få insikt om vad det är som tar tid.

Om du inte kan få till snabba queries och byte av "kärna" (eller vad de kallar det i mysql) så behöver du bygga om databasdesignen, vilket är ett riktigt hassle i MySQL. Du sätter nycklar, index, kolumner osv rätt så att du snabbt kan göra de joins du vill göra.

För att kunna hjälpa dig optimera behöver vi specifik information. Hur dina queries och tabeller i detalj ser ut.

Använd kommandot "explain relevant_tabell;" och ge oss output tillsammans med dina queries.

Spinner lite, men arbetar själv mot fullkomligt enorm databas som utan problem skulle kunna försöka leverera typ 10 000^2 * 1 000 000 records vid tillräckligt klantig fråga. Tycker det varit väldigt meckigt att hitta rak information om komplexitet inom just databashantering.

Har förstått det som att standard är att WHERE alltid behandlas före SELECT oavsett ramverk d.v.s. att WHERE är det första som behandlas i:
SELECT
FROM . INNER JOIN .. ON
WHERE (.this=.that)

Vilket då gjort att jag sätter väldigt mycket fokus i WHERE-statement och kan vara rätt trygg bara jag vet att mitt WHERE-statement alltid gör en tillräckligt bra selektering.

I övrigt har det som sagt varit en meckig djungel att förstå sig på hur man ska förhålla sig till komplexiteten i det vi gör, då det är lite udda upplägg om man bara är van att koda vanliga algoritmer samt verkar variera ganska mycket beroende på lösning.

Har du eller någon något bra tips angående vart man kan studera detta på ett lite mer systematiskt sätt än att hoppa fram och tillbaka mellan helt random diskussioner på nätet? Mina frågor blir möjligen lite noobiga, men hela området känns lite som att man antingen kan allt eller inget.

Grejen med att cacha, är att minimera prestandaåtgången för servern, per anrop.

Om man jämför med tex Flashbacksidan, så genereras den antagligen "på baksidan" av ganska många olika SQL-frågor. Bara om man tittar på sidhuvudet hittar man flera frågor. En fråga för att räkna hur många besökare som är online, en fråga för att räkna hur många medlemmar som finns, en fråga för hur många inlägg som finns, en fråga för FLASHBACK.SE-radens nyhetslänkar.

Det här är samma information som visas för oss besökare, vid varje sidanrop. När jag skriver det här är det 13 480 besökare, vilket då betyder att vid varje sidanrop ställs det nästan 54 000 sql-frågor. Det blir miljoner frågor i timmen. En betydande prestandaåtgång, även om det är enkla frågor.

Förmodligen så finns det nog ett mall-sidhuvud, i form av en datafil, där dessa uppgifter lagras. Kostar väldigt lite i prestanda att infoga med övrig sidinformation. Sedan uppdateras detta sidhuvud en gång i halvtimmen eller nåt sånt. Dvs istället för miljoner frågeställningar mot databasen per timme, är vi nu nere i åtta stycken frågor.

Handlar det om webben för din del, så kanske din webserver kan cacha automagiskt. Brukar finnas en del inställningar för det. Men det är som sagt var en avvägning mellan absolut aktuell information och hög prestanda, vs relativt fräsch information och låg prestanda. Vad behöver du/dina användare mest av?