Datat anonymt för servern
Kan i princip bara söka på primärnycklar
Nästlade nyckelpar
Följa länkar mellan värden
Datat känt för serven
Set-operationer på servern
Vyer / Index
Fördefinierade eller ad hoc -frågor
Schemalöst
Vad ska man ha dem till?
.Net genom hela kedjan
Transaktioner
Safe by default
Lucene.Net
Skalar ut
Replikerar till MSSQL
Map reduce
Här om veckan var jag på en kurs i RavenDB med Ayende Rahien
Jag är en ganska inbiten relationsdatabasfanatiker så hela kursen blev ungefär som om man jobbat hela livet med filer och sedan går en kurs i MsSql Server. Det var ganska överväldigande och jag hade inget aktuellt kundcase att hänga upp kunskaperna på.
Som någon slags befästelse av mina nyvunna kunskaper ska jag hålla ett föredrag om RavenDB på jobbet i kväll.
Här kommer rubriker, noteringar och en del bakgrundsinformation som jag samlat ihop:
RavenDB
NoSQL
RavenDB faller in under kategorin NoSQL-databas. De flesta NoSQL-databaser byter bort en del konsistenkontroller för att uppnå större skalbarhet. Utan foreign keys blir det lättare att skala ut över flera servrar. RavenDB tillåter att man lägger data som ofta kommer efterfrågas samtidigt på samma server vid en distribuerad lösning.
Key/value store
Riak, Redis och en massa andra.
Key value store är som det låter, en lång lista med namn/värde-par. (Nyckel och blob.) En del k/v-stores tillåter länkar mellan nycklar eller nästlade nyckelpar, men man kan bara göra sökningar mha nycklar.
Största begränsningen gentemot dokumentdatabaser är att servern inte vet något om det lagrade datat.
Dokumentdatabaser
RavenDB, CouchDB, MongoDB bla.
Dokumentdatabaser å andra sidan har viss förståelse för det data som sparas. Det kan vara XML, json, binary json tex. Detta gör att man kan utföra setoperationer med och på datat på servern.
Dokumentdatabaser är schemalösa och det finns oftast inga relationer som upprätthålls av databasmotorn. Man kan så klart spara nyckeln till ett relaterat dokument, men servern kommer inte se till att relationen upprätthålls.
Att man inte behöver deklarera schemat i förväg gör utvecklingen väldigt smidig.
Om man använder RavenDBs .Net-provider behöver man bara skicka ner sina objekt som de ser ut för närvarande så tar RavenDB hand om json-konverteringen.
Det gör å andra sidan att man måste tänka på och hantera olika versioner av data löpande i stället för att göra stora migreringar av data.
Nya och borttagna fält sköter sig själv precis som man kan tänka sig. Något som kan bli en negativ aha-upplevelse är att RavenDB städar bort borttagna egenskaper från dokument när man sparar om dem med nytt schema.
För att migrera data från tex ett namnfät till För- och Efternamn kan man skriva konverterare som kommer att köras automatisk när man läser dokument som som har en gammal version.
RavenDB har stöd för set-operationer på servern så där kan man göra migreringar av data, vilket verkar vara den allmänna rekommendationen även om det förtar smidigheten med schemalösa dokument. Till skillnad mot en relationsdatabas kan man spara godtyckligt komplexa dokument, listor, träd osv.
I RavenDB och CouchDB definierar man index i förväg. Resultatet sparas och de blir jättesnabba att söka på.
MongoDB tar lite samma väg som en RDBMS. Där skapas index på sekundära värden som sedan kan användas för ad hoc -frågor.
CouchDB uppdaterar index när det ställs en fråga vilket gör att första frågan mot ett smutsigt index kan ta lång tid.
RavenDB returnerar allt den hittat på typ 15 sekunder om inte indexet redan är uppdaterat.
Dokumentdatabaser är absolut inte den bästa lösningen på alla databasproblem, men när man känner att man får bråka med en relationsdatabas för att får till affärsnyttan kan en dokumentdatabas absolut göra livet lättare.
Ett par exempel är tex. fakturor och ordrar där man måste spara orginaldata oavsett vad som händer med tex. adresser och produkter. Webbsidor där man lätt hamnar i flera tiotals frågor och/eller joinar för att få rätt data från en RDBMS är en annan bra kandidat till dokumentdatabas.
Ett scenario som jag tror jag kommer hamna i ganska snart är att samla in data i ‘realtid’. Data som kan se lite olika ut och som kommer att förändras över tid. Där tror jag dokumentdatabaser eller key value stores kommer göra ett bra jobb.
RavenDB
RavenDB är skriven i .Net för .Net. Det finns ett http-baserat rest-api, men .Net klienten är en enhet med servern.
Man använder Linq för att ställa frågor till servern och man använder Linq för att definiera egna index samt MapReduce.
Ett intressant sätt att börja arbeta med RavenDB är att använda den som en ‘write behind cache’. Eftersom RavenDB är ACID kan vara säker på att sparat data verkligen finns kvar. Sedan kan man låta RavenDB skriva till en traditionell SQL-server i bakgrunden i när den har tid. Funktionerna för att transformera data i de fallen skrivs i javascript.
Om två användare försöker förändra samma dokument kommer den som sparade först få igenom sin ändring. Användare nummer två måste hämta om den nya senaste versionen av dokumentet och göra en uppdatering av det.
RavenDB stödjer distribuerade transaktioner via .Net till skillnad mot de andra alternativen där man själv får hantera kompenserande transaktioner.
MapReduce är ett sätt att distribuera hantering av frågor mot stora datamängder. Det kommer från en avhandling som Google publicerat. Det går i princip ut på att man projicerar data på ett sätt som en filtrerings-/ behandlingsmetod vill se det och som den dessutom kommer att returnera. På så sätt kan resultatet av en filtrering/behandling skickas vidare till samma filtrering/behandling någon annanstans. På så sätt kan man till exempel summera alla transaktioner av en viss typ på alla servrar i ett kluster oberoende av varandra för att sedan samla ihop de olika resultaten och göra en sista behandling innan man returnerar resultatet till användaren.
‘Safe by default’ betyder att utvecklarna av RavenDB tagit en massa beslut om vad som är ett vettigt sätt att använda databasen. Man får tex. inte, utan att mecka på servern, tillbaka mer än 128 svar oavsett hur mycket data som sparats i databasen. Man får inte ställa mer är 30 frågor under en session. Fråga nummer 31 kommer att ignoreras. Ett sätt att komma runt det är att batcha frågor och uppdateringar.
Lucene är en motor för att hantera fritextsökningar. RavenDB inkluderar Lucene vilket gör att fritextsökningar mot ditt data sker nästan på samma sätt som vanliga sökningar. RavenDB använder sina sparade index för att populera sitt Lucene-index.
På kursen kopplade vi ihop sju arbetsstationer för att testa replikering och shardning). Det gick otroligt smidigt och det var ganska lätt att se till att data från tex. samma geografiska område lagras på samma server.