Over og ut for MySql?

[kongen]

Hvorfor vil man i fremtiden bruke MySQL som er treg og har begrenset lagringskapasitet når man kan bruke MemSQL som er kjapp og kan skaleres til det uendelige?

http://www.memsql.com/

MemSQL er en in-memory database som backupper til disk og kan skaleres horisontalt over flere servere. Hvis databasen er 50 millioner Gigabytes så kan du fordele databasen over flere servere, men en MySql database kan aldri bli større enn størrelsen på en harddisk.

Fuck MySql, go MemSQL

 

[xdex]

Hæ? Jaja.. Lurer på hvorfor MySQL Cluster eksisterer..

 

[mra]

men en MySql database kan aldri bli større enn størrelsen på en harddisk.

Hehe, ok? Vi har nå en MySQL database som pt. er 8-9TB, fordelt på en haug med disker og det har nå gått ganske bra så langt

Når det er sagt, så liker jeg MemSQL, til sitt bruk er den helt super, men i mine øyne er det på ingen måte en generell erstatter for MySQL.

 

[kongen]

Lurer på hvorfor MySQL Cluster eksisterer..

MySQL er så treg at man må bruke klyster for å få fart på systemet

 

[xdex]

MySQL er så treg at man må bruke klyster for å få fart på systemet

Okei? så du kjøper smarttelefon for å kun sende sms også? alle produkter har sitt område, og alt til sitt bruk. Men dødt, som du sier? Langt i fra. Det er bare du som ikke har fått med deg alt.

 

[mra]

MySQL er så treg at man må bruke klyster for å få fart på systemet

Hehehehe, jeg er sterkt uenig. MySQL er kanskje ikke super raskt rett ut av boksen, men med korrekt konfigurering og hardware, så vil MySQL kunne håndtere det aller meste tilfredsstillende.

 

[kongen]

MySql er så treg at den må smøres med lakserolje for å få ting til å gli. Er det mulig å få MySql på RAMmen eller holder den fast på fysisk lagring?

Leste en plass at database i RAM var 30 ganger kjappere enn database på disk. Hvis man bruker en in-memory database så slipper man også å cache data man henter fra databasen.

Kan jeg med mysql skifte engine=InnoDB til engine=memory og så kjører mysql i RAM?

 

[mra]

Nå blir det jo kanskje ikke helt fair å sammenligne hastighet på en database kjørt fra disk, med en database kjørt fra RAM. Det er fult mulig å kjøre en MySQL-database utelukkende i RAM. Om det er spesielt lurt er en annen diskusjon.

Etter min mening er det noen enkle grep du kan gjøre for å få MySQL til å kjøre raskere:
* Ikke bruk JOIN og aksepter at hele databasen ikke nødvendigvis er på 3NF
* Bruk indexes korrekt
* Lagre indekserne i RAM

 

[thomasstr]

Du har mulighet til å sende MySQL rett til RAM, ja, men da bør du også skrive til disk i tilfelle du får en serversvikt.
Som @mra sier også. Gode tips!

Og med in-memory database så må du også opprette en RAM database, eksportere de eksisterende tabellene og laste inn tabellene i RAM databasen.

Noe ala

CREATE TABLE tabell (...) ENGINE = MEMORY;

Så må du også investere en del penger i selve RAM-brikkene også.

Hadde heller brukt noe form for cache ala Varnish. Da vil sidene som er ofte og mest besøkt ligge tilgjengelig i cache (Disk eller RAM) for en gitt tidsperiode.

 

[adeneo]

MemSQL er bare den siste i rekken av ymse pussige databaseløsninger, og er nesten Redis med SQL støtte.

Redis er allerede i bruk hos de aller fleste store nettsteder til kortidslagring i minnet, men data som har lengre gyldighet lagres som regel i litt mer stabile databaser som er enklere å skalere.

Så er jo spørsmålet alltid hvilke forespørsler man egentlig trenger, ikke hvor rask databasen er på papiret.
Trenger man en relasjonell database som de fleste kan bruke, så velger man SQL.
Trenger man enkle key/value oppslag, finnes det mange NoSQL løsninger, slik som Couch, Mongo osv. som kan være raskere enn MemSQL

Trenger man en stabil rask database som er enkel å skalere, enkel å bruke osv, ville jeg kanskje valgt Cassandra eller Aerospike i dag, og jeg ville kjørt den hos Google eller Amazon.
Det er nemlig det som er fremtiden, å sette opp en superduper SS rally database som er skalerbar i uendeligheten ved å klikke på en enkel knapp hos Google, og alt bare virker i løpet av sekunder.

https://cloud.google.com/launcher/?cat=DATABASE

 

[kongen]

Jeg har masse masse JOIN på mange mange tabeller. Jeg lagde indekser av data og det gikk mye kjappere å hente data fra indeksene enn å kjøre vanlige join søk på tabellene.

Er det å lese fra RAM database og skrive til disk database som er det beste?

Hvis jeg skriver til disk databasen og leser fra RAM databasen, men trenger data som nylig er skrevet til disk databasen og som enda ikke er tilgjengelig i RAM databasen, så må det søkes i disk databasen igjen. Hvordan kan jeg best holde RAM databasen oppdatert? Hvis jeg lager en insert trigger som aktiverer en stored procedure og det kommer nye insert før proceduren er ferdig med å kjøre, hvilke trøbbel kan oppstå da?

Google Launcer ser interessant ut. Jeg får sniffe litt på Cassandra i kveld