To scale or not to scale: Key/Value, Document, SQL, JPA – What’s right for my app?
3 likes1,917 views
The document discusses the comparison between SQL and NoSQL databases, outlining their strengths, weaknesses, and use cases. It highlights the challenges of scaling SQL and presents NoSQL as a more flexible, distributed option suitable for varying data models. The author also introduces Gigaspaces as an in-memory data grid that supports a range of data access APIs for different applications.
![> SELECT * FROM devoxx2010.speakers WHERE name=‘Uri Cohen’+-----------------------------------------------------+| Name | Company | Role | Twitter |+-----------------------------------------------------+| Uri Cohen | GigaSpaces | Product Manager | @uri1803 |+-----------------------------------------------------+> db.devoxx_speakers.find({name:”Uri Cohen”}){ “name”:”Uri Cohen”, “company”: { name:”GigaSpaces”, products:[“XAP”, “IMDG”] domain: “In memory data grids” } “role”:”product manager”, “twitter”:”@uri1803”}](https://image.slidesharecdn.com/devoxx-2010-101118012648-phpapp01/85/To-scale-or-not-to-scale-Key-Value-Document-SQL-JPA-What-s-right-for-my-app-2-320.jpg)
![A Universe of Data Models 15Key / ValueColumnDocument{ “name”:”uri”, “ssn”:”213445”, “hobbies”:[”…”,“…”], “…”: { “…”:”…” “…”:”…” } }{ { ... }}{ { ... }}](https://image.slidesharecdn.com/devoxx-2010-101118012648-phpapp01/85/To-scale-or-not-to-scale-Key-Value-Document-SQL-JPA-What-s-right-for-my-app-15-320.jpg)
![DocumentThink JSON (or BSON, or XML){ “name”:”Lady Gaga”, “ssn”:”213445”, “hobbies”:[”Dressing up”,“Singing”], “albums”: [{“name”:”The fame” “release_year”:”2008”}, {“name”:”Born this way” “release_year”:”2011”}] }{ { ... }}{ { ... }}](https://image.slidesharecdn.com/devoxx-2010-101118012648-phpapp01/85/To-scale-or-not-to-scale-Key-Value-Document-SQL-JPA-What-s-right-for-my-app-22-320.jpg)
![What if you didn’t have to choose?JPA{ “name”:”uri”, “ssn”:”213445”, “hobbies”:[”…”,“…”], “…”: { “…”:”…” “…”:”…” } }{ { ... }}{ { ... }}JDBC](https://image.slidesharecdn.com/devoxx-2010-101118012648-phpapp01/85/To-scale-or-not-to-scale-Key-Value-Document-SQL-JPA-What-s-right-for-my-app-24-320.jpg)
To scale or not to scale: Key/Value, Document, SQL, JPA – What’s right for my app?
- 1. To Scale or Not to ScaleWhich API is Right for You?Uri Cohen, GigaSpaces@uri1803
- 2. > SELECT * FROM devoxx2010.speakers WHERE name=‘Uri Cohen’+-----------------------------------------------------+| Name | Company | Role | Twitter |+-----------------------------------------------------+| Uri Cohen | GigaSpaces | Product Manager | @uri1803 |+-----------------------------------------------------+> db.devoxx_speakers.find({name:”Uri Cohen”}){ “name”:”Uri Cohen”, “company”: { name:”GigaSpaces”, products:[“XAP”, “IMDG”] domain: “In memory data grids” } “role”:”product manager”, “twitter”:”@uri1803”}
- 3. AgendaSQLWhat it is and isn’t good for NoSQLMotivation & Main Concepts Common interaction modelsKey/Value, Column, DocumentNOT consistency and distribution algorithms One Data Store, Multiple APIsBrief intro to GigaSpaces Key/Value challenges SQL challenges: Add-hoc querying, Relationships (JPA)
- 4. A Few (more) Words About SQL
- 5. SQL(Usually) Centralized Transactional, consistent Hard to Scale
- 6. SQLStatic, normalized data schemaDon’t duplicate, use FKs
- 7. SQLAdd hoc query support Model first, query later
- 8. SQLStandard Well known Rich ecosystem
- 10. NoSql (or a Naive Attempt to Define It)A loosely coupled collection ofnon-relational data stores
- 11. NoSql (or a Naive Attempt to Define It)(Mostly) d i s t r i b u t e d
- 12. NoSql (or a Naive Attempt to Define It)scalable (Up & Out)
- 13. NoSql (or a Naive Attempt to Define It)Not (always) ACID BASE anyone?
- 14. Why Now?Timing is everything…Exponential Increase in data & throughput Non or semi structured data that changes frequently
- 15. A Universe of Data Models 15Key / ValueColumnDocument{ “name”:”uri”, “ssn”:”213445”, “hobbies”:[”…”,“…”], “…”: { “…”:”…” “…”:”…” } }{ { ... }}{ { ... }}
- 16. Key/ValueHave the key? Get the valueThat’s about it when it comes to querying Map/Reduce (sometimes)Good forcache aside (e.g. Hibernate 2nd level cache)Simple, id based interactions (e.g. user profiles) In most cases, values are Opaque
- 17. Key/ValueScaling out is relatively easy (just hash the keys)Some will do that automatically for you Fixed vs. consistent hashing
- 18. Key/ValueImplementations: Memcached, Redis, Riak In memory data grids (mostly Java-based) started this way GigaSpaces, Oracle Coherence, WebSphere XS, JBoss Infinispan, etc.
- 19. Column Based
- 20. Column Based Mostly derived from Google’s BigTable / Amazon Dynamo papers One giant table of rows and columnsColumn == pair (name and a value, sometimes timestamp)Each row can have a different number of columnsTable is sparse: (#rows) × (#columns) ≥ (#values)
- 21. Column Based Query on row key Or column value (aka secondary index)Good for a constantly changing, (albeit flat) domain model
- 22. DocumentThink JSON (or BSON, or XML){ “name”:”Lady Gaga”, “ssn”:”213445”, “hobbies”:[”Dressing up”,“Singing”], “albums”: [{“name”:”The fame” “release_year”:”2008”}, {“name”:”Born this way” “release_year”:”2011”}] }{ { ... }}{ { ... }}
- 23. DocumentModel is not flat, data store is aware of it Arrays, nested documents Better support for ad hoc queriesMongoDB excels at this Very intuitive model Flexible schema
- 24. What if you didn’t have to choose?JPA{ “name”:”uri”, “ssn”:”213445”, “hobbies”:[”…”,“…”], “…”: { “…”:”…” “…”:”…” } }{ { ... }}{ { ... }}JDBC
- 25. A Brief Intro to GigaSpaces In Memory Data Grid With optional write behind to a secondary storage A Brief Intro to GigaSpaces Tuple basedAware of nested tuples (and soon collections)Document like Rich querying and map/reduce semantics A Brief Intro to GigaSpaces Transparent partitioning & HAFixed hashing based on a chosen property A Brief Intro to GigaSpaces Transactional (Like, ACID)Local (single partition)
- 26. Distributed (multiple partitions)Use the Right API for the JobEven for the same data…POJO & JPA for Java apps with complex domain modelDocument for a more dynamic viewMemcached for simple, language neutral data accessJDBC for:Interaction with legacy apps Flexible ad-hoc querying (e.g. projections)
- 27. Memcached (the Daemon is in the Details)30
- 28. Memcached (the Daemon is in the Details)31
- 29. SQL/JDBC – Query Them AllQuery may involve Map/ReduceReduce phase includes merging and sorting32
- 30. SQL/JDBC – Things to Consider Unique and FK constraints are not practically enforceable Sorting and aggregation may be expensive Distributed transactions are evil Stay local…33
- 31. JPA It’s all about relationships…34
- 32. JPA Relationships To embed or not to embed, that is the question….35Easy to partition and scale
- 33. Easy to query: user.accounts.type= ‘checking’Owned relationships only JPA Relationships To embed or not to embed, that is the question….36Any type of relationship
- 35. Querying involves joiningSummaryOne API doesn’t fit allUse the right API for the job Know the tradeoffsAlways ask what you’re giving up, not just what you’re gaining 37