Distributed Database

> (Data|State) Management and Processing > Distributed Database

1 - About

Distributed systems is the opposite of a single node (ie computer).

Advertising

3 - Design

Scale across the system bus before you scale across the network with distributed systems. It is all the same design principles. Think of design as fractal.

3.1 - Service

In a distributed application, different pieces of the app are called “services.”

A service for:

  • storing application data in a database,
  • image transcoding in the background (after a user uploads something)
  • for the front-end

4 - Challenges

4.1 - Divide

  • How do we divide the work across machines (network latency), data locality (moving data may be very expensive),

4.2 - Failure

dealing with failures. If a server fails on average every three years, with 10,000 nodes in our cluster we'll see 10 faults per day.

The simplest solution is to just launch another task, either on that machine if it's recovered, or on another machine.

Advertising

4.3 - Stragglers

dealing with stragglers (much more common than failure). (Nodes|Task) that have not failed, but are just running very slowly.

The simplest solution is to launch another task (on a different machine if needed) and then kill the original task.

5 - Distributed system

5.1 - Two-Phase Commit

The Two-Phase Commit is fairly standard for synchronous processing in order to avoid inconsistent state in a distributed environment.

Phase 1:

  • Coordinator Sends “Prepare to Commit”
  • Subordinates make sure they can do so no matter what
  • Write the action to a log to tolerate failure
  • Subordinates Reply “Ready to Commit”

Phase 2:

  • If all subordinates ready, send “Commit”
  • If anyone failed, send “Abort”

1) User wants to Update; 2) Prepare; 3) Write to Log; 4) Ready; 5) Commit

First the User wants to Update, then the update is prepared, written to log, set to a ready state, and finally committed to the database.

Advertising

5.2 - Eventually consistent

5.3 - CAP theorem

Distributed Database - CAP Theorem (Consistency, Availability, Partition Tolerance)

With the CAP theorem in minde, distributed system has two priority strategy:

  • prioritized availability - NoSQL
  • prioritized consistency - newSQL

5.4 - Process

The holy grail of distributed data processing

  • Submit (commit) locally: queue and manage your jobs task locally, leverage your local resources
  • Run Globally: Acquire any resource that is capable and willing to run your job/task

5.5 - Paper

6 - Documentation / Reference