NoSQL Overview
0 likes653 views
This document discusses NoSQL databases as an alternative to SQL databases. It provides examples of different types of NoSQL databases like key-value stores, document stores, wide column stores, and graph databases. Each have different data models and use cases. With exponential data growth, semi-structured data, and preference for horizontal scaling, NoSQL databases provide advantages over SQL for certain applications.
NoSQL Overview
- 1. NoSQL: What Is It and Why Would I Care? Eberhard Wolff 21.09.11
- 2. Alternative Databases: NoSQL ► NoSQL: Not only SQL ► A good example for a catchy but bad name ► Not positive definition, rather “not something else” ► Now: Even less clear
- 3. Why NoSQL? ► Exponential data growth ► More and more connected data > Hypertext, Blogs, User generated content, Blogs ► Semi structured > User generated content > Full text search / indices instead of Query-by-Example ► Integration on the database less common ► Cloud prefers scale out over scale up > Cloud supports scale up: Reboot into larger machine > …but eventually you will need to scale out i.e. add more machines
- 4. NoSQL Flavors ► Key / value store ► Document ► Wide Column: Lots of Columns ► Graph Database: Graphs with nodes, relationships and properties ► Object databases: Stores objects – not rows ► Note: NoSQL is actually vaguely defined
- 5. Key-Value Stores ► Maps keys to values Key Value ► Just a large globally available Map 42 Some data ► i.e. not very powerful data model ► Advantages > Easy to understand > Easier to build scale out solutions (no joins, easy sharding etc) ► Disadvantages > Simplistic data model > Not a good fit for complex data > Might add complexity to the application code • Focus in Scalability • Redis: Think cache + Persistence • Riak
- 6. Key Value Store: Hybrid Approach ► Might just be used to store specific data ► I.e. scores of players in an online game > No complex structure > Need to scale > Lots of reads and write ► Player name, age, address would still be in a RDBMS ► Hybrid approach
- 7. Key-Value Stores: Store All Data ► Storing data as serialized blobs > "user:someuser" è "someuser|someuser@example.com|more|data|here" ► Storing data as multiple keys > "user:username:someuser" è "someuser" > "user:email:someuser" è "someuser@example.com" > Requires multi get/set to be efficient > Allows some querying if the database supports wildcards, like "user:email:someuser*" ► Storing links > Blob: "basket:someuser" è"...|item|1|product|product:123|..." > Separate keys: "basket:someuser:item:1:product" è "product:123" – Multi-get: "basket:someuser:*" loads the shopping basket and all items ► Easy to understand, hard to implement
- 8. Document Stores ► Aggregates are typically stored as "documents“ (key-value collection) ► JSON, BSON (binary JSON) and XML are common ► Still no schema, so add any data at runtime ► The semi-structure of the document allows the database to build indexes, allowing queries that address properties of the document > E.g. "find all baskets that contain the product 123" ► Relations might be modeled as links ► Advantages > Good fit for semi structured data > In particular a good fit for JSON, XML, HTML… > Probably the easiest transition from RDBMS ► Disadvantages > Does not scale to the key/value store level ► Focus on semi structured data e.g. JSON ► MongoDB, CouchDB
- 9. Wide Column ► Add any "column" you like to a row XX ► Not a key-value store, but a "key-(column-value)" store XX XX XX XX XX XX XX ► Column families are like tables XX XX XX XX ► E.g. in the "Users" column family XX XX XX XX XX XX XX XX > "someuser" è ("username"è"someuser"), XX XX XX XX ("email" è"someuser@example.com") XX XX XX XX XX ► Since columns are named, some databases provide indexing XX XX XX > E.g. Google AppEngine allows you to define columns that can XX queried be XX XX XX XX XX XX ► Advantages XX XX XX XX > Easy to store complex and heterogeous data XX xX XX XX XX § Apache Cassandra § Amazon SimpleDB
- 10. Graph ► Nodes with Properties ► Typed relationships with properties ► Ideal e.g. to model relations in a social network ► Easy to find number of followers, degree of relation etc. ► Neo4j
- 11. What happened to Queries? ► Data is easily and quickly read/stored using primary key ► Denormalize data for commonly used queries > Store twitter inbox in key/value as – "inbox:someuser" è ("posts:123", "posts:234", ...) > instead of doing the query (RDBMS) – select p.* from POSTS p, POSTLINKS pl where p.id = pl.postId and pl.userid=42 ► Store reverse lookup > ”ewolff|following" è (”spring_rod", ”spring_juergen") > ”post:435|RT" è (”post:42", ”post:21")
- 12. What It Means for Developers § More technologies to have fun with § Broader choice of persistence stores § Probably Cross Store Persistence • Store name, firstname etc in RDBMS • Store followers in Graph database • Store Content in RDBMS • Store User Generated Content in Document database § Spring Data • Similar APIs for JPA and NoSQL • Support for cross store persistence • Sophisticated support for generic DAOs • E.g. just add findByName() method, implementation is provided § QueryDSL • JPA Criteria API done right