1. Big Data Yuan Xue (yuan.xue@vanderbilt.edu) CS 292 Special topics on

2. Part II NoSQL Database (Summary) Yuan Xue (yuan.xue@vanderbilt.edu)

3. Outline  From SQL to NoSQL  Motivation  Challenges  Approaches  Notable NoSQL systems  Database User/Application Developer: How to use?  (Logic) data model and CRUD operations  Database System Designer: How to design?  Under the hood: (Physical) data model and distribution algorithm  Database Designer: How to link application needs with database design  Schema design  Summary and Moving forward  Comparison of NoSQL Database  Summary of NoSQL Data Modeling Techniques  Summary of NoSQL Data Distribution Models/Algorithms  Limits of NoSQL  NewSQL (Spanner, will not be covered) Data Model Column Family Key-value Document

4. From SQL to NoSQL  Relational Database Review  Persistent data storage  Transaction support  ACID  Concurrency control + recovery  Standard data interface for data sharing  SQL Conceptual Design Data model mapping Entity/Relationship model Logic Design Logical Schema] Normalization Normalized Schema Physical Design Physical (Internal) Schema DesignOperation SQL query

5. Meta-data SQL Review -- Putting Things Together Application Program/Queries Users Query Processing Data access (Database Engine) Data DBMS system http://www.dbinfoblog.com/post/24/the-query-processor/

6. From SQL to NoSQL  Motivation I  Scaling (up/out) SQL database  Solution: Replication and Sharding  Motivation II  Impedance Mismatch  Difference between in-memory data structures and relational model  Predefined schema  Join operation  Not appropriate for  Graph data  Geographical data  Unstructured data Duplication facilitates read Data consistency problem arises Partition facilitates write/read lost transaction support across partition

7. From SQL to NoSQL  Google: Search Engine  Store billions document  Bigtable + Google File System  Amazon: Online Shopping  Shopping cart management  dynamo Foundation Open source DBMS Cloud-hosted managed DBMS Amazon DynamoDB Amazon SimpleDB … HBase + HDFS Cassandra Riak Redis MongoDB … Supported by many social media sites with large data needs facebook twitter Utilized by companies imdb startups..

8. What is NoSQL  Stands for Not Only SQL: Not relational database  Umbrella term for many different types of data stores (database)  Different Types of Data Model  Key va lue DB,  Column Family DB  Document DB  Graph DB  Just as there are different programming languages, NoSQL provides different data storage tools in the toolbox  Polyglot Persistence

9. What is the Magic?  Logic Data Model: From Table to Aggregate  Diverse data models  Column Family  Key-value  Document  Graph  No schema predefined  allows an attribute/field to be added at run-time  Still need to consider how to define “key” “column family”  Giving up build-in Joins  Physical Data Handling: From ACID to BASE (CAP theorem)  No full transaction support  Support at Aggregate level  Support both replication and sharding (automatically)  Relax one or more of the ACID properties Aggregate

10. NoSQL Database Classification -- Data Model View  Key Value Store  Dynamo  Riak  Redis  Memcached (in memory)  Column Family  Hbase (BigTable)  Cassandra  Document  MongoDB  Terrastore  Graph  FlockDB  Neo4J

11. Outline  Comparison of NoSQL Database  which solution is best suitable for each particular task?  test performance of each database under different types of loads and let the users decide what product better suits their needs.  Summary of NoSQL Data Modeling Techniques  Summary of NoSQL Data Distribution Models/Algorithms

12. Benchmarking Method  Yahoo Cloud Serving Benchmark  Workload was defined by different distributions assigned to the two main choices:  which operation to perform  which record to read or write  Operations against a data store were randomly selected and could be of the following types: Scan: Scans records in order, starting at a randomly selected record key. The number of records to scan is also selected randomly from the range between 1 and 100.  Each workload was targeted at a table of 100,000,000 records  Each record was 1,000 bytes in size and contained 10 fields Each workload was defined by: 1) The number of records manipulated (read or written) 2) The number of columns per each record 3) The total size of a record or the size of each column 4) The number of threads used to load the system A vendor-independent comparison of NoSQL databases: Cassandra, HBase, MongoDB, Riak Each of the NoSQL databases was deployed on a four-node cluster in the same geographical region on Amazon Extra Large Instances:

13. Result – Load Phase  HBase demonstrated by far the best writing speed.  Cassandra also showed great performance during the loading phase

