(高级数据库)-A-Dyanmo.pptx

Dyanmo;Dynamo;It sacrifices strong consistency for availability: always writable Incremental scalability Symmetry: every node should have the same set of responsibilities as its peers Decentralization Heterogeneity;Data partitioning Replication Data versioning Dynamo API Membership management;Service Level Agreements (SLA);Data Partitioning;If size of data exceeds the capacity of a single machine: partitioning Sharding data (horizontal partitioning). Consistent hashing is one form of automatic sharding.;hash(Fatemeh) = 12 hash(Ahmad) = 2 hash(Seif) = 9 hash(Jim) = 14 hash(Sverker) = 4;Load ImbalanceConsistent hashing may lead to imbalance.;Load ImbalanceConsistent hashing may lead to imbalance.;Load Balancing via Virtual Nodes;Advantages of using virtual nodes;Replication;Updates are propagated asynchronously. Each update/modication of an item results in a new and immutable version of the data. Multiple versions of an object may exist. Replicas eventually become consistent.;Version branching can happen due to node/network failures. I Use vector clocks for capturing causality, in the form of (node, counter) If causal: older version can be forgotten If concurrent: conflict exists, requiring reconciliation;Data Versioning Example;get(key) Return single object or list of objects with conflicting version and context. put(key, context, object) Store object and context under key. Context encodes system metadata, e.g., version number. Client can send the request: To the node responsible for the data (coordinator): save on latency, code on client To a generic load balancer: extra hope Coordinator generates new vector clock and writes the new version locally.;Coordinator generates new vector clock and writes the new version locally. Send to N nodes. Wait for response from W nodes. Using W=1 High availability for writes Low durability;Coordinator requests existing versions from N. Wait for response from R nodes. If multiple versions, return all versions that are causally unr