Updated Links & adding images
This commit is contained in:
Sai Kiran Kanuri
parent
9c6eed0c4c
commit
df38966f71
Binary file not shown.
|
After Width: | Height: | Size: 30 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 73 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 20 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 50 KiB |
|
|
@ -1,9 +1,9 @@
|
|||
# School of SRE : DATABASES - NoSQL
|
||||
# DATABASES - NoSQL
|
||||
|
||||
|
||||
## Target Audience
|
||||
|
||||
This Module is meant to be an introduction to NoSQL Databases. We will be touching upon the key concepts and trade-offs in a distributed data system.
|
||||
This Module is meant to be an introduction to NoSQL Databases. We will be touching upon the key concepts and trade offs in a distributed data system.
|
||||
|
||||
|
||||
## What to expect from this training
|
||||
|
|
@ -15,8 +15,11 @@ At the end of training, you will have an understanding of what a NoSQL database
|
|||
|
||||
We will not be deep diving into any specific NoSQL Database.
|
||||
|
||||
|
||||
## Agenda
|
||||
|
||||
|
||||
|
||||
* Introduction to NoSQL
|
||||
* CAP Theorem
|
||||
* Data versioning
|
||||
|
|
@ -40,10 +43,10 @@ Over time due to the way these NoSQL databases were developed to suit requiremen
|
|||
|
||||
|
||||
|
||||
1. **Document databases: **They store data in documents similar to JSON (JavaScript Object Notation) objects. Each document contains pairs of fields and values. The values can typically be a variety of types including things like strings, numbers, booleans, arrays, or objects, and their structures typically align with objects developers are working with in code. The advantages include intuitive data model & flexible schemas. Because of their variety of field value types and powerful query languages, document databases are great for a wide variety of use cases and can be used as a general purpose database. They can horizontally scale-out to accomodate large data volumes. Ex: MongoDB, Couchbase
|
||||
2. **Key-Value databases:** These are a simpler type of databases where each item contains keys and values. A value can typically only be retrieved by referencing its value, so learning how to query for a specific key-value pair is typically simple. Key-value databases are great for use cases where you need to store large amounts of data but you don’t need to perform complex queries to retrieve it. Common use cases include storing user preferences or caching. Ex: Redis, DynamoDB, Voldemort/Venice (Linkedin),
|
||||
3. **Wide-Column stores:** They store data in tables, rows, and dynamic columns. Wide-column stores provide a lot of flexibility over relational databases because each row is not required to have the same columns. Many consider wide-column stores to be two-dimensional key-value databases. Wide-column stores are great for when you need to store large amounts of data and you can predict what your query patterns will be. Wide-column stores are commonly used for storing Internet of Things data and user profile data. Cassandra and HBase are two of the most popular wide-column stores.
|
||||
4. Graph Databases: These databases store data in nodes and edges. Nodes typically store information about people, places, and things while edges store information about the relationships between the nodes. The underlying storage mechanism of graph databases can vary. Some depend on a relational engine and “store” the graph data in a table (although a table is a logical element, therefore this approach imposes another level of abstraction between the graph database, the graph database management system and the physical devices where the data is actually stored). Others use a key-value store or document-oriented database for storage, making them inherently NoSQL structures. Graph databases excel in use cases where you need to traverse relationships to look for patterns such as social networks, fraud detection, and recommendation engines. Ex: Neo4j
|
||||
1. **Document databases: **They store data in documents similar to [JSON](https://www.json.org/json-en.html) (JavaScript Object Notation) objects. Each document contains pairs of fields and values. The values can typically be a variety of types including things like strings, numbers, booleans, arrays, or objects, and their structures typically align with objects developers are working with in code. The advantages include intuitive data model & flexible schemas. Because of their variety of field value types and powerful query languages, document databases are great for a wide variety of use cases and can be used as a general purpose database. They can horizontally scale-out to accomodate large data volumes. Ex: MongoDB, Couchbase
|
||||
2. **Key-Value databases:** These are a simpler type of databases where each item contains keys and values. A value can typically only be retrieved by referencing its value, so learning how to query for a specific key-value pair is typically simple. Key-value databases are great for use cases where you need to store large amounts of data but you don’t need to perform complex queries to retrieve it. Common use cases include storing user preferences or caching. Ex: [Redis](https://redis.io/), [DynamoDB](https://aws.amazon.com/dynamodb/), [Voldemort](https://www.project-voldemort.com/voldemort/)/[Venice](https://engineering.linkedin.com/blog/2017/04/building-venice--a-production-software-case-study) (Linkedin),
|
||||
3. **Wide-Column stores:** They store data in tables, rows, and dynamic columns. Wide-column stores provide a lot of flexibility over relational databases because each row is not required to have the same columns. Many consider wide-column stores to be two-dimensional key-value databases. Wide-column stores are great for when you need to store large amounts of data and you can predict what your query patterns will be. Wide-column stores are commonly used for storing Internet of Things data and user profile data. [Cassandra](https://cassandra.apache.org/) and [HBase](https://hbase.apache.org/) are two of the most popular wide-column stores.
|
||||
4. Graph Databases: These databases store data in nodes and edges. Nodes typically store information about people, places, and things while edges store information about the relationships between the nodes. The underlying storage mechanism of graph databases can vary. Some depend on a relational engine and “store” the graph data in a table (although a table is a logical element, therefore this approach imposes another level of abstraction between the graph database, the graph database management system and the physical devices where the data is actually stored). Others use a key-value store or document-oriented database for storage, making them inherently NoSQL structures. Graph databases excel in use cases where you need to traverse relationships to look for patterns such as social networks, fraud detection, and recommendation engines. Ex: [Neo4j](https://neo4j.com/)
|
||||
|
||||
|
||||
### **Comparison**
|
||||
|
|
@ -171,7 +174,7 @@ The table below summarizes the main differences between SQL and NoSQL databases.
|
|||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Multi-Record ACID Transactions
|
||||
<td>Multi-Record <a href="https://en.wikipedia.org/wiki/ACID">ACID </a>Transactions
|
||||
</td>
|
||||
<td>Supported
|
||||
</td>
|
||||
|
|
@ -216,5 +219,4 @@ The table below summarizes the main differences between SQL and NoSQL databases.
|
|||
|
||||
* Developer productivity
|
||||
|
||||
NoSQL systems tend to map data based on the programming data structures. As a result developers need to perform fewer data transformations leading to increased productivity & fewer bugs.
|
||||
|
||||
NoSQL systems tend to map data based on the programming data structures. As a result developers need to perform fewer data transformations leading to increased productivity & fewer bugs.
|
||||
|
|
@ -1,98 +1,4 @@
|
|||
# Key Concepts - NoSQL
|
||||
|
||||
Lets looks at some of the key concepts when we talk about NoSQL or distributed systems
|
||||
|
||||
|
||||
## CAP Theorem
|
||||
|
||||
|
||||
|
||||
In a keynote titled “Towards Robust Distributed Systems” at ACM’s PODC symposium in 2000 Eric Brewer came up with the so-called CAP-theorem which is widely adopted today by large web companies as well as in the NoSQL community. The CAP acronym stands for **C**onsistency, **A**vailability & **P**artition Tolerance.
|
||||
|
||||
|
||||
|
||||
* **Consistency**
|
||||
|
||||
It refers to how consistent a system is after an execution. A distributed system is called consistent when a write made by a source is available for all readers of that shared data. Different NoSQL systems support different levels of consistency.
|
||||
|
||||
* **Availability**
|
||||
|
||||
It refers to how a system responds to loss of functionality of different systems due to hardware and software failures. A high availability implies that a system is still available to handle operations (reads and writes) when a certain part of the system is down due to a failure or upgrade.
|
||||
|
||||
* **Partition Tolerance**
|
||||
|
||||
It is the ability of the system to continue operations in the event of a network partition. A network partition occurs when a failure causes two or more islands of networks where the systems can’t talk to each other across the islands temporarily or permanently.
|
||||
|
||||
|
||||
Brewer alleges that one can at most choose two of these three characteristics in a shared-data system. The CAP-theorem states that a choice can only be made for two options out of consistency, availability and partition tolerance. A growing no of use cases in large scale applications tend to value reliability implying that Availability & Redundancy are more valuable than Consistency. As a result these systems struggle to meet ACID properties. They attain this by loosening on the consistency requirement i.e Eventual Consistency.
|
||||
|
||||
**Eventual Consistency **means that all readers will see writes, as time goes on: “In a steady state, the system will eventually return the last written value”. Clients therefore may face an inconsistent state of data as updates are in progress. For instance, in a replicated database updates may go to one node which replicates the latest version to all other nodes that contain a replica of the modified dataset so that the replica nodes eventually will have the latest version.
|
||||
|
||||
Different NoSQL systems support different levels of eventual consistency models. For ex:
|
||||
|
||||
|
||||
|
||||
* Read Your Own Writes Consistency
|
||||
|
||||
A client will see his updates immediately after they are written. The reads can hit nodes other than the one where it was written. However he might not see updates by other clients immediately.
|
||||
|
||||
* Session Consistency:
|
||||
|
||||
A client will see the updates to his data within a session scope. This generally indicates that reads & writes occur on the same server. Other clients using the same nodes will receive the same updates.
|
||||
|
||||
* Casual Consistency
|
||||
|
||||
A system provides causal consistency if the following condition holds: write operations that are related by potential causality are seen by each process of the system in order. Different processes may observe concurrent writes in different orders
|
||||
|
||||
|
||||
|
||||
|
||||
Eventual consistency is useful if concurrent updates of the same partitions of data are unlikely and if clients do not immediately depend on reading updates issued by themselves or by other clients.
|
||||
|
||||
Depending on what consistency model was chosen for the system (or parts of it), determines where the requests are routed, ex: replicas.
|
||||
|
||||
CAP alternatives illustration
|
||||
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<td>Choice
|
||||
</td>
|
||||
<td>Traits
|
||||
</td>
|
||||
<td>Examples
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Consistency + Availability
|
||||
<p>
|
||||
(Forfeit Partitions)
|
||||
</td>
|
||||
<td>2-phase commits
|
||||
<p>
|
||||
Cache invalidation protocols
|
||||
</td>
|
||||
<td>Single-site databases Cluster databases
|
||||
<p>
|
||||
LDAP
|
||||
<p>
|
||||
xFS file system
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Consistency + Partition tolerance
|
||||
<p>
|
||||
(Forfeit Availability)
|
||||
</td>
|
||||
<td>Pessimistic locking
|
||||
<p>
|
||||
Make minority partitions unavailable
|
||||
</td>
|
||||
<td>Distributed databases Distributed locking Majority protocols
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Availability + Partition tolerance (Forfeit Consistency)
|
||||
</td>
|
||||
<td>expirations/leases
|
||||
<p>
|
||||
|
|
@ -100,22 +6,22 @@ conflict resolution optimistic
|
|||
</td>
|
||||
<td>DNS
|
||||
<p>
|
||||
Web Caching
|
||||
Web caching
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
|
||||
## Versioning of Data in distributed systems
|
||||
### Versioning of Data in distributed systems
|
||||
|
||||
When data is distributed across nodes, it can be modified on different nodes at the same time (assuming Strict consistency is enforced). Questions arise on conflict resolution for concurrent updates. Some of the popular conflict resolution mechanism are
|
||||
When data is distributed across nodes, it can be modified on different nodes at the same time (assuming strict consistency is enforced). Questions arise on conflict resolution for concurrent updates. Some of the popular conflict resolution mechanism are
|
||||
|
||||
|
||||
|
||||
* **Timestamps**
|
||||
|
||||
This is the most obvious solution. You sort updates based on chronological order and choose the latest update. However this relies on Clock synchronization across different parts of the infrastructure. This gets even more complicated when parts of systems are spread across different geographic locations.
|
||||
This is the most obvious solution. You sort updates based on chronological order and choose the latest update. However this relies on clock synchronization across different parts of the infrastructure. This gets even more complicated when parts of systems are spread across different geographic locations.
|
||||
|
||||
* **Optimistic Locking**
|
||||
|
||||
|
|
@ -123,18 +29,21 @@ When data is distributed across nodes, it can be modified on different nodes at
|
|||
|
||||
* **Vector Clocks**
|
||||
|
||||
A vector clock is defined as a tuple of clock values from each node. In a distributed environment, each node maintains a tuple of such clock values which represent the state of the nodes itself and its peers/replicas. A clock value may be real timestamps derived from local clock or version no.
|
||||
A vector clock is defined as a tuple of clock values from each node. In a distributed environment, each node maintains a tuple of such clock values which represent the state of the nodes itself and its peers/replicas. A clock value may be real timestamps derived from local clock or version no.
|
||||
|
||||
|
||||
|
||||
|
||||
<p id="gdcalert1" ><span style="color: red; font-weight: bold" images\vector_clocks.png> </span><br>(<a href="#">Back to top</a>)(<a href="#gdcalert2">Next alert</a>)<br><span style="color: red; font-weight: bold">>>>>> </span></p>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<p id="gdcalert1" ><span style="color: red; font-weight: bold">>>>>> gd2md-html alert: inline image link here (to images/image1.png). Store image on your image server and adjust path/filename/extension if necessary. </span><br>(<a href="#">Back to top</a>)(<a href="#gdcalert2">Next alert</a>)<br><span style="color: red; font-weight: bold">>>>>> </span></p>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
** Vector clocks illustration **
|
||||
** Vector clocks illustration **
|
||||
|
||||
Vector clocks have the following advantages over other conflict resolution mechanism
|
||||
|
||||
|
|
@ -143,10 +52,10 @@ Vector clocks have the following advantages over other conflict resolution mecha
|
|||
1. No dependency on synchronized clocks
|
||||
2. No total ordering of revision nos required for casual reasoning
|
||||
|
||||
No need to store and maintain multiple versions of the data on different nodes.** **
|
||||
No need to store and maintain multiple versions of the data on different nodes.** **
|
||||
|
||||
|
||||
## Partitioning
|
||||
### Partitioning
|
||||
|
||||
When the amount of data crosses the capacity of a single node, we need to think of splitting data, creating replicas for load balancing & disaster recovery. Depending on how dynamic the infrastructure is, we have a few approaches that we can take.
|
||||
|
||||
|
|
@ -154,7 +63,7 @@ When the amount of data crosses the capacity of a single node, we need to think
|
|||
|
||||
1. **Memory cached**
|
||||
|
||||
These are partitioned in-memory databases that are primarily used for transient data. These databases are generally used as a front for traditional RDBMS. Most frequently used data is replicated from a rdbms into a memory database to facilitate fast queries and to take the load off from backend DB’s. A very common example is memcached.
|
||||
These are partitioned in-memory databases that are primarily used for transient data. These databases are generally used as a front for traditional RDBMS. Most frequently used data is replicated from a rdbms into a memory database to facilitate fast queries and to take the load off from backend DB’s. A very common example is memcached or couchbase.
|
||||
|
||||
2. **Clustering**
|
||||
|
||||
|
|
@ -166,7 +75,7 @@ When the amount of data crosses the capacity of a single node, we need to think
|
|||
|
||||
4. **Sharding**
|
||||
|
||||
Sharing refers to dividing data in such a way that data is distributed evenly (both in terms of storage & processing power) across a cluster of nodes. It can also imply data locality, which means similar & related data is stored together to facilitate faster access. A shard in turn can be further replicated to meet load balancing or disaster recovery requirements. A single shard replica might take in all writes (single leader) or multiple replicas can take writes (multi-leader). Reads can be distributed across multiple replicas. Since data is now distributed across multiple nodes, clients should be able to consistently figure out where data is hosted. We will look at some of the common techniques below. The downside of sharding is that joins between shards is not possible. So a upstream/downstream application has to aggregate the results from multiple shards.
|
||||
Sharing refers to dividing data in such a way that data is distributed evenly (both in terms of storage & processing power) across a cluster of nodes. It can also imply data locality, which means similar & related data is stored together to facilitate faster access. A shard in turn can be further replicated to meet load balancing or disaster recovery requirements. A single shard replica might take in all writes (single leader) or multiple replicas can take writes (multi-leader). Reads can be distributed across multiple replicas. Since data is now distributed across multiple nodes, clients should be able to consistently figure out where data is hosted. We will look at some of the common techniques below. The downside of sharding is that joins between shards is not possible. So an upstream/downstream application has to aggregate the results from multiple shards.
|
||||
|
||||
|
||||
|
||||
|
|
@ -180,7 +89,7 @@ When the amount of data crosses the capacity of a single node, we need to think
|
|||
**<span style="text-decoration:underline;"> Sharding example</span>**
|
||||
|
||||
|
||||
## Hashing
|
||||
### Hashing
|
||||
|
||||
A hash function is a function that maps one piece of data—typically describing some kind of object, often of arbitrary size—to another piece of data, typically an integer, known as _hash code_, or simply _hash_. In a partitioned database, it is important to consistently map a key to a server/replica.
|
||||
|
||||
|
|
@ -203,9 +112,9 @@ Where
|
|||
The downside of this simple hash is that, whenever the cluster topology changes, the data distribution also changes. When you are dealing with memory caches, it will be easy to distribute partitions around. Whenever a node joins/leaves a topology, partitions can reorder themselves, a cache miss can be re-populated from backend DB. However when you look at persistent data, it is not possible as the new node doesn’t have the data needed to serve it. This brings us to consistent hashing.
|
||||
|
||||
|
||||
### Consistent hashing
|
||||
#### Consistent Hashing
|
||||
|
||||
Consistent Hashing is a distributed hashing scheme that operates independently of the number of servers or objects in a distributed _hash table_ by assigning them a position on an abstract circle, or _hash ring_. This allows servers and objects to scale without affecting the overall system.
|
||||
Consistent hashing is a distributed hashing scheme that operates independently of the number of servers or objects in a distributed _hash table_ by assigning them a position on an abstract circle, or _hash ring_. This allows servers and objects to scale without affecting the overall system.
|
||||
|
||||
Say that our hash function h() generates a 32-bit integer. Then, to determine to which server we will send a key k, we find the server s whose hash h(s) is the smallest integer that is larger than h(k). To make the process simpler, we assume the table is circular, which means that if we cannot find a server with a hash larger than h(k), we wrap around and start looking from the beginning of the array.
|
||||
|
||||
|
|
@ -224,28 +133,28 @@ In consistent hashing when a server is removed or added then only the keys from
|
|||
To evenly distribute the load among servers when a server is added or removed, it creates a fixed number of replicas ( known as virtual nodes) of each server and distributes it along the circle. So instead of server labels S1, S2 and S3, we will have S10 S11…S19, S20 S21…S29 and S30 S31…S39. The factor for a number of replicas is also known as _weight_, depending on the situation.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
All keys which are mapped to replicas Sij are stored on server Si. To find a key we do the same thing, find the position of the key on the circle and then move forward until you find a server replica. If the server replica is Sij then the key is stored in server Si.
|
||||
|
||||
Suppose server S3 is removed, then all S3 replicas with labels S30 S31 … S39 must be removed. Now the objects keys adjacent to S3X labels will be automatically re-assigned to S1X, S2X and S4X. All keys originally assigned to S1, S2 & S4 will not be moved.
|
||||
Suppose server S3 is removed, then all S3 replicas with labels S30 S31 … S39 must be removed. Now the objects keys adjacent to S3X labels will be automatically re-assigned to S1X, S2X and S4X. All keys originally assigned to S1, S2 & S4 will not be moved.
|
||||
|
||||
Similar things happen if we add a server. Suppose we want to add a server S5 as a replacement of S3 then we need to add labels S50 S51 … S59. In the ideal case, one-fourth of keys from S1, S2 and S4 will be reassigned to S5.
|
||||
|
||||
When applied to persistent storages, further issues arise: if a node has left the scene, data stored on this node becomes unavailable, unless it has been replicated to other nodes before; in the opposite case of a new node joining the others, adjacent nodes are no longer responsible for some pieces of data which they still store but not get asked for anymore as the corresponding objects are no longer hashed to them by requesting clients. In order to address this issue, a replication factor (r) can be introduced.
|
||||
When applied to persistent storages, further issues arise: if a node has left the scene, data stored on this node becomes unavailable, unless it has been replicated to other nodes before; in the opposite case of a new node joining the others, adjacent nodes are no longer responsible for some pieces of data which they still store but not get asked for anymore as the corresponding objects are no longer hashed to them by requesting clients. In order to address this issue, a replication factor (r) can be introduced.
|
||||
|
||||
Introducing replicas in a partitioning scheme—besides reliability benefits—also makes it possible to spread workload for read requests that can go to any physical node responsible for a requested piece of data. Scalability doesn’t work if the clients have to decide between multiple versions of the dataset, because they need to read from a quorum of servers which in turn reduces the efficiency of load balancing.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Quorum
|
||||
### Quorum
|
||||
|
||||
Quorum is the minimum number of nodes in a cluster that must be online and be able to communicate with each other. If any additional node failure occurs beyond this threshold, the cluster will stop running.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
To attain a quorum, you need a majority of the nodes. Commonly it is (N/2 + 1), where N is the total no of nodes in the system. For ex,
|
||||
|
||||
|
|
@ -253,7 +162,9 @@ In a 3 node cluster, you need 2 nodes for a majority,
|
|||
|
||||
In a 5 node cluster, you need 3 nodes for a majority,
|
||||
|
||||
In a 6 node cluster, you need 4 nodes for a majority.
|
||||
In a 6 node cluster, you need 4 nodes for a majority.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -261,22 +172,6 @@ In a 6 node cluster, you need 4 nodes for a majority.
|
|||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<p id="gdcalert5" ><span style="color: red; font-weight: bold">>>>>> gd2md-html alert: inline image link here (to images/image5.png). Store image on your image server and adjust path/filename/extension if necessary. </span><br>(<a href="#">Back to top</a>)(<a href="#gdcalert6">Next alert</a>)<br><span style="color: red; font-weight: bold">>>>>> </span></p>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<p id="gdcalert6" ><span style="color: red; font-weight: bold">>>>>> gd2md-html alert: inline image link here (to images/image6.png). Store image on your image server and adjust path/filename/extension if necessary. </span><br>(<a href="#">Back to top</a>)(<a href="#gdcalert7">Next alert</a>)<br><span style="color: red; font-weight: bold">>>>>> </span></p>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network problems can cause communication failures among cluster nodes. One set of nodes might be able to communicate together across a functioning part of a network but not be able to communicate with a different set of nodes in another part of the network. This is known as split brain in cluster or cluster partitioning.
|
||||
|
|
@ -289,8 +184,9 @@ Below diagram demonstrates Quorum selection on a cluster partitioned into two se
|
|||
|
||||
|
||||
|
||||
<p id="gdcalert7" ><span style="color: red; font-weight: bold">>>>>> gd2md-html alert: inline image link here (to images/image7.png). Store image on your image server and adjust path/filename/extension if necessary. </span><br>(<a href="#">Back to top</a>)(<a href="#gdcalert8">Next alert</a>)<br><span style="color: red; font-weight: bold">>>>>> </span></p>
|
||||
<p id="gdcalert5" ><span style="color: red; font-weight: bold">>>>>> gd2md-html alert: inline image link here (to images/image5.png). Store image on your image server and adjust path/filename/extension if necessary. </span><br>(<a href="#">Back to top</a>)(<a href="#gdcalert6">Next alert</a>)<br><span style="color: red; font-weight: bold">>>>>> </span></p>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue