Providing Big Data Applications with
Fault-Tolerant Data Migration Across
Heterogeneous NoSQL databases
Marco Scavuzzo, Damian A. Tamburri, Elisabetta Di Nitto
Politecnico di Milano, Italy
BIGDSE ‘16 – May 16th 2016, Austin
NoSQLs and Big Data
applications
Highly-available, big data applications need specific storage
technologies:
Distributed File Systems – DFSs (e.g., HDFS, Ceph, etc.)
NoSQL databases (e.g., Riak, Cassandra, MongoDB, Neo4j, etc.)
NoSQLs preferred to DFSs for:
Efficient data access (for reads and/or writes)
Concurrent data access
Adjustable data consistency and integrity policies
Logics (filter, group, aggregate) in the data layer in place of the
application layer (Hive, Pig, etc.).
2
NoSQLs heterogeneity
Lack of standard data access interfaces and languages
Lack of common data models (e.g., data types, secondary indexes,
integrity constraints, etc.)
Different architectures leading to different ways
of approaching important problems (e.g., concurrency control,
replication, transactions, etc.)
3
Vendor
lock-in
“The lack of standards due to most
NoSQLs creating their own APIs [..]
is going to be a nightmare in due
course of time w.r.t. porting
applications from one NoSQL to
another. Whether it is an open
source system or a proprietary one,
users will feel locked in.”
C. Mohan
4
Research objective
Provide a method and supporting architecture to aid
fault-tolerant data migration across heterogeneous
NoSQL databases for Big Data applications
Hegira4Cloud
5
Hegira4Cloud
requirements
1. Big Data migration across any NoSQL database and Database
as a Service (DaaS)
2. High performant data migration
3. Fault-tolerant data migration
6
Hegira4Cloud approach
Conversion to the
Metamodel Format
Migration System Core
Source
DB
SRC
MIGRATION QUEUE
TWC
Target
DB
Conversion from the
Metamodel Format
7
Hegira4Cloud V1
Migration System Core
Source
DB
SRC
MIGRATION QUEUE
TWC
Target
DB
Monolithic architecture data migration GAE Datastore -> Azure Tables
dataset #1
dataset #2
dataset #3
Source size (MB)
16
64
512
# of Entities
36940 ~18m 147758 ~71m 1182062 ~568m
Migration time (sec)
1098
4270
34111
Entities throughput (ent/s)
33.643
34.604
34.653
Avg. %CPU usage
4.749
3.947
4.111
8
Improving performance:
components decoupling
Source
DB
SRC
MIGRATION QUEUE
TWC
Target
DB
Components decoupling helps in:
distributing the computation (conversion to/from the intermediate meta
model);
isolating possible bottlenecks;
finding (and solving) errors.
9
Improving performance:
parallelization
Source
DB
SRC
SRC
SRC
MIGRATION QUEUE
TWC
TWC
TWC
Target
DB
Operations to be executed can be parallelized:
data extraction (from the source database)
data should be partitionable
data load (to the target database)
10
Improving performance:
TWC parallelization
Source
DB
SRC
SRC
SRC
MIGRATION QUEUE
TWC
TWC
TWC
Target
DB
Challenges:
avoid to duplicate data (i.e., process disjunct data only once)
avoid threads starvation
in case of fault, already extracted data shouldn’t be lost
Solution: RabbitMQ
messages distributed (disjointly) in round-robin fashion
messages correctly processed are acknowledged and removed
messages are persisted on disk
11
Improving performance:
SRC parallelization
Source
DB
SRC
SRC
SRC
METAMODEL QUEUE
TWC
TWC
TWC
Target
DB
Challenges:
complete knowledge of stored data is needed to partition data
partitions should be processed at most once (to avoid duplications)
12
Improving performance:
SRC parallelization
Source
DB
Lets assume
that data are
associated
VDP1
with an
unique,
incremental
primary key (orVDP2
an indexed
property)
VDP3
SRC
SRC
SRC
MIGRATION QUEUE
TWC
TWC
TWC
Target
DB
Source DB
1
…
10
11
…
References to
the VDPs are
stored inside a
persistent
storage
20
21
…
30
13
Addressing faults
Source
DB
SRC
MIGRATION QUEUE
TWC
Target
DB
Types of (non-trivial) faults:
Database faults
Components faults
Network faults
Connection loss
On connection loss, not all databases guarantee a unique pointer to the
data (e.g., Google Datastore)
14
Virtual data partitioning
Source DB
Key
Values
PARTITION STATUS
1
VDP1
2
…
not mig.
migrate
under
mig.
finish_mig
migrated
10
11
VDP2
VDP3
Status Log
…
20
VDPid
Status
21
1
migrated
…
2
under_mig
30
3
not_mig
ZooKeeper
15
Hegira4Cloud V2
STATUS
LOG
Source
DB
SRC
MIGRATION QUEUE
TWC
Target
DB
16
Hegira4Cloud V2:
Evaluation
Parallel distributed
architecture
Monolithic arcitecture
dataset #1 dataset #2 dataset #3 dataset #1
Source size (MB)
16
64
512
318464 (311GB)
# of Entities
36940
147758
1182062
~107M
Migration time (sec)
Entities throughput
(ent/s)
1098
4270
34111
124867 (34½h)
33.643
34.604
34.653
856.41
Avg. %CPU usage
4.749
3.947
4.111
49.87
1 Source Reading Thread
40 Target Writing Threads
17
Conclusions
Efficient, fault-tolerant method for data migration
Architecture supporting data migration across NoSQL
databases
Supporting several databases (Azure Tables, Cassandra,
Google Datastore, HBase)
Evaluated on industrial case study
Future work
Support online data migrations
Rigorous tests for assessing data completeness and
correctness
19
Marco
Scavuzzo
PhD student @
Politecnico di Milano
You can find me at: [email protected]
Credits
Presentation template by SlidesCarnival