Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
NoSQL revolution   An introduction to the NoSQL world with real life          examples using RavenDB and RedisMatteo Bagli...
The   movement
Document databases in practiceNicola Baldihttp://it.linkedin.com/in/nicolabaldiLuigi Berrettinihttp://it.linkedin.com/in/l...
Overview15/12/2012    Document databases in practice   4
Unbounded result sets problem             Unbounded number of requests problem15/12/2012              Document databases i...
 They favor denormalization over             composition and joins       Relations are different than in RDBMSs       T...
« a conceptual model should be drawn with      little or no regard for the software that might      implement it » (Martin...
 RDBMS are schema-full       • tuples = sets of key-value pairs ⇒ flat structure       • more complex data structures are...
ENTITY     Some objects are not defined primarily by       their attributes     They represent a thread of identity that...
VALUE OBJECT When you care only about the attributes of an    element of the model, classify it as a value object Make i...
AGGREGATE     Invariants are consistency rules that must be       maintained whenever data changes     They’ll involve r...
 Cluster entities and value objects into aggregates    and define boundaries around each Choose one entity to be the roo...
 Because the root controls access, it cannot        be blindsided by changes to the internals     This arrangement makes...
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 ...
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 databa...
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...
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...
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 doc...
 RavenDB can skip over some results internally       ⇒ TotalResults value invalidated     For proper paging use SkippedR...
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 ...
All queries use an index to return results    Dynamic = created automatically by the server    Static = created explicit...
 no matching static index to query ⇒ RavenDB      automatically creates a dynamic index on the      fly (on first user qu...
 permanent     expose much more functionality     low latency: on first run dynamic indexes       have performance issu...
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 ⇒ recursi...
 field       • a name-value pair with associated info       • can be indexed if youre going to search on it         ⇒ tok...
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 stal...
15/12/2012   Document databases in practice – Advanced topics   46
documentStore.Conventions.DefaultQueryingConsistency     ConsistencyOptions.QueryYourWrites       same behavior of       ...
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
Upcoming SlideShare
Loading in …5
×

DotNetToscana: NoSQL Revolution - RavenDB

617 views

Published on

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

Published in: Technology
  • Be the first to comment

DotNetToscana: NoSQL Revolution - RavenDB

  1. 1. 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
  2. 2. The movement
  3. 3. Document databases in practiceNicola Baldihttp://it.linkedin.com/in/nicolabaldiLuigi Berrettinihttp://it.linkedin.com/in/luigiberrettini
  4. 4. Overview15/12/2012 Document databases in practice 4
  5. 5. Unbounded result sets problem Unbounded number of requests problem15/12/2012 Document databases in practice - Overview 5
  6. 6.  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
  7. 7. « 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
  8. 8.  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
  9. 9. 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
  10. 10. 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
  11. 11. 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
  12. 12.  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
  13. 13.  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
  14. 14. Nested child document15/12/2012 Document databases in practice - Overview 14
  15. 15. Document referenced by ID15/12/2012 Document databases in practice - Overview 15
  16. 16. 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
  17. 17. 15/12/2012 Document databases in practice - Overview 17
  18. 18. Order contains denormalized data from Customer and Product Full data are saved elsewhere15/12/2012 Document databases in practice - Overview 18
  19. 19. 15/12/2012 Document databases in practice - Overview 19
  20. 20. Querying15/12/2012 Document databases in practice 20
  21. 21.  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
  22. 22. 15/12/2012 Document databases in practice – Querying 22
  23. 23.  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
  24. 24. 15/12/2012 Document databases in practice – Querying 24
  25. 25.  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
  26. 26.  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
  27. 27. 15/12/2012 Document databases in practice – Querying 27
  28. 28. 15/12/2012 Document databases in practice – Querying 28
  29. 29.  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
  30. 30. 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
  31. 31.  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
  32. 32.  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
  33. 33. 15/12/2012 Document databases in practice – Querying 33
  34. 34. 15/12/2012 Document databases in practice – Querying 34
  35. 35. 15/12/2012 Document databases in practice – Querying 35
  36. 36. Advanced topics15/12/2012 Document databases in practice 36
  37. 37.  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
  38. 38.  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
  39. 39. 15/12/2012 Document databases in practice - Overview 39
  40. 40. 15/12/2012 Document databases in practice – Advanced topics 40
  41. 41. 15/12/2012 Document databases in practice – Advanced topics 41
  42. 42. One to one15/12/2012 Document databases in practice – Advanced topics 42
  43. 43. One to many ⇒ SELECT N+115/12/2012 Document databases in practice – Advanced topics 43
  44. 44. Value type15/12/2012 Document databases in practice – Advanced topics 44
  45. 45.  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
  46. 46. 15/12/2012 Document databases in practice – Advanced topics 46
  47. 47. 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
  48. 48. 15/12/2012 Document databases in practice - Overview 48
  49. 49. 15/12/2012 Document databases in practice - Overview 49
  50. 50. 15/12/2012 Document databases in practice - Overview 50
  51. 51. Key-value databases in practice

×