NoSQL Data Stores Data Stores for the Cloud

1. COS 497 - Cloud Computing NoSQL Data Stores Data Stores for the Cloud

2. First, some definitions of terms …

3. SQL JOIN An SQL JOIN clause combines records from two or more tables in a database. It creates a set that can be saved as a table or used as it is. A JOIN is a means for combining fields from two tables by using values common to each. ANSI-standard SQL specifies four types of JOIN: INNER, OUTER, LEFT, and RIGHT. As a special case, a table (base table, view, or joined table) can JOIN to itself in a self-join. One of the most complex SQL operations.

4. Horizontal and Vertical Scaling - Scaling Resources Up Horizontal scaling means that you scaleby adding more machines to your pool of resources. Whereas Vertical scaling means that you scaleby adding more power (CPU, RAM, etc.) to your existing machine. In the database world, horizontal scalingis often based on partitioning of the data i.e. splitting up the data so that each machine contains only part of the data. While in vertical scaling the data resides on a single node and scaling is done through the use of multi-cores, etc. i.e. spreading the load between the CPU and RAM resources of that single machine.

5. With horizontal scaling it is easier to scale dynamically by adding more machines into the existing pool. • Whereas Vertical scaling is often limited to the capacity of a single machine, scaling beyond that capacity often involves downtime and comes with an upper limit. • Good examples for horizontal scaling are the Cloud data stores, e.g. DynamoDB, Cassandra , MongoDB… • A good example for vertical scaling is MySQL - Amazon RDS (The cloud version of MySQL) provides an easy way to scale vertically by switching from small to bigger machines, but this process often involves downtime.

6. ACID ACID is an acronym for a set of properties that you would like to hold when modifying a database via a transaction, i.e. a group of related changes to the database. Atomicity Consistency Isolation Durability A cornerstone of RDMS

7. Atomicity means that you can guarantee that all of a transaction happens, or none of it does. You can do complex operations as one single unit (aka transaction), all or nothing, and a crash, power failure, error, or anything else will not leave the database in a state in which only some of the related changes have happened. Consistency means that you can guarantee that your data will be consistent. None of the constraints that may existon related data will ever be violated.

8. Isolation means that one transaction cannot read data from another transaction that is not yet completed. • If two transactions are executing concurrently, each one will see the world as if they were executing sequentially, and if one needs to read data that is written by another, it will have to wait until the other is finished. • Durability means that once a transaction is complete, it is guaranteed that all of the changes have been recorded to a durable medium (such as a hard disk), and the fact that the transaction has been completed is likewise recorded. • So, transactions are a mechanism for guaranteeing these properties - they are a way of grouping related actions together such that as a whole, a group of operations can be atomic, produce consistent results, be isolated from other operations, and be durably recorded.

9. What is NoSQL? “NoSQL is the term used to designate database management systems (aka data stores) that differ from traditionalrelational database management systems in some way. These data stores may not require fixed-table schemas, and usually avoid join operations and typically scale horizontally.” - Wikipedia “Non-relational”may be more accurate term than “NoSQL”, as some NoSQL DBs do support a subset of SQL.

10. NoSQL is a non-relational database management systems, different from traditional relational database management systems in some significant ways. It is designed for distributed data stores where very large scale of data storing needs to be available (For example, Google or Facebook which collects terabits of data every day for their users). These type of data storing may not require fixed schema, avoid join operations and typically scale horizontally.

11. Today, data is becoming easier to access and capture through third parties such as Facebook, Google+ and others. Personal user information, social graphs, geo-location data, user-generated content and machine logging data are just a few examples where the data has been increasing exponentially. To use the above services properly requires the processing of huge amounts of data. Which SQL databases are no good for, and were never designed for. NoSQLdatabases have evolved to handle this huge data properly.

13. RDMS has a problem with Unstructured or Semi-Structured Data

14. Example

15. A typical traditional, structured, table-based relational database Fixed number of fields for each record – highly structured

16. CAP Theorem You need tounderstand the CAP theorem when you talk about NoSQL databases, or, in fact, when designing any distributed system. The CAP theorem states that there are three basic requirements which exist in a special relation when designing applications for a distributed architecture.

17. Consistency - This means that the data in the database remains consistent after the execution of an operation. For example, after an update operation, all clients see the same data. Availability - This means that the system is always on (Service guarantee availability), no downtime. Partition Tolerance - This means that the system continues to function even if the communication among the servers is unreliable, i.e. the servers may be partitioned into multiple groups that cannot communicate with one another.

