Kom ihåg mig?

Optimering av mysqldatabas

 
Ämnesverktyg Visningsalternativ
Oläst 2010-07-08, 14:05 #1
-Joel- -Joel- är inte uppkopplad
Nykomling
 
Reg.datum: Feb 2004
Inlägg: 24
-Joel- -Joel- är inte uppkopplad
Nykomling
 
Reg.datum: Feb 2004
Inlägg: 24
Question Optimering av mysqldatabas

Hej alla WN-are! Jag har hängt på forumet under rätt lång tid, och läst mycket intressant. Tack för alla tips!

Nu har jag en fråga. Hittills har jag bara gjort några mindre projekt som inte blivit så mycket med. Nu har jag börjat med ett (förhoppningsvis) större projekt, och jag har lite funderingar kring optimering av databasen:

Databasen innehåller en tabell över några tusen rader, som förändras. Över dessa "produkter" ska det köras fritextsökningar, som ska kunna hitta träffar mitt inne i "produktnamnen". Det är batchjobb med många sökord, tio- kanske hundratusentals. Sökorden är kopplade till användare, och jag misstänker att det kommer att finnas väldigt mycket dubbletter bland sökorden.

Nu till min fråga: är det värt att separera sökningarna från användarna för att slippa köra identiska sökningar? Då måste det till en extra tabell som kopplar ihop sökningarna med varje användare, med massa extra joins som följd. Dessutom ökar det komplexiteten i utvecklingen.

Kortfattat undrar jag alltså om fritextsökningar som letar genom hela strängen är så tidsödande att det motiverar en ökad komplexitet och tidsåtgång med en extra "jointabell"?

Tack på förhand!

Ps. Tips var jag kan hitta bra information om databaser mottages tacksamt.
-Joel- är inte uppkopplad   Svara med citatSvara med citat
Oläst 2010-07-08, 14:34 #2
studiox studiox är inte uppkopplad
Har WN som tidsfördriv
 
Reg.datum: Aug 2004
Inlägg: 1 356
studiox studiox är inte uppkopplad
Har WN som tidsfördriv
 
Reg.datum: Aug 2004
Inlägg: 1 356
1.) Kör tester
2.) Gör tester
3.) Testa

Det finns inget bra svar på din fråga. Enklast är att du skapar ett par "dummy" tabeller med massa skärpdata. Det är ju lätt att skapa och så kör du lite tester.

Jag har en tabell som innehåller sådär 21 miljoner rader som jag kör fritext på, tar cirka 10 sekunder att hitta upp rätt rad. Så när du säger 1000 så blir jag inte ett dugg orolig, om du inte ska köra det på ett nintendo
studiox är inte uppkopplad   Svara med citatSvara med citat
Oläst 2010-07-08, 15:39 #3
Ara Ara är inte uppkopplad
Bara ett inlägg till!
 
Reg.datum: Mar 2005
Inlägg: 1 956
Ara Ara är inte uppkopplad
Bara ett inlägg till!
 
Reg.datum: Mar 2005
Inlägg: 1 956
Som studiox säger några tusen rader är inga problem alls om du inte kör det på telefonen.
Ara är inte uppkopplad   Svara med citatSvara med citat
Oläst 2010-07-08, 21:44 #4
Clarence Clarence är inte uppkopplad
Administratör
 
Reg.datum: Jan 2003
Inlägg: 1 974
Clarence Clarence är inte uppkopplad
Administratör
 
Reg.datum: Jan 2003
Inlägg: 1 974
Generellt sett kan det vara bra att indexera datan i ett lämpligare system om det ska köras en större mängd wildcard-sökningar. Se t ex söklösningar som Sphinx eller Lucene/SolR. Då får du mycket bättre prestanda för större datamängd - men frågan är om den behövs. Generellt sett kan du räkna med att hantera _minst_ 10 gånger trafiken mot en MySQL fulltext och än större skillnad mot en icke-indexerad fråga i MySQL.

Har du frekvent uppdaterad data kan du endast få begränsad nytta av att cacha resultat. Har du dessutom en liten andel återkommande frågor så blir nyttan än mindre.

Med det sagt så är ett par tusen rader och några hundra frågor mot en kort sträng som ett batch-jobb ingen större utmaning även för en slö server. Jag skulle nog föreslå att köra det fulkodat men ha en plan tillgänglig för när man kan se prestandaproblem närma sig.
Clarence är inte uppkopplad   Svara med citatSvara med citat
Oläst 2010-07-18, 02:08 #5
Martin™ Martin™ är inte uppkopplad
Flitig postare
 
Reg.datum: Mar 2007
Inlägg: 345
Martin™ Martin™ är inte uppkopplad
Flitig postare
 
Reg.datum: Mar 2007
Inlägg: 345
Jag jobbar på en ny hemsida och den har ungefär 10000 rader i databasen. Sidan har varit jätteseg men idag satte jag mig ner och försökte optimera databasen. Jag lade till några index och nu laddar sidan ~dubbelt så snabbt!
Länktips: http://www.databasejournal.com/featu...le.php/1382791
Martin™ är inte uppkopplad   Svara med citatSvara med citat
Oläst 2010-07-18, 22:41 #6
JLEs avatar
JLE JLE är inte uppkopplad
Flitig postare
 
Reg.datum: Aug 2007
Inlägg: 382
JLE JLE är inte uppkopplad
Flitig postare
JLEs avatar
 
