1. HDDBRS MIDDLEWARE FOR IMPLEMENTING HIGHLY AVAILABLE DISTRIBUTED DATABASES
RIM MOUSSA, PHD
UTIC LAB. , TUNISIA
Project Goals
Implement
a
reliable,
scalable,
portable,
full-featured
high
availability
solution
for
distributed
databases, conformant with open standards.
3-tier distributed architecture
1. Client
more than
$1MpH, 8%
 Not aware of data distribution
 Not aware of data redundancy
DBCTm-1 Work.
Queue
DBCTm Work. Queue
DBCTi Work. Queue
JDBC Driver
 DB group k-available composed of m source
DB instances and k parity DB instances.
 Tables horizontally fragmented.
 Surjective function for record grouping.
between $51KpH and
$250KpH, 28%
High-availability Methods
REED SOLOMON
ERASURE
CODES
Data Stripping
Load Balancing
Encoding/
Decoding
Overhead
Quick Recovery
Minimal Storage
Overhead
Spare
Fig. 1. Middleware Architecture.
 Testbed: Oracle DBMS, 1.7GHz CPU on DB
DB connection Thread for each DB instance
Query Handler Thread
Distributed Transaction Handler Thread
Recovery Thread
RMI Thread …
Threads communicate through concurrent
queues (working and response queue for
each thread) and sleep and notify primitives.
backends, 2.7GHz mid-tier, all connected through
a100Mbps router,
 Insert Performances: 65ms, 140ms, 160ms for
respectively k = 0, 1, 2.
 Record Recovery Performances:
 130ms for a 3KB record,
 only 0.18ms for decoding.
 Fragments Recovery:
 JDBC Interface with DB backends.
 XA/open standard (2-PC protocol) for
distributed transaction management.
 RMI for client transaction processing.
High Storage
Cost
 One data fragment of 7.52MB recovered at a
rate of 720KBps.
 Two data fragments of 15.04MB recovered at
a rate of 690KBps.
 Decoding overhead is 6% of recovery time.
Demonstration Outline
Demonstrated Configuration:
 2-available group of 4 source
DB instances and 2 parity DB
instances (m = 4, k = 2) .
 Item
• Script to create
table fragments fon
each DB instance.
• DB population.
 Each item is 3KB.
DB Set up &
Population
Key Search
• Search item with
key i_id
• Either by deleting of
up to k fragments
contents or by
shutting down
corresponding DB
instances
Record
Recovery
• Recover item with
key i_id
•
•
•
•
Simulate k
Servers Failure
Set up k spares
Query alive servers
Decode
Insert recovered
data into spare
servers
Recover k
Servers
 Oracle DBMS instances
Future Work
References
Automatic
increase of
Performance a group
high
Test using
TPC-C bench availability
in both failure level
and safe
modes
[Khediri MSc
Project]
TH
18
Distributed
highly
available
DB which
autoscale
over a
cluster
.
.
.
Performances
 Multithreading






JDBC Driver
Spare
Middleware Architecture
REPLICATION
DBCTj Work. Queue
DBCTn Work. Queue
3. DB backends
JDBC Driver
 Redundant data management
 Recovery process (records and fragments)
 Failure detection …
up to $50KpH, 46%
Optimize
parity
updates
using
Jserver
.
.
.
2. HDDBRS Mid-tier
JDBC Driver
between $251KpH and
$1MpH, 18%
DBCT0 Work. Queue
DB Backends
A survey conducted by the CPR and ERA, in
2001 shows important downtime cost per
hour for questionned companies [1].
JDBC Driver
System Design
JDBC Driver
Downtime Cost
1. CPR, EAR, http://www.contingencyplanningresearch.com/cod.htm
2. Litwin, W., Moussa, R., Schwarz, T.J.E.: LH*RS - a highly available scalable
distributed data structure. ACM Trans., (2005)
3. Weatherspoon, H., Kubiatowicz, J.D.: Erasure Coding vs. Replication: A
quantitative Comparison. Proc. of the 1st International Workshop on P2P
Systems, (2002)
4. Cecchet, E., Marguerite, J., Zwaenepoel, W.: C-JDBC Flexible Database
Clustering Middleware. USENIX, (2004)
Further Information
URL: http://rim.moussa.googlepages.com/hddbrs_mid_project.html
Email: rim.moussa@googlepages.com
ACM CONFERENCE ON INFORMATION AND KNOWLEDGE MANAGEMENT, HONG KONG, 2009