14. Result – WorkLoad A  Workload A: Update- heavily mode.  simulates the database work, during which typical actions of an e- commerce solution user are recorded.  Settings for the workload: 1) Read/update ratio: 50/50 2) Zipfian request distribution

15. Result – Workload B  Workload B: Read-heavy mode.  Workload B consisted of 95% of reads and 5% of writes.  Content tagging can serve as an example task matching this workload; adding a tag is an update, but most operations imply reading tags. Settings for the "read-mostly" workload: 1) Read/update ratio: 95/5 2) Zipfian request distribution

16. Result – Workload C  Workload C: Read- only.  Settings for the workload: 1) Read/update ratio: 100/0 2) Zipfian request distribution  simulated a data caching system. The data was stored outside the system, while the application was only reading it.

17. Result – Workload E  Workload E: Scanning short ranges. Settings for the workload: 1) Read/update/insert ratio: 95/0/5 2) Latest request distribution 3) Max scan length: 100 records 4) Scan length distribution: uniform ??

18. Result – Workload G  Workload G: Insert- mostly mode.  Settings for the workload: 1) Insert/Read: 90/10 2) Latest request distribution

19. Data Modeling for NoSQL  Key-Value storage is a very simplistic, but very powerful model.  Shortcoming: poor applicability to cases that require processing of key ranges.  Ordered Key-Value model is very powerful  Shortcoming: provide no framework for value modeling.  value modeling can be done by an application,  Column family (BigTable-style databases)  model values as a map-of-maps-of-maps, namely, column families, columns, and timestamped versions.  Document databases advance the BigTable model offering two significant improvements.  values with schemes of arbitrary complexity, not just a map-of-maps.  database-managed indexes, at least in some implementations. http://highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniques/

20. NoSQL data modeling in principle  NoSQL data modeling often starts from the application-specific queries as opposed to relational modeling:  Relational modeling is typically driven by the structure of available data. The main design theme is ”What answers do I have?”  NoSQL data modeling is typically driven by application-specific access patterns, i.e. the types of queries to be supported. The main design theme is ”What questions do I have?”  NoSQL data modeling often requires a deeper understanding of data structures and algorithms than relational database modeling does.

21. Denormalization  Denormalization can be defined as the copying of the same data into multiple documents or tables in order to simplify/optimize query processing or to fit the user’s data into a particular data model.  In general, denormalization is helpful for the following trade-offs:  Query data volume or IO per query VS total data volume. Using denormalization one can group all data that is needed to process a query in one place. This often means that for different query flows the same data will be accessed in different combinations. Hence we need to duplicate data, which increases total data volume.  Processing complexity VS total data volume. Modeling-time normalization and consequent query-time joins obviously increase complexity of the query processor, especially in distributed systems. Denormalization allow one to store data in a query-friendly structure to simplify query processing.  Applicability: Key-Value Stores, Document Databases, BigTable-style Databases

22. Aggregate  All major genres of NoSQL provide soft schema capabilities  Soft schema allows one to form classes of entities with complex internal structures (nested entities) and to vary the structure of particular entities.This feature provides two major facilities:  Minimization of one-to-many relationships by means of nested entities and, consequently, reduction of joins.  Masking of “technical” differences between business entities and modeling of heterogeneous business entities using one collection of documents or one table.  Applicability: Key-Value Stores, Document Databases, BigTable-style Databases

23. Application Side Joins  Joins are rarely supported in NoSQL solutions.  As a consequence of the “question-oriented” NoSQL nature, joins are often handled at design time as opposed to relational models where joins are handled at query execution time.  Query time joins almost always mean a performance penalty, but in many cases one can avoid joins using Denormalization and Aggregates, i.e. embedding nested entities.  In many cases joins are inevitable and should be handled by an application.  The major use cases are:  Many to many relationships are often modeled by links and require joins.  Aggregates are often inapplicable when entity internals are the subject of frequent modifications. It is usually better to keep a record that something happened and join the records at query time as opposed to changing a value.  Applicability: Key-Value Stores, Document Databases, BigTable-style Databases, Graph Databases 

24. Atomic Aggregates  NoSQL solutions have limited transaction support.  In some cases one can achieve transactional behavior using distributed locks or application- managed MVCCapplication- managed MVCC  It is common to model data using an Aggregates technique to guarantee some of the ACID properties.  Aggregates allow one to store a single business entity as one document, row or key-value pair and update it atomically  transactional machinery is required for the relational databases because normalized data typically require multi-place updates.  Applicability: Key-Value Stores, Document Databases, BigTable-style Databases

