Snabbaste SQL-servern?
 

Jag sitter med ett större projekt som kräver en snabb databas engine, och därav min fråga: Vilken är det snabbaste databasserver (enligt fakta) som kan användas enkelt och effektivt med PHP.

Jag vet mycket väl att ex. MySQL är snabb, men behöver en ännu snabbare för detta, och tyvärr så handlar det inte om optimering eller dyl.

Kommer ha 2-3 tabeller, varav en av dem kommer innehålla några miljarder raws.

Några tips eller referenser?

MySQL cluster är ju ett alternativ.. eller någon NoSQL lösning.

Om du gjort alla optimeringar som GÅR att göra (Du får gärna berätta vad du gjort) så får du skaffa snabbare hårdvara, mer minne och snabbare hårddiskar.

Många hävdar att postgresql är snabbare än Mysql men min erfarenhet är att SELECT finns det inget som slår mysql på.

Dock har exempelvis SSD diskar visat sig öka prestanda med 50 ggr. Går att göra ganska mycket.

Största databasen jag pillat med hade runt 20miljoner rader och närmare en miljard kombinationer och det gick att få ner accesstiden rätt rejält om man vet vad man gör.

Det är ett nytt projekt, så det finns ingen databas ännu. Därav denna fråga, för att göra rätt från början (istället för att behöva skriva om koden sen, samt migrera databasen).

Jag har hört en annan databas engine än MySQL som ska vara snabbare men där jag inte kan minnas namnet på..

Jo absolut, men det får gärna vara sista utvägen.
NoSQL kanske kan vara något, aldrig pillat med det, men får google och se vad den kan göra för mig :)

MySQL är ingen engine.. MyISAM eller InnoDB är engines, inte MySQL, det är en server.

Du har helt rätt, jag som uttryckte mig fel.

Dum fråga men du vet alltså att du från dag 1 kommer ha ett par MILJARDER rader i din databas?

I så fall borde du göra precis som vilken duktig utvecklare som helst - skapa redan nu 3 miljarder rader i mysql och testa så kommer du märka hur bra eller dåligt det blir.

MySQL-kluster med databasen i RAM? Alternativt så ger PCI-korts-SSD-diskar grym prestanda. Naturligtvis med rätt mängd RAM och tweaks.

PS. Du kan alltid få köpa vår gamla Itanium med 16 proppar och 256 GB RAM för en billig penning. ;)

Varför skulle det vara en dum fråga?
Jag vet att det kommer bli tungt, inget jag behöver testa för att veta. Men det har med olika faktorer att göra, lite som de andra försöker vinka för, d.v.s hårdvara.

Men jag tackar för ditt förslag.

Hehe bästa av båda världarna. ingen dålig hw, men tyvärr förmodligen några ören dyrare än vad jag vill spendera på detta projekt :cool:

Nåja du fick väl lite tips av mig också. Men om det nu är så att du inte har intresse av att testa detta innan så är du faktiskt korkad. Ingen seriös person som jobbar med databaser ignorerar att göra prestandatester med testdata, det är otroligt värdefullt. Fast jag gissar att du inte jobbar med ett riktigt projekt utan mest är nyfiken.

Det är absolut inga problem för postgres att hantera ett par miljarder rader. Sedan är optimeringar alltid det viktigaste.

NoSQL (t.ex. FB's Cassandra eller MongoDB) + memcache säger jag.

:)

En normal server med vanliga SSD-diskar gör mirakel den med och kostar inte alltför mycket. Om nu inte databasen blir groteskt stor så det går åt massor med SSD då.

Om du inte behöver relationer mellan tabellarna (?) överväg en lösning där man inte använder relations databaser. Det låter mer som en lösning för key- value stores som BigTable eller Cassandra som redan påpekats. Men dessa datamängder innebär potentiellt stora stora problem vad gäller prestanda , backup m.m om man inte exakt vet vad man gör..

