MODULE 2 PPT distribution models, sharding,msp

Distribution oii is Models

1. D I STR I B U T I O N MODELS

2. PA TH S O F D A T A D I ST I B U T I O N Replication takes the same data and copies it over multiple nodes. Replication comes into two forms: Master-slave and Peer-to-peer Sharding puts different data on different nodes.

3. SINGLE SERVER Run the database on a single machine that handles all the operation to store the data.

4. SH ARDIN G Horizontal Scalability. Responsive. Load Balancing. Performance. Auto Sharding.

5. MASTER SLAVE REPLICATION Offloading. Read Resilience. Recovery.

6. PEER TO PEER REPLICATION Complication : Consistency

7. C OM B I N I N G S H ARD I N G AN D RE P L I C A T I O N Using Master-slave Replication Together With Sharding Using Peer-to-peer Replication Together With Sharding

8. KE Y P O IN T S There are two styles of distributing data: Sharding distributes different data across multiple servers, so each server acts as the single source for a subset of data. Replication copies data across multiple servers, so each bit of data can be found in multiple places.

9. KE Y P O IN T S A system may use either or both techniques. Replication comes in two forms: Master-slave replication makes one node the authoritative copy that handles writes while slaves synchronize with the master and may handle reads. Peer-to-peer replication allows writes to any node; the nodes coordinate to synchronize their copies of the data. Master-slave replication reduces the chance of update conflicts but peer-to-peer replication avoids loading all writes onto a single point of failure.

10. CONSISTENCY CAP THE O REM EVE N TU A L CO N SISTEN C Y

11. UPDATE CONSITENCY Write – Write Conflict Serialization Approaches For Maintaining Consistency Pessimistic Optimistic Conditional Update Concurrent Programming

12. READ CONSISTENCY Read – Write Conflict Logical Consistency Acid Transactions Inconsistency Window

13. REPLICATION INCONSISTENCY Eventual Consistency Stale Read-yours-write Consistency Session Consistency Sticky Session

14. RELAXING CONSISTENCY C A P Theorem Availability Par t i t i o n T ole r ance Split Brain ACID Property BASE Property

15. RELAXING DURABILITY Replication Durability

16. Quorums Write Quorums Replication Factor

17. KE Y P O IN T S Write-write conflicts occur when two clients try to write the same data at the same time. Read write conflicts occur when one client reads inconsistent data in the middle of another client’s write. Pessimistic approaches lock data records to prevent conflicts. Optimistic approaches detect conflicts and fix them. Distributed systems see read-write conflicts due to some nodes having received updates while other nodes have not. Eventual consistency means that at some point the system will become consistent once all the writes have propagated to all the nodes. Clients usually want read-your-writes consistency, which means a client can write and then immediately read the new value. This can be difficult if the read and the write happen on different nodes.

18. KE Y P O IN T S To get good consistency, you need to involve many nodes in data operations, but this increases latency. So you often have to trade off consistency versus latency. The CAP theorem states that if you get a network partition, you have to trade off availability of data versus consistency. Durability can also be traded off against latency, particularly if you want to survive failures with replicated data. You do not need to contact all replicants to preserve strong consistency with replication; you just need a large enough quorum.

19. Version Stamps Business and System Transactions Compare and set (CAS) GUID Advantage Composite Stamp

20. Version Stamps on Multiple Nodes The are specific forms of vector stamps Vector clocks and Version vectors

21. K E Y P O I N T S Version stamps help you detect concurrency conflicts. When you read data, then update it, you can check the version stamp to ensure nobody updated the data between your read and write. Version stamps can be implemented using counters, GUIDs, content hashes, timestamps, or a combination of these. With distributed systems, a vector of version stamps allows you to detect when different nodes have conflicting updates

22. THANK YOU

23. ANY QUESTIONS?