Big Data & Scripting storage networks and distributed file systems

Transcription

1 Big Data & Scripting storage networks and distributed file systems 1,

2 2, adaptivity: Cut-and-Paste 1 distribute blocks to [0, 1] using hash function start with n nodes: n equal parts of [0, 1] [0, 1] N n 1, ( i 1, i ] N n n i adding a node: reassign stripe of width 1 n+1 from each part to new node N n+1 move blocks in these parts to N n+1 fuse new part together sorted by previous block assignment consider as one continuous interval 1 Brinkmann, Salzwedel, Scheideler Efficient, distributed data placement strategies for storage area networks, 2000

3 3, adaptivity: Cut-and-Paste assumption: hash function yields uniform random distribution expected equal distribution of blocks to nodes node addresses can be determined without keeping table retrace splitting scheme ordering before fusing allows exact location not applicable in heterogeneous situations extensions to heterogeneous case exist 2 2 Brinkmann, Salzwedel, Scheideler Compact adaptive placement schemes for non-uniform requirements, 2002

4 4, data access until now: store and retrieve blocks distribution and redundancy by duplicates open: accessing this data possible guarantees/properties: parallel data access distributed among nodes synchronization with read operations (i.e. read always current state) synchronization of write/update operations (e.g. which update wins) performance: latency = time until system reacts to request bandwidth = transferable data per time unit (e.g. Mb/s) update strategy determines guarantees and strategies for read access

5 data access: consistency and synchronicity redundancy block update affects multiple nodes synchronous updates sequence of read write accesses yields correct results example: write operation A 1 affects one copy of a block B i next read access A 2 reads different copy of B i all copies of B i should be identical (synchronous) consistency parallel updates should not lead to alternative histories example: simultaneous updates A 1 and A 2 to different copies of block B i [] two copies of B i in different states determine winner copy of B i or prevent parallel update 5,

6 6, data access: master copy the master copy can be used ensure consistency: block B i has r duplicates: B 1 i,..., B r i a single, distinguished copy is B i s master copy, say B 1 i consistency is ensured by limiting write access to the master copy reading: use any copy reading in parallel is allowed writing: write only to master copy update duplicates from master

7 7, data access: master copy updates can be executed using different strategies, resulting in different guarantees immediately hold reading access when master copy is written can guarantee synchronicity lazily e.g. when system load allows without blocking access copies can be in obsolete state

8 8, data access: master copy access-blocking needs centralized write access centralization leads to bottle-necks in efficiency and security guarantees like synchronicity can often only be given in exchange for efficiency: synchronous systems with immediate update have block reading access on updates ( centralization) can guarantee synchronicity and consistency asynchronous / lazy updates can still guarantee consistency no synchronicity without centralized reading access

9 9, data access: without master copy writing is allowed to any duplicate synchronicity could be achieved by blocking duplicates blocking in a distributed situation as complicated easily leads to locking situations updates without blocking or master copy parallel writing is allowed two duplicates can be in different updated states neither synchronicity nor consistency guaranteed synchronization strategy needed to resolve inconsistencies duplicates in different states have to be reunified example: latest update always wins

10 10, data access: transactions abstraction of grouped updates implement invariants in storage systems example: online store (1) outstanding debts, (2) bills to be send (3) goods available, (4) goods to be send when order is placed, ensure (1)-(4) are all updated (purchase successful, transaction completed) not updated at all (purchase failed, transaction failed) transactions group individual updates together usually either all updates are executed or none (atomic) system can guarantee properties for transactions e.g. ACID (atomic, consistent, isolated, durable) in RDBMS implementation very complex in distributed systems

11 11, data access: the CAP-theorem formalize guarantees and network model: consistency transactions, guarantee ACID-properties allows to keep system in a consistent state availability data still accessible if nodes fail (e.g. backups) partition tolerance tolerate disconnection of the network individual parts function independently allows arbitrary scaling network model no global clock (asynchronous) nodes decide on local information

12 12, data access: the CAP theorem CAP theorem Maximal two properties out of consistency, availability and partition tolerance can be guaranteed. conjectured by Brewer, 2000 proven for an asynchronous network model 3 improvements are possible when nodes have a global timer (synchronous network model) keeping all nodes on single, global time is very complicated (if possible at all) 3 Lynch, Gilbert, Brewer s conjecture and the feasibility of consistent, available, partition-tolerant web services, 2002

13 13, data access: trade-offs redundancy enables parallelism and failure tolerance enforces updates in multiple places collides with efficiency synchronicity and consistency systems differ in the subset of properties they provide optimal system for particular task result of required guarantees distributed RDBMS systems: consistency, availability NOSQL 4 systems: availability, partition tolerance 4 not only SQL