18. Generally, it is not be possible to fulfill all three requirements in a distributed system. CAP provides the basic requirements for a distributed system to follow two of the three requirements. Distributed systems must be partition tolerant (P), so we have to choose between Consistency and Availability. Current NoSQLdatabases follow the different combinations of C and A from the CAP theorem.

19. Network Partitions A network partition can occur when a network failure causes a collection of nodes to be divided into two sub-collections that are isolated from each other. Partitions may occur within or between data centers.

20. Here is the brief description of three combinations CA, CP, AP : • CA - Single site cluster, therefore all nodes are always in contact. When a partition occurs, the system blocks. • CP - Some data may not be accessible, but the rest is still consistent/accurate. • AP - System is still available under partitioning, but some of the data returned may be inaccurate.

22. Business Perspective In the business world … Availability is more valuable than Consistency – When in doubt, take the customer’s order. – Apologize, fix, and compensate later. Do notsay “Sorry, we cannot take your money. Our computers are down!”

23. RDBMS versus NoSQL RDBMS - Structured and organized data - Structured query language (SQL) - Data and its relationships are stored in separate tables. - Data Manipulation Language, Data Definition Language - Tight Consistency - ACID Transaction NoSQL - Stands for Not Only SQL - No declarative query language - No predefined schema - Variants - Key-Value Pair Store, Column Store, Document Store, Graph Store - Eventual consistency rather ACID property - Unstructured and unpredictable data - CAP Theorem - Prioritizes high performance, high availability and scalability

24. Key Point: SQL and NoSQL If SQL is your only storage tool, then all problems must look the same– no Big Data. Using SQL and NoSQL storage technologies where appropriate, systems can have – SQL for high consistency where needed – NoSQLfor high availability and scalability

25. NoSQL: The Name • “SQL” = Traditional relational DBMS • Recognition over past decade or so … • … Not every data management/analysis problem is best • solved using a traditional relational DBMS • “NoSQL” used to be mean “No SQL” • - Not using traditional relational DBMS • But now, “NoSQL” = Not ONLY SQL

26. Not every data management/analysis problem is best solved exclusivelyusing a traditional RDBMS … Database Management System (RDBMS) provides … … efficient, reliable, convenient, and safe multi-user storage of, and access to, large amounts of persistent data. But not for Big data!

27. Why not stick to relational DBs? Limited scalability – Master/slave clusters are limited by write bandwidth, and have a single point-of-failure, i.e. the master. – Partitioning of data requires that you rewrite your application to find your data, and does not scale joins. Availability is more important than consistency – A RDBMS will make data unavailable until it is consistent on each node. – In large clusters or if a node is down, the period of unavailability can be too long.

28. Scaling Up RDMS • There are issueswith scaling up when the data set is just too big. • RDBMS were not designed to be distributed. • Researchers began looking at multi-node database solutions. • Known as “scaling out” or “horizontal scaling”. • Different approaches include • Master-slave • Sharding • Memcaching – keeping copies of tables in RAM

29. RDBMS: Scalability: Master/Slave All write operations on the master All read operations from the slaves Writes are propagated to the replicated slaves - Reads may be incorrect, meanwhile  - When data is too big, master has problem to duplicate data to slaves 

30. RDBMS: Scalability: Shards Partitioning (Sharding) Advantage: - Scales well for both operations Disadvantages: - Applications need to be shard “aware” – more programming. - No joins across shards - No referential integrity across shards Referential integrity is a property of data which, when satisfied, requires every value of one column of a relational table to exist as a value of another column in a different table.

31. What problem do you have? What data problem are you trying to solve? Do you need – Fault tolerance – High availability – Consistency – Scalability Why not use a database that solves all of these problems at once? – It’s impossible to make such a database! So Cloud developers began to research other technologies …

32. NoSQL Systems • Alternative to traditional relational DBMS • Flexible schema • Quicker/cheaper to set up • Massive scalability • Relaxed consistency  higher performance and availability • No declarative query language (i.e. SQL)  more programming • Relaxed consistency  fewer guarantees

33. But You Still Need RDBMS!

34. Evolution of NoSQL Databases • Standard architecture for simple web apps: – Frontend load-balanced web servers – Business logic layer in the middle – Backend database • Databases do not scale well with very large numbers of users or very large amounts of data • Alternatives include – Sharded (partitioned) databases – Master-Slave databases – Memcached

35. NoSQL Overview • Main objective: implement distributed data store – Different objects stored on different servers – Same object replicated on different servers • Main idea: Give up some of the ACID constraints to improve performance • Simple interface: – Write (=Put): needs to write all replicas – Read (=Get): may get only one • Eventual consistency Strong consistency

