DotNetToscana: NoSQL Revolution - RavenDB
Upcoming SlideShare
Loading in...5
×
 

DotNetToscana: NoSQL Revolution - RavenDB

on

  • 451 views

http://www.dotnettoscana.org/nosql-revolution.aspx

http://www.dotnettoscana.org/nosql-revolution.aspx

Statistics

Views

Total Views
451
Slideshare-icon Views on SlideShare
449
Embed Views
2

Actions

Likes
0
Downloads
2
Comments
0

1 Embed 2

http://www.slashdocs.com 2

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • https://github.com/ravendb/ravendb/pull/408

DotNetToscana: NoSQL Revolution - RavenDB DotNetToscana: NoSQL Revolution - RavenDB Presentation Transcript

  • NoSQL revolution An introduction to the NoSQL world with real life examples using RavenDB and RedisMatteo Baglinihttp://it.linkedin.com/in/matteobaglini www.dotnettoscana.orgNicola Baldihttp://it.linkedin.com/in/nicolabaldiLuigi Berrettinihttp://it.linkedin.com/in/luigiberrettini 15/12/2012
  • The movement
  • Document databases in practiceNicola Baldihttp://it.linkedin.com/in/nicolabaldiLuigi Berrettinihttp://it.linkedin.com/in/luigiberrettini
  • Overview15/12/2012 Document databases in practice 4
  • Unbounded result sets problem Unbounded number of requests problem15/12/2012 Document databases in practice - Overview 5
  •  They favor denormalization over composition and joins  Relations are different than in RDBMSs  They are schema-less, but attention should be paid in designing documents15/12/2012 Document databases in practice - Overview 6
  • « a conceptual model should be drawn with little or no regard for the software that might implement it » (Martin Fowler, UML Distilled) A domain model should be independent from implementation details like persistence In RavenDB this is somewhat true15/12/2012 Document databases in practice - Overview 7
  •  RDBMS are schema-full • tuples = sets of key-value pairs ⇒ flat structure • more complex data structures are stored as relations  Document databases are schema-less • object graphs stored as docs ⇒ no flat structure • each document is treated as a single entity RavenDB suggested approach is to follow the aggregate pattern from the DDD book15/12/2012 Document databases in practice - Overview 8
  • ENTITY  Some objects are not defined primarily by their attributes  They represent a thread of identity that runs through time and often across distinct representations  Mistaken identity can lead to data corruption15/12/2012 Document databases in practice - Overview 9
  • VALUE OBJECT When you care only about the attributes of an element of the model, classify it as a value object Make it express the meaning of the attributes it conveys and give it related functionality Treat the value object as immutable Dont give it any identity and avoid the design complexities necessary to maintain entities15/12/2012 Document databases in practice - Overview 10
  • AGGREGATE  Invariants are consistency rules that must be maintained whenever data changes  They’ll involve relationships within an aggregate (relations & foreign keys: order / orderlines)  Invariants applied within an aggregate will be enforced with the completion of each transaction15/12/2012 Document databases in practice - Overview 11
  •  Cluster entities and value objects into aggregates and define boundaries around each Choose one entity to be the root of each aggregate and control all access to the objects inside the boundary through the root Allow external objects to hold references to the root only Transient references to internal members can be passed out for use within a single operation only15/12/2012 Document databases in practice - Overview 12
  •  Because the root controls access, it cannot be blindsided by changes to the internals  This arrangement makes it practical to enforce all invariants for objects in the aggregate and for the aggregate as a whole in any state change15/12/2012 Document databases in practice - Overview 13
  • Nested child document15/12/2012 Document databases in practice - Overview 14
  • Document referenced by ID15/12/2012 Document databases in practice - Overview 15
  • Denormalized reference  we clone properties that we care about when displaying or processing a containing document  avoids many cross document lookups and results in only the necessary data being transmitted over the network  it makes other scenarios more difficult: if we add frequently changing data, keeping details in synch could become very demanding on the server  use only for rarely changing data or for data that can be dereferenced by out-of-sync data15/12/2012 Document databases in practice - Overview 16
  • 15/12/2012 Document databases in practice - Overview 17
  • Order contains denormalized data from Customer and Product Full data are saved elsewhere15/12/2012 Document databases in practice - Overview 18
  • 15/12/2012 Document databases in practice - Overview 19
  • Querying15/12/2012 Document databases in practice 20
  •  DocumentStore • used to connect to a RavenDB data store • thread-safe • one instance per database per application  Session • used to perform operations on the database • not thread-safe • implements the Unit of Work pattern  in a single session, a single document (identified by its key) always resolves to the same instance  change tracking15/12/2012 Document databases in practice – Querying 21
  • 15/12/2012 Document databases in practice – Querying 22
  •  Sequential GUID key • when document key is not relevant (e.g. log entries) • entity Id = sequential GUID (sorts well for indexing) • Id property missing / not set ⇒ server generates a key Identity key • entity Id = prefix + next available integer Id for it • Id property set to a prefix = value ending with slash • new DocumentStore ⇒ server sends a range of HiLo keys Assign a key yourself • for documents which already have native id (e.g. users)15/12/2012 Document databases in practice – Querying 23
  • 15/12/2012 Document databases in practice – Querying 24
  •  soft-limit = 128 no Take() replaced by Take(128)  hard-limit = 1024 if x > 1024 Take(x) returns 1024 documents15/12/2012 Document databases in practice – Querying 25
  •  RavenDB can skip over some results internally ⇒ TotalResults value invalidated  For proper paging use SkippedResults: Skip(currentPage * pageSize + SkippedResults)  Assuming a page size of 10…15/12/2012 Document databases in practice – Querying 26
  • 15/12/2012 Document databases in practice – Querying 27
  • 15/12/2012 Document databases in practice – Querying 28
  •  RavenDB supports Count and Distinct  SelectMany, GroupBy and Join are not supported  The let keyword is not supported  For such operations an index is needed15/12/2012 Document databases in practice – Querying 29
  • All queries use an index to return results  Dynamic = created automatically by the server  Static = created explicitly by the user15/12/2012 Document databases in practice – Querying 30
  •  no matching static index to query ⇒ RavenDB automatically creates a dynamic index on the fly (on first user query)  based on requests coming in, RavenDB can decide to promote a temporary index to a permanent one15/12/2012 Document databases in practice – Querying 31
  •  permanent  expose much more functionality  low latency: on first run dynamic indexes have performance issues  map / reduce15/12/2012 Document databases in practice – Querying 32
  • 15/12/2012 Document databases in practice – Querying 33
  • 15/12/2012 Document databases in practice – Querying 34
  • 15/12/2012 Document databases in practice – Querying 35
  • Advanced topics15/12/2012 Document databases in practice 36
  •  an index is made of documents  document • atomic unit of indexing and searching • flat ⇒ recursion and joins must be denormalized • flexible schema • made of fields15/12/2012 Document databases in practice – Advanced topics 37
  •  field • a name-value pair with associated info • can be indexed if youre going to search on it ⇒ tokenization by analysis • can be stored in order to preserve original untokenized value within document  example of physical index structure {“__document_id”: “docs/1”, “tag”: “NoSQL”}15/12/2012 Document databases in practice – Advanced topics 38
  • 15/12/2012 Document databases in practice - Overview 39
  • 15/12/2012 Document databases in practice – Advanced topics 40
  • 15/12/2012 Document databases in practice – Advanced topics 41
  • One to one15/12/2012 Document databases in practice – Advanced topics 42
  • One to many ⇒ SELECT N+115/12/2012 Document databases in practice – Advanced topics 43
  • Value type15/12/2012 Document databases in practice – Advanced topics 44
  •  indexing: thread executed on creation or update server responds quickly BUT you may query stale indexes (better stale than offline)15/12/2012 Document databases in practice – Advanced topics 45
  • 15/12/2012 Document databases in practice – Advanced topics 46
  • documentStore.Conventions.DefaultQueryingConsistency  ConsistencyOptions.QueryYourWrites same behavior of WaitForNonStaleResultsAsOfLastWrite  ConsistencyOptions.MonotonicRead you never go back in time and read older data than what you have already seen15/12/2012 Document databases in practice – Advanced topics 47
  • 15/12/2012 Document databases in practice - Overview 48
  • 15/12/2012 Document databases in practice - Overview 49
  • 15/12/2012 Document databases in practice - Overview 50
  • Key-value databases in practice