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

[Westman]

Börjar du prata såna mängder frågor och så stor datamängd så är dina maskinexempel väldigt klena. Sen är det också rätt viktigt att veta vilken motor du kommer att använda då det ger möjligheter och även restriktioner i om man kan och bör använda många "små" servrar eller ett fåtal stora.

När det gäller IOPS så finns det exempel på system som klarar rätt stora mängder men då pratar vi servrar med PCI Express SSD:er. Exempel från IBM.

[KristianE]

Ursprungligen postat av Westman

Börjar du prata såna mängder frågor och så stor datamängd så är dina maskinexempel väldigt klena. Sen är det också rätt viktigt att veta vilken motor du kommer att använda då det ger möjligheter och även restriktioner i om man kan och bör använda många "små" servrar eller ett fåtal stora.

När det gäller IOPS så finns det exempel på system som klarar rätt stora mängder men då pratar vi servrar med PCI Express SSD:er. Exempel från IBM.

Jepp. SATA/SAS-controllers har en gräns och roterande skivor har stora begränsningar.
En av våra partners arbetar med Fusion I/O PCIe-kort. Läsprestandan är ca 1.5
Gigabyte per sekund och skrivprestandan ligger på 1.4 Gigabyte per sekund.

PCIe-controllern har såklart också en gräns men bandbredden är bra mycket högre
än 6 Gbit SAS, t.ex.

Skicka gärna PM om nån vill veta mer.

Core i7 är ingen serverprocessor och jag skulle starkt avråda att använda denna.
Ska du ha något motsvarande/bättre så är det Xeon 5600-serien du bör titta på.
24 GB RAM fylls snabbt om du nu ska ha oändligt med databasstorlek. 5600-serien
stöder 144 GB RAM per CPU så det är bara att köpa på.

[Sludent]

Ursprungligen postat av KristianE

Core i7 är ingen serverprocessor och jag skulle starkt avråda att använda denna.
Ska du ha något motsvarande/bättre så är det Xeon 5600-serien du bör titta på.
24 GB RAM fylls snabbt om du nu ska ha oändligt med databasstorlek. 5600-serien
stöder 144 GB RAM per CPU så det är bara att köpa på.

5600-serien stödjer 288 GB, 5500-serien stödjer 144 GB.

[Sludent]

Reagerade också på den klena hårdvaran som i princip hör hemma på skrivbordet.

[johan1234]

Absolut intressant och inte alltid helt lätt. Känner dock att en viktig puck som är väldigt styrande inte får rätt utrymme - och det är lasten som är extremt styrande. En sak är att växa en databas till 50 TB och ha några köra queries mot den. En annan är att ha 25000 samtidiga användare på den databasen och vilja få resultat från en tabell med några miljoner rader - på millisekunder. Vad är det som gäller tror du?

Vi har kunder som kör alla varianter. Klustrat, replikering och olika former av uppdelning för att klara last och storlek. Kan ge ett råd som vi normalt ger... De större kunderna vi har som kör flera TB och har mycket stor last (som snittar tusentals samtidiga användare) - har vi så här långt alltid rekommenderat dedikerade lösningar för. De flesta skalar dock framsidan - dvs webbservrar mm - i en cloud miljö så de kan skala upp och ner med automatik.

[Westman]

Om vi ändå pratar Intelproppar och 5600-serien så har den också en extra liten feature och det är inbyggd krypteringsfunktion (AES). Jag var inte alldeles pigg när han från Intel pratade men här vaknade jag till.

EDIT: Hittar inte belägg för att AES-NI skulle vara begränsat till X56xx men ska maila Intelmannen och fråga.