36. NoSQL Key Feature Decisions • Want a data management system that is – Elastic and highly scalable – Flexible (Different records can have different schemas) • To achieve above goals, willing to give up – Complex queries: e.g. give up on joins – Multi-object transactions – ACID guarantees: e.g. eventual consistency is OK – Not all NoSQL systems give up all these properties

37. Six key features of NoSQL: 1. Scale horizontally “simple operations” – key lookups, reads and writes of one record or a small number of records, simple selections 2. Replicate/distribute data over many servers 3. Simple call-level interface (contrast with SQL) 4. Weaker concurrency model than ACID 5. Efficient use of distributed indexes and RAM 6. Flexible schema

38. NoSQL Systems • Name originally meant No SQL support, but now “softened” to mean Not Only SQL • One or more of the ACID properties not supported • Database JOINs generally not supported • Usually flexible schemas • Some well known examples: Google’s BigTable, Amazon’s Dynamo and Facebook’s Cassandra • Several recent open source systems

39. CAP Again! Very large systems will partition at some point - failures - It is necessary to decide between C and A - Most web-based DB applications choose A Strict consistency cannot be achieved at the same time as availability on partitioned data ACID must be relaxed!

40. NoSQL and ACID NoSQL databases relaxed the ACID properties →BASE Basically Available Soft state Eventually consistent

41. BASE Basically Available: The database system always seems to work! Soft State: It does nothave to be consistent all the time (Not all shards return the same data value →approximate answers!) Eventually Consistent: The system will eventuallybecome consistent when the updates propagate, in particular, when there are not too many updates

42. You would use NoSQL for one main reason: scalability. • If your application needs to handle millions of queries per second, the only way to achieve it is to add more servers. That is very cheap and easy with NoSQL. • In contrast, scaling a traditional SQL database is much more complicated. • Only the biggest websites out there are actually taking advantage of the full NoSQL potential, i.e., Facebook, having thousands of servers running Cassandra.

43. Different Types of NoSQL Systems • • Distributed Key-Value Systems - Lookup a single value for a key • – Amazon’s Dynamo • • Document-based Systems - Access data by key or by search of “document” data. • – CouchDB • – MongoDB • • Column-based Systems • – Google’s BigTable • – Facebook’s Cassandra • • Graph-based Systems - Use a graph structure - Google’s Pregel - Neo4j Use different types for different types of applications

44. Key-Value Pair (KVP) Stores • • Access data (values) by strings called keys. • • Data has no required format – data may have any format • Extremely simple interface • Data model: (key, value) pairs • Basic Operations: Insert(key,value), Fetch(key),Update(key), Delete(key) • Implementation: efficiency, scalability, fault-tolerance • Records distributed to nodes based on key • Replication • Single-record transactions, “eventual consistency” • Example systems • Amazon Dynamo, …

45. “Value” is stored as a “blob” - Without caring or knowing what is inside - Application is responsible for understanding the data In simple terms, a NoSQLKey-Value storeis a single table with two columns: one being the (Primary) Key, and the other being the Value. Each record may have a different schema

46. Example

47. Original KVP Store was Dynamo - Amazon’s Highly-Available Key-Value Store • Main observation from Amazon: – “There are many services on Amazon’s platform that only need primary-key access to a data store.” E.g. Best seller lists, shopping carts, customer preferences, session management, sales rank, product catalog Aside: Dynamo now superseded by DynamoDB. http://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf

48. Other Key-Value Pair Stores implementations are based primarily on Amazon's Dynamo research paper, which was written in 2007. Amazon Dynamo automatically spreads the data and traffic for a table over a sufficient number of servers to meet the request capacity specified by the customer. The main idea is the use of a hash table where there is a unique key and a pointer to a particular item of data. - These mappings are usually accompanied by cache mechanisms to maximize performance.

49. Dynamo applies a MD5 hash on the key to generate a 128-bit identifier, which is then used to determine the storage node that is responsible for serving the key. • - Data records are randomly assigned to storage nodes. • - This allows the data store to scale incrementally - dynamically partition the data over the set of nodes (i.e., storage hosts) in the system. The simplicity of Key-Value Stores makes them ideally suited to extremely fast, highly-scalable retrieval of the values needed for application tasks like managing user profiles or sessions or retrieving product names. This is why Amazon makes extensive use of its own KVP system, Dynamo, in its shopping cart.

50. Document Stores • Like Key-Value Stores, except Value is a “Document” • Data model: (key, “document”) pairs • Document format: JSON, XML, other semi-structured formats • Basic operations: Insert(key,document), • Fetch(key), Update(key), • Delete(key) • Also Fetch()based on document contents • Example systems • CouchDB, MongoDB, SimpleDB, … • Document stores • – Store arbitrary/extensible structures as a “value”