�ݺ�ߣ

Editor's Notes

• #2: Inledning om datalagring och bakgrunden till NoSQL - 2 minDatalagring har länge varit synonymt med Relationsdatabaser.Det har varit så sedanEdgar Codd publicerade sin artikel om relationsmodeller 1970. Men relationsdatabaser är bra. Extremt bra. SQL Server är ett exempel på en fantastisk relationsdatabas och den går att använda till nästan vad som helst. Men den kanske inte är utmärkt för alla uppgifter. Den är ju relationell medan de flesta av oss arbetar med objektorientering. Och vi har på så många sätt försökt få ner våra objektorienterade modeller i dessa relationsmodeller. Det är verkligen dags att titta på ett alternativ.Den här presentationen handlar om RavenDb, som är ett alternativ.
• #3: RavenDb är en dokumentdatabas.
• #4: Innan vi svarar på det bör vi reda ut vad ett dokument är.
• #5: Vad är dokument för en dokumentdatabas?Ett dokument är data som är representerad i XML, Json eller något annat strukturerat format. RavenDb använder Json.Dokument är oberoende och är schemalösa.Dokument är inte platta. Ett dokument kan representera en hel objekt-hierarki.
• #6: Det här är mycket enkelt exempel på ett dokument.Dokument är oberoende och schemafria, vilket betyder att jag kan lägga till ett dokument som har en egenskap mer än det befintliga dokumentet samtidigt som jag fortfarande kan behandla dem tillsammans i operationer i databasen.Dessa två objekt är serialiserade in i RavenDb från helt vanliga C# Pocos. Inga attribut eller basklasser krävs.Dessutom kommer det att gå att läsa ut det första dokumentet in i den nya klassens struktur utan problem.
• #7: Ett lite mer komplext exempel som också visar på att man kan spara objektshierarkier i dokumenten. Men även om dokumenten är schemafria, betyder inte det att man inte ska lägga ner lite tid på att fundera på sin datastruktur.
• #8: User-dokument är platt, medan Photo-dokumentet har en lista med tags som i en relationsvärlds skulle kräva en extra tabell. Photo-dokumentet har också en relation till User-dokumentet. RavenDb tillåter att man lagrar hierarkier, men hanterar inte referenser särskilt bra. Det finns ett visst stöd för joins, genom något som kallas includes, men det är inte alls jämförbart med joins i den relationella världen. Dokument bör vara root aggregates.Dokument bör stanna inom en transaktionell gräns.
• #9: Så vad är en dokumentdatabas nu när vi vet vad dokument är?En dokumentdatabas är i grunden en Key / Value store. En key / value store tillåter att man sparar data baserat på en nyckel. För att läsa, anger man bara nyckeln. Key / Value stores har ofta extremt bra prestanda just för att man kan optimera hanteringen av nycklarna. Dessutom är det väldigt gynnsamt att skala key / value stores eftersom prestandan inte påverkas av varken mängden data eller antalet noder som finns. Nackdelen är att Value ofta är en blob, vilket gör att det är upp till klienten att känna till vad Value egentligen är. Dessutom kan man bara läsa genom nyckeln, vilket gör att klienten måste hantera sekundära index för att kunna ställa mer komplicerade frågor.---Den fundamentala skillnaden mellan en key / value store och en dokumentdatabas är att dokumentdatabasenpå något sätt kan förstå vadValue är och utföra operationer på den datan.För en dokumentdatabas är Value alltså själva dokumentet.Vi kan fortfarande läsa genom nyckeln, vilket precis som för en vanlig Key / Value store är en extremt billig operation. Men dokumentdatabasen har en förmåga att läsa sin egen data och kan utföra operationer på sin data. Den kan till exempel hantera sina egna index, vilket gör att vi har ett mycket rikare sätt att ställa frågor mot den.
• #10: RavenDb är en dokumentdatabas utvecklad i .NET, i C#Den är byggd på HTTP och det är REST man använder.Den bygger upp sina index med hjälp av Lucene.NETDen har en LINQ-provider som gör frågor väldigt naturliga för en van .NET-utvecklare.Den har ett i närmast självförklarande klient-APIDen är safe by defaultDen har utbyggnadsmöjligheter i form av triggers och listeners.Den går att köra på Windows.Jämför med Couch.
• #11: RavenDb har en egen HTTP Server som implementerar det REST-interface som man använder för att kommunicera med den.Den har ett antal background workers. En för indexeringEn för reduceEn för övriga tasks.Dokument och index sparas i två olika stores. Dokumenten är ju som bekant json och indexen är Lucene.Indexen sparas på disk enligt Lucen medan dokumenten sparas i ESENT eller Raven.Munin.ESENT är JET Blue som är samma databas som Exchange och Active Directory använder. Raven.Munin är en managed store. Alltså en native .NET store som är helt byggd med managed kod, vilket gör att den rent teoretiskt går att köra på alternativa plattformar.
• #12: Ladda ner senaste unstable��Stable, Unstable och Commercialpacka upp c:\\ravenDra igång, cmd.exeVisa Raven Studio��http://localhost:8080Skapa ett enkelt testdok, fråga efter det via http, deleteVisual Studio��- 4 minConsole app Skapa en documentStore Initialize documentStore using sessionSkapa en UserSparaVisa i studioLäs ut med LoadUppdatera FullnameSparaVisa i studioSkapa en till UserSparaVisa i StudioLäs ut med QueryEtt index skapas -> Nästa steg, IndexVänta lite nu. Vi har inte skapat något schema och vi har inte skapat några index. Hur går det här till egentligen?
• #13: Generellt om index i RavenDe processas server side och bygger på Lucene.NET. Index kan vara stale. De kanske inte är kompletta. Den underliggande datan är alltid korrekt, men indexen kan vara inkorrekta.Dynamiska / Temp / AutoSkapas när de används. Mycket bra jämfört med RMDBS, oindexerade fält, table scans.http://localhost:8080/indexes/dynamic/Usershttp://localhost:8080/indexes/dynamic/Users?query=UserName:M*http://localhost:8080/indexes/dynamic/Users?query=FullName:M*AutoEtt tempindex ändras till ett autoindex efter en viss tids användning.Map/ReduceMap/Reduce är en algoritm skapad av Google för att stödja distribuerad hantering av stora datamängder utspridda på många noder.Egentligen är Map/Reduce alternativt sätt att göra en GROUP BY på. Men distribuerat. Och med partitioner av datan.Det går ut på att man med en Map-funktion samlar den data man vill ta göra sin gruppering på. I Raven innebär det alltså att man frågar efter en del av ett dokument.Man tar sedan resultatet av Map-funktionen och skickar in det i Reduce-funktionen. Reduce-funktionens uppgift är att genomföra grupperingen. Det viktiga är att Reduce-funktionen returnerar samma sak som den tar emot och anledningen till det är att man i praktiken ska kunna köra Map Reduce på massor av noder eller partitioner av datan. Och eftersom datan är partitionerad kommer grupperingen inte lyckas eftersom en partition inte känner till grupperingsnycklarna i de andra partitionerna. De kan ske först när de är individuellt reducerade och därefter sammanslagna varpå man kör Reduce-funktionen igen när man har alla nycklarna.Exempel med folk:Dela in salen i två partitioner.Utse en räknare i varje partition.Ställ en binär fråga, höger eller vänster hand upp.Map: Ni har säkert en massa intressanta egenskaper, men jag vill enbart veta detta om er.Reduce: Gruppera på vilken hand som är uppe och räkna antalet av varje.Begär svar av räknarna.Upp i notepad med resultatet. Node 1 H 2 V 3 Node 2 H 1 V 2 Reduce H 3 V 5Kodexempel:PhotoTagCountIndexLive ProjectionsDokument är oberoende, vilket betyder att vi inte ska behöva ladda information från andra dokument för att hantera dem. Vi löser det normalt genom denormalisering av viss information. Men med denormalisering måste vi ta ansvar för att uppdatera den denormaliserade informationen, vilket kan bli lite jobbigt. För att komma runt det, finns fenomenet Live Projections vilket är motsvarigheten till en nested loop join i relationsvärden.I objektsmodellen har vi våra normaliserade PhotoVotes...Lucene.NETFuzzy, Range,
• #14: Single: När man skapar ett uppdaterar ett dokument körs den operation under en transaktion och skulle det bli fel någonstans, rullas allt tillbaka och ingen skada kan uppstå på Ravens interna filstruktur.Batch: Batchoperationer som sker under ett och samma anrop körs under samma transaktion. Om någon operation fallerar, rullas allt tillbaka.Multi operation: Operationer som exekveras i en multioperationstransaktion syns bara för den pågående transaktionen. Operationer i andra transaktioner eller operationer utan transaktioner ser inte förändringar förrän transaktionen är commitad. Alla dokument som modifieras av transaktionen låses, vilket innebär att de är läsbara av andra transaktioner, men om någon annan försöker modifiera dokumentet uppstår en konflikt.Partiella fel tillåts också utan att hela transaktionen rullas tillbaka. Partiella fel kan ske och korrigeras och man kan fortsätta med ytterligare operationer och slutligen committa. Det är viktigt att vet att transaktionen spänner över flera HTTP-anrop och det är möjligt genom att man använder en HTTP Header med ett unikt id.Cross shard:Med Ravens support för sharding, vilket tillåter att man delar upp data på flera instanser av databasen, tillåts också transaktioner över dessa shards. Det bygger på att man skickar samma HTTP Header till alla shards, vilket gör att operationer kan koordineras över flera shards samtidigt.
• #16: ShardingReplikering / IndexreplikeringRättigheter genom bundlePatchning är native i APIt.Versioning genom bundleExpiration genom bundleSet based operation
• #18: Slutplädering Vad ska man använda den till? Repository pattern = alla appar Event Sourcing Persistent ViewModels, Read Fördelar Många tunga features Extremt låg tröskel Nackdelar Litet community? Omogen?
• #23: Även om en mycket stark poäng med relationsdatabaser är att de inte skalar, är det inte något som många av oss har något problem med normalt. Anledningen att relationsdatabaser inte skalar är att de måste hålla full koll på sin data. Den måste vara vara consistent (konsekvent, överensstämmande, fast, jämn, följriktig) för att hålla koll på nycklar Consistency: Alla klienter ser samma data samtidigtAvailability: Felande noder påverkar inte andra noder, klienter kan alltid läsa och skrivaPartition Tolerance: Systemet fungerar bra även det är uppdelat på flera noder
• #24: Klient APIHTTPDocumentStoreIndexStoreEsent, JET Blue, Exchange, Active DirectoryManaged, Raven.Munin