[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

[studiox]

Ursprungligen postat av Rampe

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.

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.

[Bjorne]

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

[Jine]

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

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

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