Trött på alla no-sql kuksugare

När all hype väl lagt sig så visar det sig att det finns legitima användningsområden för alla tekniker. Problemet kommer när du försöker slå i en spik med en skruvmejsel. Visst, det går. Men det är mycket lättare med en hammare.

Relationsdatabaser är definitivt att föredra när du jobbar med data som konsistent i format. Dokumentdatabasen, som oftast är vad som menas när man pratar om NoSQL eller Non-relational data, kom till som en lösning på problemet att hantera icke-kanonisk data där datamodellen kan skifta mellan olika dataströmmar eller skifta över tid i samma dataström. Visst, det går att hantera detta i en relationsdatabas också, men inte lika effektivt och med snävare begränsningar.

Egentligen är verkligheten den motsatta - relationsdatabaser tillkom för att hantera strukturerad data på ett effektivare sätt då de tidigaste databaserna (vi snackar 60-tal här) var olika former av key/value eller hierarkiska lagringsmodeller och SQL hade inte uppfunnits än. Så dokument-databasen som sådan är inte en ny "fluga", den har funnits länge. Den har dock aktualiserats de senaste 10-15 åren när fokus skiftat ifrån 90-talets expersystem med strikt definierade datamodeller och transformationsregler till behovet av "big data" och heterogena lösningar med skiftande datamodell och behov att kunna effektivt hantera data av godtyckligt format.

Den där sista meningen, ställer till det. Det går aldrig att hantera effektivt. Skit in är skit ut.

Att det kanske är enklare och snabbare att koda för en ramverkskodare är en sak, men det kommer alltid vara bättre att tänka efter före. Men alldeles för få programmerare orkar sätta sig in i vad det är för data de kommer hantera. Och det får man betala för, antingen genom längre svarstider, eller att slänga in mer och kostsammare hårdvara.

Tänk efter före och välj rätt verktyg till uppgiften. Bygg micro services, så kan man alltid byta teknikstack eller lösning.

Kan hålla med, men "big data" folket tenderar tycka annorlunda.


Tror min poäng var att det finns scenarier där det inte går att veta exakt innan hur strukturen på din data ser ut eller hur den förändras över tid.

Microservices kommer också med sitt pris, exempelvis ett komplext systemlandskap med divergerande teknologier som kan bli kostsamt och svårt att både driva och underhålla.

Ingenting är smärtfritt :-)

Att saker förändras över tid, är något man kan planera in. Det kommer ske.

Håller med om att det finns fall där det är omöjligt att veta hur strukturen på datat ser ut. Dock tror jag att det är undantag, snarare än regel. Med hjälp av microservice-tänket, så minimerar man var det får finnas.

MS-tänket kan bli komplext om man ger det helt fria händer att välja. Man bör även där tänka devops och hålla sig till stora, välkända teknikplattformar, så det inte blir personberoenden.

"Best tool for the job". Alla problem går inte att lösa på samma sätt. Om man nu får samma resultat med NoSQL som RBDS så kan man välja det som passar bäst, ibland passar NoSQL bäst.

Precis, det är huvudorsaken till varför en del väljer nosql, de har inte lärt sig jobba mot en relationsdatabas vilket är något märkligt för det är inte speciellt svårt.

Tippar på att man i 99 fall av 100 skall välja relationsdatabas framför nosql på grund av funktionalitet. De som faktiskt bör välja nosql istället för relationsdatabas har mycket speciella krav.

Jag gillar SQL. Men jag gillar också noSQL.

Om du ska göra ett dokument-baserat system då är det enklare att göra ett objektträd och dunka ner detta i en MongoDB. Det blir snygg kod, som inte blir för komplicerad och det blir oftast tillräckligt snabbt också.

SQL med en ORM är betydligt mer komplext. Ofta göms komplexiteten men den finns ju där ändå och orsakar ofta problem när en ORM som EF används felaktigt. Vilket ofta blir fallet, när utvecklarna inte förstår SQL och relationsdatabaser ordentligt.

