[Westman]

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.

[Rampe]

Ursprungligen postat av Westman

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.

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

[Westman]

Ursprungligen postat av Rampe

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

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å.

[danjel]

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..

[Jim_Westergren]

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).

[Emj]

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.

[dAEk]

Ursprungligen postat av Emj

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

+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.

[iamandreas]

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?

[CotopaXi]

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.

[tartareandesire]

Ursprungligen postat av CotopaXi

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.