Ta en titt på Redis http://redis.io/ som är en annan NoSQL lösning. Jag använder den själv.

Jonas Lejon tycker att den är Guds gåva till webbutvecklaren:
http://utvbloggen.se/redis-ar-guds-g...bbutvecklaren/

Den enda begränsningen är RAM. Jag har ca 0,25M nycklar och den tar ca 200 MB så alltså ingen fara för mig. Dock med flera miljarder nycklar så beror det ju på hur mycket data det handlar om. Annars kan du ju använda en relationsdatabas som MySQL och använda Redis som cache (som jag gör). Blir ungefär som memcache tror jag bara det att du kan cacha längre med Redis (jag cachar en månad), du kan manipulera data bättre och att Redis kan hantera 81000 GET per sekund (enligt Jonas Lejon).

Det är svårt att säga något utan att veta vad du vill göra.

Dela med dig av din tabell-layout, annars går det inte att säga så mycket vettigt.

Dear everyone who are not Facebook. You are not Facebook.

Bygg applikationen med de verktyg du känner till, först när du har den mängd data du pratar om kan du börja oroa dig för skalning. Dessutom är hårdvara billigt i jämförelse med utbildning/learn by doing very wrong.

Håller med dig rent generellt MEN det finns tillfällen då man snabbt får väldigt stora datamängder trots att man inte har miljontals användare, t.ex. om man sysslar med forskning eller utveckling (inte minst bioteknik och relaterade vetenskaper), statistik etc. Finns säkert fler exempel som jag inte kommer på där man redan från början vet att man kommer behöva arbeta med stora tabeller.

Jag föreslår att du kikar på¨Microsoft SQL-server, Sybase SQL-server, Oracle, IBM DB2 för att ta några exempel som alla är snabbare än MySQL när det gäller relationsdatabaser.

testat SQL-lite?

Jag är lite förvånad om att ingen har nämnt Percona Server. Det är en fork av mySQL med google och andra företags patchar inlagt. Mycket snabbare än vanilla mySQL, stabilare och utnyttjar alla kärnor. Dessutom är den 100% kompatibel med vanliga mySQL vilket gör det superenkelt att flytta över sin databas :)

För enkel jämförelse av features gå till http://vschart.com/list/database/

+1

Det framgår t.ex. inte vad i MySQL som är för långsamt, hur datat används (skrivs det ofta till databasen eller är mest läsningar?) eller om ni måste ha stöd för transaktioner.

Kan väl bara hålla med. Datastruktur, write/read load, transaktionsstöd, relationsbehov osv är av extremt stor vikt.

XtraDB (Percona som nämns ovan) kan vara ett bra val - om det behövs transkationsstöd, det är en hög write load eller väldigt lokaliserad läsning (i och med att du då får den lokaliserad till buffer poolen automatiskt).

Behöver du något som är smidigt att klustra upp för snabbare svarstider vid frågor så finns många intressanta NoSQL-lösningar.

Kan du bli tvungen att ändra datastrukturer i efterhand så bör du istället titta mot schemalösa databaser eller se till att sharda din data väldigt genomtänkt.

Har du en väldigt enkel datastruktur kan ett key-value-store vara bäst. De skalar ofta mycket bättre och många av dom har inbyggda klustringsfunktioner.

Motiveringarna till val är långt många fler än så och riktigt bra tips från folk som vet vad de pratar om får du först om du kan beskriva ditt problem mycket mer utförligt.

Vidare är det värt att säga att du kommer få problem direkt om du får för dig att använda SQL Lite. Även MSSQL och MySQL med MyISAM är som upplagt för problem vid den skalan - även om de båda är väldigt kompetenta på sina vis.

Scale later
http://gettingreal.37signals.com/ch04_Scale_Later.php

Du kanske inte ens behöver en databas? Beror ju på vad du vill kunna göra med datat.

Som några redan nämnt är NoSQL otroligt snabbt... men som sagt - vad ska du göra med datat?