Men jag förstår dig, det är en lite orolig utveckling om detta inte lärs ut ordentligt längre, eftersom SQL och relationsdatabaser är helt överlägsna på prestanda vid många transaktioner och mycket data. Och att man ofta ser att det görs en massa work-arounds typ cachning osv som ger nya problem, som man plåstrat på eftersom man inte valde rätt teknik från början till sin lösning.

Sen betyder ju noSQL: not only SQL (inte: not SQL)

Jag skulle snarare vilja se att DSL:er som SQL utvecklades mer och användes mer till allt möjligt snarare än att det ska ses som "förlegad teknik". Hur kan det vara förlegat med mindre antal kodrader som gör mer? Det måste ju vara rätt väg att gå. Kanske inte minst inom HTML/CSS/JS-träsket där det kodas så in i helsicke, med ganska liten effekt per skriven kodrad.

Och man vet att man aldrig kommer söka efter något utan alltid vet exakt position vart datat ligger. Men även då är det tveksamt om man ändå valt en nosql.

Tänk på att de som beskriver fördelar hos nosql ofta beskriver vad nosql saknar men som finns hos relationsdatabaser.
Exempelvis skalning, ett problem med relationsdatabaser är när databaser behöver köras på flera fysiska maskiner, detta eftersom databasen har funktionalitet för att synkronisera/jämföra data på olika sätt. nosql skryter då med att de går att skala till fler fysiska maskiner, men orsaken till varför är att de inte synkroniserar data.
Det är inga problem att lägga en relationsdatabas på en fysisk maskin och en annan relationsdatabas på en annan fysisk maskin som inte "pratar" med varandra och få samma skalfördelar som hos nosql.

Den bästa beskrivningen av nosql är att säga att det är en avskalad relationsdatabas. De har inte så mycket funktionalitet

Nä, så fungerar inte MongoDB. Där lagras datat binärt som bson. Du behöver inte veta var. Och du kan i efterhand skapa index så att du snabbt kan börja söka på t.ex. order.orderline[x].articleNo.


Nja, stämmer inte riktigt. Problemet är ju relationerna. Att en logisk mängd data kan bestå av data från många olika tabeller, dessa måste hänga ihop. Medan i noSQL blir det ju enklare att skala ut eftersom där sparar du hela ordern eller hela fakturan i ett, inte i fler olika tabeller (även om det också är möjligt).

Men visst, du kan ju designa systemet på ett liknande sätt i SQL som i noSQL, och få det att fungera på ett liknande sätt som en "skalbar" noSQL-databas, det stämmer bra.

Det är valfritt att lägga in regler i databasen. Går alldeles utmärkt att strunta i regelverk och lägga in vad som helst som inte hänger ihop.

Och det är viktigt att tänka på, enligt mig är det vansinne att välja nosql för nästan allt annat än lek. Om man väljer nosql så vet man verkligen exakt varför och är mycket kunnig

Databasteknologi skapades när vi hade jättelångsamma och små hårddiskar. Det var tvunget att fungera så för att något skulle fungera alls. I dag ser det väldigt annorlunda. Vi har SSD-diskar som läser 1 GB på en sekund. I många system kan du komma undan med att spara ner data som filer i olika mappar och eventuellt indexera lite vid sidan av.

ja, snabbare diskar har gjort att databaser (både relationsdatabaser och nosql databaser blivit snabbare). Snabbare disk gör att gott åt båda.

Jag vill bara varna för denna enkelhet att lagra data har ganska lite med enkelhet att skapa applikationer eller programmera att göra. Det enkla blir snabbt otroligt svårt för man har trasslat in sig dåliga lösningar där man måste kompensera överallt, exempelvis med att "indexera vid sidan av".

Göra trädlösningar i relationsdatabaser är lätt, göra trädlösningar i relationsdatabaser med referensintegritet är inte lika lätt, lite överkurs men går alldeles utmärkt. Och det är en enorm hjälp för de som lagrar data att ha något där informationen är korrekt. Information som innehåller skräp är inte bra information, det finns gott om företag som spenderat enorma summor på att tvätta sin information, det finns gott om företag som går i konkurs för att deras information blivit mer eller mindre oanvändbar.