[emilv]

Det är otroligt viktigt att den databasmotor du väljer kan skala ut till flera servrar utan problem. Detta innebär ofta ett problem med relationsdatabaser (men inte alltid! Det finns några kommersiella databaser som skalar).

Jag skulle nog börjat kika på så kallade NoSQL-databaser, ofta kallade dokumentorienterade databaser. Cassandra och MongoDB är ett par kända fria alternativ. De har inga relationer mellan olika dokument och klarar därför att dela upp dem på olika maskiner utan speciellt krångliga lösningar. Typiskt brukar även vara att sökningar och andra typer av jobb kan skalas ut till dessa maskiner automatiskt av databasmotorn.

MongoDB har till exempel stöd för MapReduce för batchjobb, där varje maskin arbetar på sitt eget data och returnerar en delmängd av det slutliga resultatet.

[Clarence]

Ursprungligen postat av emilv

Jag skulle nog börjat kika på så kallade NoSQL-databaser, ofta kallade dokumentorienterade databaser. Cassandra och MongoDB är ett par kända fria alternativ. De har inga relationer mellan olika dokument och klarar därför att dela upp dem på olika maskiner utan speciellt krångliga lösningar. Typiskt brukar även vara att sökningar och andra typer av jobb kan skalas ut till dessa maskiner automatiskt av databasmotorn.

Cassandra brukar räknas till kolumn-orienterade databaser. Sen bör man väl tillägga att NoSQL-lägret även omfattar t ex graf-databaser, xml-databaser, key-value-stores, objektorienterade databaser osv.

Speciellt är det värt att nämna att NoSQL ofta verkar användas i tron om att det alltid kommer skala bättre, prestera bättre och allmänt lösa alla databas-problem. Faktum är att de traditionella databaserna klarar de allra flesta applikationer alldeles utmärkt och att man ofta måste strukturera om rätt grundläggande saker för att ha någon större nytta av ett alternativ. Och även då måste man välja rätt alternativ för sin egen situation. Facebook är alltid ett populärt exempel. De använder MySQL, HBase och Cassandra tillsammans (och en mängd andra tekniker, men för databasen). Alla valt utifrån datan som skulle lagras och speciellt hur den används.

Med det sagt tror jag också att emilvs mongodb kan vara intressant om det är expanderingen och klustringen som är ditt stora problem, som det låter på din fråga. Det är väldigt lätt att lägga till nya shards, det finns stöd för auto sharding, maxsize osv.

Men beskriver du inte din användning i mycket större detalj finns det ingen som kan ge dig ett informerat förslag utifrån ditt användningsområde.

Ursprungligen postat av abergman

Du skulle kunna Lastbalansera ett gäng mysqler så du sprider läsning och skrivning, dock så har du som redan sagt ett problem med datamängden, det kommer ta stopp i diskarna troligtvis.

Du skulle splitta upp databasen och lagra olika delar på olika maskiner, så att du istället för att ha 1*MASSVISMEDDATA så har du 4*INTELIKAMYCKETDATA..

Det abergman beskriver kallas sharding om du vill läsa mer information om det på nätet (det mesta är på engelska givetvis). Använder du MySQL är även MySQL Cluster värt att titta på.

[abergman]

Ursprungligen postat av Clarence

Cassandra brukar räknas till kolumn-orienterade databaser. Sen bör man väl tillägga att NoSQL-lägret även omfattar t ex graf-databaser, xml-databaser, key-value-stores, objektorienterade databaser osv.

Speciellt är det värt att nämna att NoSQL ofta verkar användas i tron om att det alltid kommer skala bättre, prestera bättre och allmänt lösa alla databas-problem. Faktum är att de traditionella databaserna klarar de allra flesta applikationer alldeles utmärkt och att man ofta måste strukturera om rätt grundläggande saker för att ha någon större nytta av ett alternativ. Och även då måste man välja rätt alternativ för sin egen situation. Facebook är alltid ett populärt exempel. De använder MySQL, HBase och Cassandra tillsammans (och en mängd andra tekniker, men för databasen). Alla valt utifrån datan som skulle lagras och speciellt hur den används.

Med det sagt tror jag också att emilvs mongodb kan vara intressant om det är expanderingen och klustringen som är ditt stora problem, som det låter på din fråga. Det är väldigt lätt att lägga till nya shards, det finns stöd för auto sharding, maxsize osv.

Men beskriver du inte din användning i mycket större detalj finns det ingen som kan ge dig ett informerat förslag utifrån ditt användningsområde.



Det abergman beskriver kallas sharding om du vill läsa mer information om det på nätet (det mesta är på engelska givetvis). Använder du MySQL är även MySQL Cluster värt att titta på.

Har du någon aning om hur prestandan skulle bli med 1 SQL-nod och 2 storagenoder?

[Clarence]

Ursprungligen postat av abergman

Har du någon aning om hur prestandan skulle bli med 1 SQL-nod och 2 storagenoder?

Mycket sämre än att skapa en egen lösning med sharding/replikering (beroende på syftet för valet av mysql cluster) klassiska MySQL på samma 3 maskiner. På nivån med tre noder kan jag inte se mycket poäng med att använda cluster, förutom att man har den framtida skalbarheten. Tydligt exempel på när skalbarhet (ännu) inte har något med prestanda att göra.