25. Index Table  Index Table is a very straightforward technique that allows one to take advantage of indexes in stores that do not support indexes internally.  The most important class of such stores is the BigTable-style database. The idea is to create and maintain a special table with keys that follow the access pattern.  An Index table can be updated for each update of the master table or in batch mode. Either way, it results in an additional performance penalty and become a consistency issue.  Applicability: BigTable-style Databases

26. Composite Key Index  Composite key is a very generic technique, but it is extremely beneficial when a store with ordered keys is used.  Composite keys in conjunction with secondary sorting allows one to build a kind of multidimensional index.

27. ACID and Transaction Support in Distributed Environment  Recall -- scaling out database  Distributed environment with multiple nodes  Data are distributed across nodes via  Replication  Sharding  Concerns from Distributed Networking Environment  Message Loss/Delay  Network partition  CAP theorem comes as a guideline

28. CAP Theorem Start with three properties for distributed systems: Consistency: All nodes see the same data at the same time Availability: Every request to a non- failing node in the system returns a response about whether it was successful or failed. Partition Tolerance: System properties (consistency and/or availability) hold even when the system is partitioned (communicate lost) Consistency Partition tolerance Availability

29. CAP Theorem Consistency – Atomic data object Consistency Partition tolerance Availability As in ACID 1.In a distributed environment, multiple copies of a data item may exist on different nodes. 2.Consistency requires that all operations towards a data item are executed as if they are performed over a single instant Data item X Copy 1 Data item X Copy 2 Clients Data item X

30. CAP Theorem Availability – Available data object Requests to data -- Read/write, always succeed. 1.All (non-failing ) nodes remain able to read and write even when network is partitioned. 2.A system that keeps some, but not all, of its nodes able to read and write is not Available in the CAPsense, even if it remains available to clients and satisfies its SLAs for high availalbility Consistency Partition tolerance Availability Reference: https://foundationdb.com/white-papers/the-cap-theorem

31. CAP Theorem Partition Tolerance Consistency Partition tolerance Availability 1.The network will be allowed to lose arbitrarily many messages sent from one node to another. 2.When network is partitioned, all messages from one component to another will get lost. Under Partition Tolerance Consistency requirement implies that every data operation will be atomic, even though arbitrary messages may get lost. Availability requirement implies that every nodes receiving a request from a client must respond, even though arbitrary messages may get lost.

32. CAP Theorem  You can have at most two of these three properties for any shared-data system  Consistency, availability and partition tolerance  To scale out, you have to support partition tolerant  NoSQL: either consistency or availability to choose from under network partition Consistency Partition tolerance Availability Pick one side NoSQL SQL

33. NoSQL Database Classification -- View from CAP Theorem ConsistencyPartition tolerance Availability Relational: MySQL, PostgreSQL Relational: MySQL BigTable and its derivatives: HBase, Redis, MongoDB Dynamo and its derivatives: Cassandra, Riak

34. Desired Properties from Replication  Availability. Isolated parts of the database can serve read/write requests in case of network partition.  Read/Write latency. Read/Write requests are processes with a minimal latency.  Read/Write scalability. Read/Write load can be balanced across multiple nodes.  Fault-tolerance. Ability to serve read/write requests does not depend on availability of any particular node.  Data persistence. Node failures within certain limits do not cause data loss.  Consistency.

35. More on Consistency  Question: in AP system, if consistency property can not be hold, what property can be claimed?  Example  Data item X is replicated on nodes M and N  Client A writes X to node N  Some period of time t elapses.  Client B reads X from node M  Does client B see the write from client A?  From client’s perspective, two kinds of consistency:  Strong consistency (as C in CAP): any subsequent access is guaranteed to return the updated value  Weak consistency: subsequent access is not guaranteed to return the updated value  Inconsistency window: The period between the update and the moment when it is guaranteed that any observer will always see the updated value  Consistency is a continuum with tradeoffs  Multiple consistency models Client A write read Data item X Copy 1 Data item X Copy 2 MN Client B

36. Eventual Consistency  Eventual consistency  a specific form of weak consistency  When no updates occur for a long period of time, eventually all updates will propagate through the system and all the nodes will be consistent  all accesses will return the last updated value.  For a given accepted update and a given node, eventually either the update reaches the node or the node is removed from service