Reg.datum: Aug 2007
Inlägg: 382
Har över 100 miljoner poster i en databas och kör då MySQL med InnoDB samt Sphinx Search för att göra fulltext-sökningar. Dock fanns det en begränsning i Sphinx som gjorde att jag fick dela upp det i 3 st index. Detta körs på en fem år gammal server och sökningar tar runt 1 ms
JLE är inte uppkopplad   Svara med citatSvara med citat
Oläst 2010-07-19, 12:02 #7
Normans avatar
Norman Norman är inte uppkopplad
Mycket flitig postare
 
Reg.datum: Feb 2004
Inlägg: 589
Norman Norman är inte uppkopplad
Mycket flitig postare
Normans avatar
 
Reg.datum: Feb 2004
Inlägg: 589
Vad är avsikten med optimeringen?
Läs / skriv?

För läsning räcker det i stort sett att se till att du kan hålla hela databasen i ram-minne och extra för att kunna hålla sökresultat i cache.
Mer ramminne, vettiga strukturer på databas så kan sökningar hållas i cache.

För skrivning så är det snabba diskar eller ha ramdisk cache som gäller.
Du kan även vinna på att investera i SSD diskar. Skrivhastighet, IO/ps random writes är vad som är viktigt.

Tänk dock på att vanliga "konsument" ssd diskar inte är att tänka på eftersom de har begränsat antal skrivningar innan hastigheten på dessa begränsas. (INTEL firmware som gör detta)
Så har du loggning på, massa skrivningar och annat så kommer SSD prestandan degraderas kraftigt med tiden.

Det som skiljer enterprise SSD (inte alls samma sak när det gäller SSD , även om myten säger det) är att enterprise SSD är testad för mycket högre antal skrivningar och att firmwaren då inte kommer börja strypa hastighet för att skyddadisken.

Enterprise SSD är dock mycket dyrare, så kanske blir värt ändå i vissa fall att köra konsument SSD och sen byta med regelbundna mellanrum.
Norman är inte uppkopplad   Svara med citatSvara med citat
Oläst 2010-07-19, 12:26 #8
studiox studiox är inte uppkopplad
Har WN som tidsfördriv
 
Reg.datum: Aug 2004
Inlägg: 1 356
studiox studiox är inte uppkopplad
Har WN som tidsfördriv
 
Reg.datum: Aug 2004
Inlägg: 1 356
Citat:
Ursprungligen postat av JLE Visa inlägg
Har över 100 miljoner poster i en databas och kör då MySQL med InnoDB samt Sphinx Search för att göra fulltext-sökningar. Dock fanns det en begränsning i Sphinx som gjorde att jag fick dela upp det i 3 st index. Detta körs på en fem år gammal server och sökningar tar runt 1 ms
hur stora är tabellerna du söker i? 100 miljoner artiklar och en sökning tar 1ms är inte realistiskt imho
studiox är inte uppkopplad   Svara med citatSvara med citat
Oläst 2010-07-19, 12:48 #9
Lumax Lumax är inte uppkopplad
Mycket flitig postare
 
Reg.datum: Jun 2004
Inlägg: 610
Lumax Lumax är inte uppkopplad
Mycket flitig postare
 
Reg.datum: Jun 2004
Inlägg: 610
Citat:
Ursprungligen postat av Norman Visa inlägg
Tänk dock på att vanliga "konsument" ssd diskar inte är att tänka på eftersom de har begränsat antal skrivningar innan hastigheten på dessa begränsas. (INTEL firmware som gör detta)
Har du nån källa där man kan läsa på lite om det?
Lumax är inte uppkopplad   Svara med citatSvara med citat
Oläst 2010-07-19, 13:18 #10
studiox studiox är inte uppkopplad
Har WN som tidsfördriv
 
Reg.datum: Aug 2004
Inlägg: 1 356
studiox studiox är inte uppkopplad
Har WN som tidsfördriv
 
Reg.datum: Aug 2004
Inlägg: 1 356
Citat:
Ursprungligen postat av Norman Visa inlägg
Tänk dock på att vanliga "konsument" ssd diskar inte är att tänka på eftersom de har begränsat antal skrivningar innan hastigheten på dessa begränsas. (INTEL firmware som gör detta)
Jag trodde ALLA SSD diskar betedde sig på samma sätt? Att radera block i SSD kostar ju plats då man måste radera block i oftast 16k storlek har jag för mig, medan du kan skriva i så små som 2k eller något. TRIM är ju något som delvis löser det problemet då man väljer att helt enkelt radera ett 16k block först efter att man "tömt" det helt.

En "Enterprise" disk kommer ju att få exakt samma problem.
studiox är inte uppkopplad   Svara med citatSvara med citat
Svara

Taggar
databas, mysql, optimering


Aktiva användare som för närvarande tittar på det här ämnet: 1 (0 medlemmar och 1 gäster)
 
Ämnesverktyg
Visningsalternativ

Regler för att posta
Du får inte posta nya ämnen
Du får inte posta svar
Du får inte posta bifogade filer
Du får inte redigera dina inlägg

BB-kod är
Smilies är
[IMG]-kod är
HTML-kod är av

Forumhopp


Alla tider är GMT +2. Klockan är nu 12:41.

Programvara från: vBulletin® Version 3.8.2
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Svensk översättning av: Anders Pettersson
 
Copyright © 2017