To be relational, or not ?             Thats not the question!   @sbtourist aka sergio bossa   @alexsnaps aka alex snaps  ...
Agenda   Act 1 – Relational databases:      a difficult love affair.   Interlude 1 – Problems in the modern era:       big...
About us   Sergio Bossa         Software Engineer at Bwin Italy.         Long time open source contributor.         (Micro...
Act I             Relational databases   A difficult love affair …                                    sergio bossa & alex ...
The relational model   Defines constraints         Finite model           aka relation variable, relation or table        ...
The ACID guarantees   Let people easily reason about the problem.         Atomic.               We see all changes, or no ...
The SQL ubiquity   SQL is everywhere         Still trying to figure out why my blog           uses a relational database t...
Interlude 1   Problems of  the Modern Era                                 sergio bossa & alex snaps - @sbtourist & @alexsn...
Big Data   Whats Big Data for you?   Not a question of quantity.         Gigabytes?         Terabytes?         Petabytes? ...
CAP Theorem   Year 2000: Formulated by Eric Brewer.   Year 2002: Demonstrated by Lynch and Gilbert.   Nowadays: A religion...
Act II   Non-relational databases   Love is in the air                              sergio bossa & alex snaps - @sbtourist...
Non-relational databases                           From the origins to the current explosion...                           ...
Data Model (1)     Column-family.           Key-identified rows             with a sparse number of columns.           Col...
Data Model (2)           Graph.                 Vertices represent your data.                 Edges represent meaningful r...
Data Model (3)           Document.                 Schemaless documents.                        With denormalized data.   ...
Data Model (4)           Key/Value.                 Opaque values.                 Maximize flexibility.                 E...
Consistency Model (1)           Strict (Sequential) Consistency.                 Every read/write operation act on either:...
Consistency Model (2)           Eventual Consistency.                 All read/write operations will eventually reach     ...
Partitioning (1)           Client-side partitioning.                 Every server is self-contained.                 Clien...
Partitioning (2) Server-side partitioning.       Servers automatically partition data.       Consistent-hashing, ring-base...
Replication (1)           Master/Slave.                 Master propagates changes to slaves.                        Log re...
Replication (2)           N-Replication.                 Nodes are all peers.                        No master, no slaves....
Processing               A distributed system is built by:                           Moving data toward its behavior.     ...
CAP - Problem   CAP Theorem.         Consistency.         Availability.         Partition tolerance.         Pick two.    ...
CAP - Trade-offs           Consistency + Availability.                 Requests will wait until partitions heal.          ...
Interlude II   Relational or non-relational?    Not the correct question!                                    sergio bossa ...
Relational or non-relational? Not the correct question!   Freedom to build the right solution for your problems.   Freedom...
Act III   Building scalable apps                            sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 ...
Building scalable apps   Relational databases                                      sergio bossa & alex snaps - @sbtourist ...
Scaling out...           Adding app servers will work...             ... for a little while!           But at some point w...
Master-Slave   One master         gets all the writes         replicates to slaves   Slaves (& master)         gets the re...
Master-Master           Multiple masters                 Writes & reads all participants           Writes are replicated t...
Vertical Partitioning           Data is split across multiple database servers based               on                 The ...
Horizontal partitioning           Data is split across multiple database servers based on                 Key sharding    ...
Building scalable apps   Caching                                      sergio bossa & alex snaps - @sbtourist & @alexsnapsS...
Caching           If going to the database is so               expensive...               ... we should just avoid it!    ...
Distributed Caching           What if data isnt perfectly partitioned ?           How do we keep this all in sync ?       ...
Distributed Caching           Cached data remains close to the              processing unit                               ...
Distributed Caching                                                   RDBMS                                               ...
Distributed Caching                             SLOWER                         LARGER                                     ...
Distributed Caching                            SLOWER                                                  LARGER             ...
Distributed Caching                                                    Weve scaled our reads                              ...
Write-behind Cache   Rather than write changes directly to the slowest participant         Write to fastest durable store ...
Write-through                                           RDBMS                                           Cache             ...
Write-through                                           RDBMS                                           Cache             ...
Write-through                                           RDBMS                                           Cache             ...
Write-through                                           RDBMS                                           Cache             ...
Write-behind                                          RDBMS                                          Cache                ...
Write-behind                                          RDBMS                                          Cache                ...
Write-behind                                          RDBMS                                          Cache      Writer    ...
Write-behind                                          RDBMS                                          Cache      Writer    ...
Write-behind                                          RDBMS                                          Cache      Writer    ...
Write-behind                                          RDBMS                                          Cache      Writer    ...
Write-behind                                          RDBMS                                          Cache      Writer    ...
Write-behind                                          RDBMS                                          Cache      Writer    ...
Write-behind                                          RDBMS                                          Cache      Writer    ...
Write-behind                                          RDBMS                                                     Writer    ...
Write-behind                                          RDBMS                                                     Writer    ...
Building scalable apps   Non-relational databases                                      sergio bossa & alex snaps - @sbtour...
The case for non-relationals           Weve seen how to scale our relational database.           Weve seen how to add cach...
Rich Data   Frequent schema changes.         Relational databases          cannot easily handle table modifications.      ...
Runtime Data   Poorly structured data.         Relational model           doesnt fit unstructured data.               Unle...
Massive Data   Large quantity of data.         Relational databases are typically single instance.               Otherwise...
Building scalable apps   Multi-paradigm                                      sergio bossa & alex snaps - @sbtourist & @ale...
A case for multi-paradigm: CQRS                                                          sergio bossa & alex snaps - @sbto...
CQRS - Explained           Command Store.                  Strictly modeled after the problem domain.                  Com...
What about stores implementation?                                          sergio bossa & alex snaps - @sbtourist & @alexs...
Introducing Ehcache           Started in 2003 by Greg Luck           Apache 2.0 License           Integrated by lots of pr...
Introducing Ehcache 2.4           New Search API           New consistency modes           New transactional modes        ...
Ehcache & Terracotta   Terabyte scale with minimal footprint   Server array with striping for linear scale   High availabi...
Introducing Terrastore   Document Store.         Ubiquitous.         Consistent.         Distributed.         Scalable.   ...
Terrastore Architecture                                                  sergio bossa & alex snaps - @sbtourist & @alexsna...
CQRS - Implemented                                             sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday...
CQRS - Implemented   Command Store.         Express your domain as an object model.         Process and store it with Ehca...
The end   Be a polyglot!                        sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
Conclusion   Be polyglot         Go out and play with all this         Know your options (all of them)   Understand your d...
Creative Commons by wwworks                                                      sergio bossa & alex snaps - @sbtourist & ...
More info   www.ehcache.org   www.terracotta.org   code.google.com/p/terrastore                                    sergio ...
Upcoming SlideShare
Loading in...5
×

To be relational, or not to be relational? That's *not* the question!

1,213

Published on

La presentazione di Alex Snaps e Sergio Bossa,
in occasione del Codemotion, Roma 5 marzo 2011 http://www.codemotion.it

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,213
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Transcript of "To be relational, or not to be relational? That's *not* the question! "

  1. 1. To be relational, or not ? Thats not the question! @sbtourist aka sergio bossa @alexsnaps aka alex snaps sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  2. 2. Agenda Act 1 – Relational databases: a difficult love affair. Interlude 1 – Problems in the modern era: big data and the CAP theorem. Act 2 : Non-relational databases: love is in the air. Interlude 2 : Relational or non-relational? Not the correct question. Act 3 : Building scalable apps. The End sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  3. 3. About us Sergio Bossa Software Engineer at Bwin Italy. Long time open source contributor. (Micro)Blogger - @sbtourist. Alex Snaps Software engineer at Terracotta … … after 10 years of industry experience. www.codespot.net — @alexsnaps sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  4. 4. Act I Relational databases A difficult love affair … sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  5. 5. The relational model Defines constraints Finite model aka relation variable, relation or table Candidate keys Foreign keys Queries are relations themselves Heading & body SQL differs slightly from the "pure" relational model sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  6. 6. The ACID guarantees Let people easily reason about the problem. Atomic. We see all changes, or no changes at all. Consistent. Changes respect our rules and constraints. Isolated. We see all changes as independently happening. Durable. We keep the effect of our changes forever. Fits a simplified model of our reality. sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  7. 7. The SQL ubiquity SQL is everywhere Still trying to figure out why my blog uses a relational database to be honest SQL is known by everyone Raise your hand if youve never written a SQL query ... and if you dont want to ORM are there for you ActiveRecord if youre into Rails Simple persistence for all our objects! sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  8. 8. Interlude 1 Problems of  the Modern Era sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  9. 9. Big Data Whats Big Data for you? Not a question of quantity. Gigabytes? Terabytes? Petabytes? Its all about supporting your business growth. Growth in terms of schema evolution. Growth in terms of data storage. Growth in terms of data processing. Is your data stack capable of handling such a growth? sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  10. 10. CAP Theorem Year 2000: Formulated by Eric Brewer. Year 2002: Demonstrated by Lynch and Gilbert. Nowadays: A religion for many distributed system guys. CAP Theorem in a few words: Consistency. Availability. Partition-Tolerance. Pick (at most) two. More later. sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  11. 11. Act II Non-relational databases Love is in the air sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  12. 12. Non-relational databases From the origins to the current explosion... How do they differ? sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  13. 13. Data Model (1) Column-family. Key-identified rows with a sparse number of columns. Columns grouped in families. Multiple families for the same key. Dynamically add/remove columns. Efficiently access same-family columns sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  14. 14. Data Model (2) Graph. Vertices represent your data. Edges represent meaningful relations between nodes. Key/Value properties attached to both. Indexed properties. Efficient traversal. sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  15. 15. Data Model (3) Document. Schemaless documents. With denormalized data. Stored as a whole unit. Clients can update/query contents. sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  16. 16. Data Model (4) Key/Value. Opaque values. Maximize flexibility. Efficiently store and retrieve by key. sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  17. 17. Consistency Model (1) Strict (Sequential) Consistency. Every read/write operation act on either: The last value read. The last value written. sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  18. 18. Consistency Model (2) Eventual Consistency. All read/write operations will eventually reach consistent state. Stale data may be served. Versions may diverge. Repair may be needed. sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  19. 19. Partitioning (1) Client-side partitioning. Every server is self-contained. Clients partition data per-request. sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  20. 20. Partitioning (2) Server-side partitioning. Servers automatically partition data. Consistent-hashing, ring-based is the most used. sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  21. 21. Replication (1) Master/Slave. Master propagates changes to slaves. Log replication. Statement replication. Slaves may take over master in case of failures. sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  22. 22. Replication (2) N-Replication. Nodes are all peers. No master, no slaves. Each node replicates its data to a subset (N) of nodes. sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  23. 23. Processing A distributed system is built by: Moving data toward its behavior. ... or ... Moving behavior toward its data. An efficient distributed system is built by: Moving behavior toward its data. Map/Reduce is the most common and efficient. sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  24. 24. CAP - Problem CAP Theorem. Consistency. Availability. Partition tolerance. Pick two. Do you remember? Makes sense only when dealing with partitions/failures ... sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  25. 25. CAP - Trade-offs Consistency + Availability. Requests will wait until partitions heal. Full consistency. Full availability. Max latency. Consistency + Partition tolerance. Some requests will act on partial data. Some requests will be refused. Full consistency. Reduced availability. Min latency. Availability + Partition tolerance. All requests will be fulfilled. Sacrifice consistency. Max availability. Min latency. sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  26. 26. Interlude II Relational or non-relational?  Not the correct question! sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  27. 27. Relational or non-relational? Not the correct question! Freedom to build the right solution for your problems. Freedom to scale your solution as your problems scale. Know your use case. Understand the problem domain, then choose technology. Know your data. Understand your data and data access patterns, then choose technology. Know your tools. Understand available tools, dont go blind. Pick the simple solution. Choose the simpler technology that works for your problem. Build on that. sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  28. 28. Act III Building scalable apps sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  29. 29. Building scalable apps Relational databases sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  30. 30. Scaling out... Adding app servers will work... ... for a little while! But at some point we need to scale the database as well RDBMS WRITE READ PowerBook G4 PowerBook G4 PowerBook G4 sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  31. 31. Master-Slave One master gets all the writes replicates to slaves Slaves (& master) gets the read operations We didnt really scale writes  Static topology SPOF remains sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  32. 32. Master-Master Multiple masters Writes & reads all participants Writes are replicated to masters Synchronously Expensive 2PC Asynchronously Conflicts have to be resolved Complex Static topology Limited performance again Solved SPOF, sort of… sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  33. 33. Vertical Partitioning Data is split across multiple database servers based on The functional area Joins are moved to the application Not relational anymore SPOF back What about one functional area growing "out of hand" ? sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  34. 34. Horizontal partitioning Data is split across multiple database servers based on Key sharding Joins are moved to the application Not relational anymore SPOF back What about one functional area growing "out of hand" ? Routing required Wheres Order#123 ? sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  35. 35. Building scalable apps Caching sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  36. 36. Caching If going to the database is so expensive... ... we should just avoid it! Put a cache in front of the database Data remains closer to processing unit If needed, distribute sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  37. 37. Distributed Caching What if data isnt perfectly partitioned ? How do we keep this all in sync ? RDBMS WRITE Peer-to-peer ? READ Cache Cache Cache PowerBook G4 PowerBook G4 PowerBook G4 sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  38. 38. Distributed Caching Cached data remains close to the processing unit RDBMS Central unit L2 orchestrates it all L1 L1 L1 PowerBook G4 PowerBook G4 PowerBook G4 sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  39. 39. Distributed Caching RDBMS L2 L1 L1 L1 PowerBook G4 PowerBook G4 PowerBook G4 sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  40. 40. Distributed Caching SLOWER LARGER RAM L2 L1 L1 L1 Core Core Core FASTER SMALLER sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  41. 41. Distributed Caching SLOWER LARGER RDBMS L2 L1 L1 L1 FASTER PowerBook G4 PowerBook G4 PowerBook G4 SMALLER sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  42. 42. Distributed Caching Weve scaled our reads But what about writes ? SLOWER LARGER RDBMS L2 L1 L1 L1 FASTER PowerBook G4 PowerBook G4 PowerBook G4 SMALLER sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  43. 43. Write-behind Cache Rather than write changes directly to the slowest participant Write to fastest durable store (persistent queue) required for recovery in the face of failure Only write to database later in batches and/or coalesced while still controlling the lag the load on the database In a distributed environment handling failures  we enforce happens at least once  loosens the contract vs. "once and only once"! sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  44. 44. Write-through RDBMS Cache Application code sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  45. 45. Write-through RDBMS Cache Application code sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  46. 46. Write-through RDBMS Cache Application code sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  47. 47. Write-through RDBMS Cache Application code sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  48. 48. Write-behind RDBMS Cache Application code sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  49. 49. Write-behind RDBMS Cache Application code sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  50. 50. Write-behind RDBMS Cache Writer Application code sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  51. 51. Write-behind RDBMS Cache Writer Application code sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  52. 52. Write-behind RDBMS Cache Writer Application code sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  53. 53. Write-behind RDBMS Cache Writer Application code sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  54. 54. Write-behind RDBMS Cache Writer Application code sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  55. 55. Write-behind RDBMS Cache Writer Application code sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  56. 56. Write-behind RDBMS Cache Writer Application code sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  57. 57. Write-behind RDBMS Writer Cache Writer Application code sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  58. 58. Write-behind RDBMS Writer Cache Writer Application code sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  59. 59. Building scalable apps Non-relational databases sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  60. 60. The case for non-relationals Weve seen how to scale our relational database. Weve seen how to add caching. Weve seen how to make caching scale. So why going non-relational? A matter of use case sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  61. 61. Rich Data Frequent schema changes. Relational databases cannot easily handle table modifications. Column, Document and Graph databases can. Tracking/Processing of large relations. Relational databases keep and traverse table relations by foreign-key joins. Joins are expensive. Graph databases provide cheap and fast traversal operations. sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  62. 62. Runtime Data Poorly structured data. Relational model doesnt fit unstructured data. Unless you want BLOBs. Non-relational databases provide more flexible models. Throw-away data. Relational databases provide maximum data durability. But not all kind of data are the same. When you can afford to possibly lose some data, non-relational databases let you trade durability for higher flexibility and performance. sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  63. 63. Massive Data Large quantity of data. Relational databases are typically single instance. Otherwise cost too much. Choose a partitioned non-relational database. High volume of writes. Scaling writes with relational databases is difficult. Even if using write-behind caching. Choose a partitioned non-relational database. Eventual consistency may also help. Complex, aggregated, queries. Complex aggregations and queries are expensive in standard relational databases. Remember joins? Choose a non-relational database supporting distributed data processing. Hint: Map/Reduce. sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  64. 64. Building scalable apps Multi-paradigm sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  65. 65. A case for multi-paradigm: CQRS sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  66. 66. CQRS - Explained Command Store. Strictly modeled after the problem domain. Commands model domain changes. Domain changes cause events publishing. Query Store. Fed by published events. Strictly modeled after the user interface. Possibly denormalized to accommodate queries. Offline Store. Fed by published events. Strictly modeled after processing needs. Business Intelligence. Reporting. Statistical aggregations, … sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  67. 67. What about stores implementation? sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  68. 68. Introducing Ehcache Started in 2003 by Greg Luck Apache 2.0 License Integrated by lots of projects, products Hibernate Provider implemented 2003 Web Caching 2004 Distributed Caching 2006 REST and SOAP APIs 2008 Acquired by Terracotta Sept. 2009 sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  69. 69. Introducing Ehcache 2.4 New Search API New consistency modes New transactional modes Still: Small memory footprint Cache Writers JTA Bulk load Grows with your application with only two lines of configuration Scale Up - BigMemory (100’s of Gig, in process, NO GC) Scale Out - Clustering Platform (Up to 2 Terabytes, HA) sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  70. 70. Ehcache & Terracotta Terabyte scale with minimal footprint Server array with striping for linear scale High availability High performance data persistence In-memory performance as you scale sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  71. 71. Introducing Terrastore Document Store. Ubiquitous. Consistent. Distributed. Scalable. Written in Java. Based on Terracotta. Open Source. Apache-licensed. sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  72. 72. Terrastore Architecture sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  73. 73. CQRS - Implemented sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  74. 74. CQRS - Implemented Command Store. Express your domain as an object model. Process and store it with Ehcache and Terracotta. Optionally write it back to a relational database. Query Store. Map queries to user (screen) views. Map views to JSON documents. Store and get them back with Terrastore. Offline Store. Collect data from input commands. Keep data denormalized. Aggregate and process with Terrastore Map/Reduce. sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  75. 75. The end Be a polyglot! sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  76. 76. Conclusion Be polyglot Go out and play with all this Know your options (all of them) Understand your domain It’s current and future requirements Be wise, and choose well! sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  77. 77. Creative Commons by wwworks sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011
  78. 78. More info www.ehcache.org www.terracotta.org code.google.com/p/terrastore sergio bossa & alex snaps - @sbtourist & @alexsnapsSaturday 5 March 2011

×