FAQ |
Kalender |
|
2010-07-08, 13:05 | #1 | ||
|
|||
Nykomling
|
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. |
||
Svara med citat |
2010-07-08, 13:34 | #2 | ||
|
|||
Har WN som tidsfördriv
|
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 |
||
Svara med citat |
2010-07-08, 14:39 | #3 | ||
|
|||
Bara ett inlägg till!
|
Som studiox säger några tusen rader är inga problem alls om du inte kör det på telefonen.
|
||
Svara med citat |
2010-07-08, 20:44 | #4 | ||
|
|||
Administratör
|
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.
__________________
eldefors.com - Personlig (teknik)-blogg |
||
Svara med citat |
2010-07-18, 01:08 | #5 | ||
|
|||
Flitig postare
|
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 |
||
Svara med citat |
2010-07-18, 21:41 | #6 | |||
|
||||
Flitig postare
|
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
|
|||
Svara med citat |
2010-07-19, 11:02 | #7 | |||
|
||||
Mycket flitig postare
|
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. |
|||
Svara med citat |
2010-07-19, 11:48 | #8 | ||
|
|||
Mycket flitig postare
|
|||
Svara med citat |
2010-07-19, 12:18 | #9 | ||
|
|||
Har WN som tidsfördriv
|
Citat:
En "Enterprise" disk kommer ju att få exakt samma problem. |
||
Svara med citat |
2010-07-19, 11:26 | #10 | ||
|
|||
Har WN som tidsfördriv
|
Citat:
|
||
Svara med citat |
Svara |
|
|