A Fragmentation Algorithm for Storage Management
in Cloud Database Environment
Islam Eisa Rashed Salem
Faculty of Computers and Information Faculty of Computers and Information
Menoufia university Menoufia university
Email: eslam@sda.gov.eg Email: rsalem@ci.menofia.edu.eg
Abstract—The past decade has witnessed using cloud DBMSs
for enterprises’ applications and managing their data. However,
only a few number of cloud DBMSs have provided relational
database as a service and get benefits from being in cloud
data centers. Cloud DBMSs are grouped into two categories.
The first category is scalable datastores that cannot preserve
ACID for transactions over the entire database. The second
one is scalable traditional DBMSs that scale difficulty as they
migrate data or instances. This paper proposes a shared storage
architecture for cloud DBMS that reduces migration of data that
happens for preserving load balance between database instances
after increasing scalability by adding new database instances or
new storage devices. Moreover, it provides storage management
module that locates database objects well on storage devices
for parallel access in ’write and read’ operations with reducing
storage skewness and bottleneck, based on a new horizontally
fragmentation algorithm. Also, it provides storage monitoring
module for detecting skewness and reconfiguring the storage.
The proposed Cloud DBMS overcomes limitations in scalable data
stores and traditional DBMSs. We finally confirm the effectiveness
of the proposed architecture on real data sets.
I. I NTRODUCTION
Cloud Computing is a cost-efficient computing paradigm
in which computing resources are delivered to customers
through the Internet. The US National Institute of Standards
and Technology (NIST) have published a working definition
[1] for cloud characteristics which represents on-demand self-
service, broad network access, resource pooling which can be
shared between many tenants, rapid elasticity and measured
service.
A Cloud database management system is a distributed
database that delivers computing as a service instead of a
product [2]. It holds the cloud computing properties, being
extremely scalable, supporting multi-tenancy, elasticity and
low cost as it uses pay per use model [3]. NoSQL Cloud
database providers use scalable data-stores which does not
support full transactional queries like G-store [4], Mega-store
[5], BigTable [6] and Elas-Tras data store [7] but achieves high
scalability and many cloud properties. On the other hand, SQL
or relational cloud database as a service like Relational Cloud
[8], Oracle Enterprise 12c [9], Unified MySQL Platform [10],
and Microsoft’s cloud SQL Server DBMS [11] support trans-
actional queries with full ACID (Atomicity, Consistency, Iso-
lation, and Durability). These cloud DBMSs have limitations
in providing cloud properties like scalability, elasticity, and
multi-tenancy. As they use shared nothing architecture, which
limits scalability and leads to migrating data for preserving
load balance between database instances [12], [13].
‹,((( 
Hatem Abdelkader
Faculty of Computers and Information
Menoufia university
Email: hatem.abdelkader@ci.menofia.edu.eg
Building a relational cloud DBMS that combines high
availability, scalability of NoSQL systems like BigTable, and
the consistency and usability of traditional SQL databases, is
the current challenge. New DBMS called F1 is built at Google
for Google’s AdWords on top of Spanner meeting required
properties at the expense of higher latency for typical reads
and writes and using fat client [14].
For solving these problems, we propose an architecture for
cloud DBMSs infrastructure, which separates processing pool
from the storage pool and makes the latter shared between
all database instances. In this architecture, adding a new
database instance for a tenant does not require data migration
between instances since the data is shared between all tenants
that results in scalability enhancement. We propose a storage
management and monitoring module. It is responsible for
better data placement that balance I/O load in ’read and write’
operations between these storage devices. It groups related
data on most frequently accessed columns into fragments and
distribute each fragment on different storage devices.
The major contributions of this paper can be summarized
as follows: firstly, this paper suggests a storage management
system for shared storage cloud DBMSs that balances I/O
load between storage drives during ’write and read’ operations
together. Also, it reduces skewness in storage utilization and
increases elasticity and scalability using efficient data place-
ment algorithm. Secondly, it proposes an automatic storage
utilization monitoring and data reconfiguration module that
detect skewness and reconfigures data on storage devices.
The rest of the paper is organized as follows: related re-
search to the proposed architecture is discussed in Section II. A
practically shared storage DBMS architecture that incorporates
our storage management and concurrency control modules is
introduced in Section III. Section IV details the proposed stor-
age management module for shared storage DBMS. Section
V shows the results of the comparison between our enhanced
cloud DBMS and other cloud DBMSs. Finally, we conclude
this paper in Section VI.
II. R ELATED W ORK
Several researches have been conducted on increasing
scalability, elasticity and enhancing storage management for
cloud relational DBMS. They propose new data placement
techniques, storage utilization monitoring systems, storage
reconfiguration and migration techniques for either data or in-
stances. These algorithms aim to increase transactions through-
put by distributing data on a large number of storage devices
and balancing I/O ’read and write’ workload between them,
reduce the data migration occurrence ratio and reduce the cost
while preserving consistency. These goals lead to enhancing
database performance and achieving near linear scalability
besides preserving ACID characteristics.
Data placement techniques. for cloud DBMS including
DAX, Oracle ASM and RAID have been proposed. DAX is
a back-end storage service for enhancing storage management
in cloud DBMS [15]. It aims at providing network-accessible
persistent storage for hosted DBMS tenants. Each DBMS
tenant, in turn, is served using only a database instance. Each
DBMS tenant has a DAX client library, and they all are
attached to shared DAX storage tier which provides a reliable,
widely distributed, and shared block storage service. DAX has
some constraints on the relational DBMS including:
• Database cannot be managed using different instances
even if it is too large and serves many clients at
a real-time, since different tenants (instances) don’t
communicate with each other.
• Optimistic I/O technique does not balance the load for
’read and write’ operations between storage devices,
so bottle-neck on storage devices may happen as a
result of placing associated blocks on one hard drive.
Another solution for enhancing DBMS scalability and
improving storage management is Oracle Automatic Storage
Management (ASM) [16]. ASM collects physical drives into
disk groups where one or more disk groups can be assigned
to a database. ASM automates the physical placement of
database segment on its disk groups. New database segment is
evenly distributed to all storage devices to scale performance,
maximize storage utilization, and balance I/O operations.
ASM allows changes of physical storage configuration without
taking database off-line. ASM solution works on a per-DB
level, requiring a dedicated disk group to be allocated to
each database. All storage devices cannot be shared among
all DBMS nodes. ASM balances I/O load between disk drives
in ’write’ only, whereas ’read’ requested blocks may be found
on one hard drive.
Moreover, RAID controllers provide data partitioning and
placement techniques that efficiently partition database seg-
ment across many storage devices for parallel access during
’write and read’ operations. They work at block level without
DBMS knowledge of what the blocks store and how they are
being utilized, this lead to suboptimal usage of the storage.
They achieve balancing I/O among storage devices during
’write’ operations only and not in ’read’ operations.
Storage monitoring and reconfiguration techniques.
STORM is a storage utilization monitoring system that pro-
vides a data movement strategy for moving a large amount
of data between storage devices during considerable storage
bandwidth and time [17]. STORM has a TableMapper compo-
nent which has access to database servers and SAN storage
pool to gather information using DBMON and STMON,
respectively. The dynamic data layout reconfiguration problem
is a non-linear hard one. Using heuristics, STORM presents an
approximate solution in O(N log(N/M ) + (N/M )2 ) whereas
M is the number of storage devices and N is the total number
of database objects in the storage devices.
Migration techniques. There are several migration tech-
niques which have many types including asynchronous, syn-
chronous and live migration. Albatross [18], a technique to live

migrate a cell in shared storage architectures with no aborted
transactions and minimal performance impact. In shared stor-
age architecture, the persistent image of a cell is stored in a
network addressable storage abstraction and hence does not
need migration. Albatross focuses on migrating the database
cache and the state of active transactions between database
instances.
III. P ROPOSED C LOUD DBMS A RCHITECTURE
Cloud DBMSs should allow tenants’ elastic resource pro-
visioning either in storage or computing. An enhanced archi-
tecture for cloud data centers that provides DBaaS on shared
storage architecture with efficient storage management for
shared storage DBMSs is suggested. The proposed architecture
is also featured with efficient data placement, storage provi-
sioning, and storage utilization monitoring and reconfiguration.
It decreases data migration among instances and storage re-
configuration processes. It also enhances DBMS performance,
preserve consistency and increase queries throughput. The
proposed architecture exploits the shared process model as
it manipulates resources consumption and isolation well [19],
[20].
Figure 1 presents the proposed architecture for cloud data
centers which provide relational DBaaS. It suggests virtualiz-
ing network layer and computing layer only.
Fig. 1. Proposed cloud data center architecture
In network layer, it assigns each tenant desired bandwidth
according to his requirements. In the computing layer, it
collects the resources of all physical servers, making a com-
puting pool, and creates minimum allowed number of virtual
machines that can use these resources where maximum virtual
machine resources are 64 virtual CPUs, one terabyte RAM
and one terabyte swap area [21]. Minimizing number of virtual
machines reduces network communications between database
tenants hosted on different servers. On the other hand, the
proposed architecture does not virtualize the storage layer,
it shares the storage between virtual machines and uses a
proposed storage management module that balances the I/O
load between storage devices for DBMS operations better than
RAID controllers.
 IV. S TORAGE M ANAGEMENT M ODULE
Storage management is a key important module in cloud Data:
DBMS. Many storage management systems for cloud DBMSs, • Relation to be fragmented (R)
like Oracle ASM, DAX and RAID, still have limitations in • Frequency of accessing each column
elasticity, balancing the I/O load among storage devices and f (A1), . . . , f (An)
increasing DBMS scalability as they have to migrate data after • Applications predicates (P r = p1, . . . , pn)
adding new database instance to balance load between them.
Result:
This research proposes a new storage management approach
that increases DBMS scalability, elasticity and balances I/O • Set of predicates on the most frequently accessed
load on all hard drives during the ’write and read’ operations. columns (pr‘)
• Set of roughly equivalent cardinality fragments
The proposed storage management approach utilizes
F = f 1, f 2, . . . , f n.
database statistics to determine which database tuples are
accessed together. Then, it distributes them to different storage begin
devices to guarantee balancing I/O load between storage de- w=u=v=1
vices during ’write and read’ operations. It applies horizontal for i ← 2 to n step i = i + 1 do
fragmentation algorithm to group each associated database if f (Ai ) > f (Aa ) then
tuples together into a fragment.Any tuple can be retrieved v=u
using different predicates. Thus, database tuples may be asso- u=w
ciated many times as a result of different predicates. The pro- w=i
posed storage management algorithm uses the most frequently else if f (Ai ) > f (Ab ) then
accessed three columns in order to fragment the database. v=u
This information is obtained from the database statistics and u=i
differs according to the database and the applications. If the else if f (Ai ) > f (Ac ) then
applications access the database using different qualifiers at v=i
close rates, the number of suitable columns for fragmentation else
increases. All fragments should almost have the same size. F s = 512 ∗ n(hd)
Fragment size is determined depending on the number of hard n(F ) = Rs/F s
drives, their characteristics and stripe size on hard drives. It Pa = {pa1 , pa2 , pa3 , . . . , pan : Aa θ V alue}
suggests stripe size 512 KB. whereas this size does not cause Pb = {pb1 , pb2 , pb3 , . . . , pbm : Ab θ V alue}
a large number of I/Os for executing a request. Thus, it does Pc = {pc1 , pc2 , pc3 , . . . , pck : Ac θ V alue}
not cause a delay for other outstanding I/O and makes good M ergeSort(F Pa , F Pa [1], F Pa [n])
parallelism for large queries. M ergeSort(F Pb , F Pb [1], F Pb [n])
The proposed horizontal fragmentation algorithm operates M ergeSort(F Pc , F Pc [1], F Pc [n])
as follows. Firstly, it gets the most frequently accessed three foreach Pi ∈ Pa do
columns, such columns can be determined using application if fi ∈ F then
predicates information, i.e., query qualifications. Secondly, it fi ← fi − (fi ∩ F )
gets the simple predicates for these columns. Thirdly, it sorts
these predicates according to their frequency using merge sort if s(fi ) < 0.5 ∗ Fs then
algorithm. Fourthly, it wraps between the most frequently pi+1 ← pi ∪ pi+1
accessed column predicates; if the predicate fragment size is else if s(fi ) > 2 ∗ Fs then
almost the predetermined fragment size, it adds this predicate foreach pj ∈ Pb do
to the output predicate set which will fragment the database, if s(fij ) < 0.5 ∗ Fs then
whereas each fragment will be parallel distributed on all pj+1 ← pj ∪ pj+1
storage devices. Otherwise, if the resulted fragment size is else if s(fij ) > 2 ∗ Fs then
lower than half of the fragment size, it combines this fragment foreach pm ∈ Pc do
with the later predicate. If the resulted fragment size is higher if s(fijm ) < 0.5 ∗ Fs then
than the predetermined size, it wraps between predicates pm+1 ← pm ∪ pm +1
for the second frequently accessed column to partition this else
fragment into lower size fragments, which are related together P r  ← P r  ∪ pm
and their tuples are accessed together. Finally, the algorithm F ← F ∪ fijm
gets predicates which fragment the database to parallel access
to each fragment where each fragment tuples are accessed else
together. P r  ← P r  ∪ pj
F ← F ∪ fij
Although the proposed storage management system pre-
vents skewness in storage utilization and gives high transaction else
throughput for each tenant, a storage utilization monitoring P r  ← P r  ∪ pi
system that detects skewness and re-configures the data on the F ← F ∪ fi
storage devices was proposed. The first task of storage monitor
and reconfiguration module is to gather information about a Algorithm 1: Horizontal fragmentation
number of blocks accessed by each tenant and their distribution
to storage devices for an interval of time from the DBMS. If the


 Data: X V. E XPERIMENTAL S TUDY
Result: x A. Configuration
/* initialization */ The proposed architecture has been simulated on an on-
if s < e then /* Check for base case */ premise private Cloud using UBUNTU Enterprise Cloud on
q = F LOOR[(s + e)/2]
two small Dell server with 4 cores 2.66 GHZ and 16 GB RAM.
/* Divide step */ The first server was configured to be a cloud controller and the
M ergeSort(A, s, q)
second one was configured to be a cloud node. It was plugged
/* Conquer step */ with a 60 GB SSD hard drive and 3 HDD 240 GB 7200
M ergeSort(A, q, e)
rpm. Three virtual machines have been created where each one
/* Conquer step */ represents a DBMS instance and then a virtual SAN storage
M erge(A, s, q, e)
has been created to store the data. Ubuntu 14.04 has been
/* Conquer step */ installed on each virtual machine. The storage management
Algorithm 2: MergeSort(X, s, e) function and utilization monitor algorithms have been implemented in
c++. They include a horizontal fragmentation algorithm for
partitioning database segments. A module for gathering and
Data: A analyzing heuristics about storage devices and DBMS opera-
Result: x tions, besides taking storage reconfiguration decision which
/* initialization */ uses merge sort algorithm was implemented. Finally, some
n1 ← q − s + 1 of other DBMS modules like indexing have been simulated
n2 ← e − q where it has used B + -tree and transaction processor for exe-
/* Create arrays L[], R[] */ cuting transactions like SQL select, insert, update and delete
for i ← 1 to n1 do statements to test and compare our algorithms performance
L[i] ← A[s + i − 1] against others. All these algorithms are implemented in C++,
for j ← 1 to n2 do and the servers communicate together and with clients using
R[j] ← A[q + j] BSD sockets. Also, threads are used to access hard disks in
L[n1 + 1] ← ∞ parallel to increase the performance. The proposed work was
R[n2 + 1] ← ∞ tested twice on different real datasets. the first was on Land
i←1 Registry Price Paid Data have been used [22], where some
j←1 tables size is larger than 10 GB.
for k ← s to e do According to this data set, there was no statistics on
if L[i] ≤ R[j] then the database operations and storage devices, it considers the
A[k] ← L[i] primary key as the most accessed attribute. The data has been
i←i+1 imported to the DBMS simulation, then it has been sorted
else out using merge sort and it has been fragmented, then each
A[k] ← R[j] fragment has been distributed to storage devices to balance
j ←j+1 I/O load among them. Then, some transactions on the proposed
Algorithm 3: Merge(X, s, m, e) function DBMS have been executed and the results are recorded to com-
pare them with other DBMSs like Oracle, which uses Auto-
matic Storage Management system, PostgreSQL and MySQL,
which have used RAID of 0 to increase performance. Whether
tenant’s accessed blocks are not balanced distributed to storage a transaction needs to access data from different fragments,
devices, the system Analyzes this information. It calculates the the transaction owner thread needs to get a list of conflict
variance for accessed blocks distribution by this tenant. If the transactions and their time table.
value is higher than the specified threshold which is determined The second experiment was executed on Health Insurance
by the administrators, it calculates the data reconfiguration Data with its statistics about applications’ queries accessing it
on storage devices. Consequentially, the storage management have been used [23], some tables size is larger than 5 GB.
module places database objects using the merge sort algorithm
for resorting and locating the data on storage devices, the B. Results and Discussion
complexity is O(n log(n)).
1) Results for first trial: In the first experiment in first
experiment, the ’write’ operation has been evaluated on the
Algorithms notation proposed DBMS with the storage module, with RAID 0
w Highest frequently accessed column index algorithm and finally with Oracle ASM, see Figure 2. The
u Second frequently accessed column index consumed time for writing database segment in these storage
v Third frequently accessed column index
Rs Size of relation management solutions is very close as these storage manage-
Fs Size of fragment ment systems partition the database segment into fixed size
n(hd) Number of hard drives
Ai Attribute i
blocks and distribute them to the hard drives. The proposed
f (Ai ) Frequency of attribute i storage module determines the best block size according to
Pa , P b , P c Predicates of attribute a, b, c hard drive properties which neither cause bottle-neck nor large
F Set of fragments
fi A fragment in the fragment set based on Pa predicates number of I/O ps. Thus, it consumes time lower than in RAID
fij A fragment in the fragment set based on Pa ,Pb predicates 0 and Oracle ASM. In Oracle ASM, the more the number of
fijm A fragment in the fragment set based on Pa ,Pb , Pc predicates tenants and database schemas increases, the lower the number


of hard drives assigned to database schema as they cannot be
shared with different schemes.

Fig. 4. Time for parallel read operation from three fragments

Fig. 2. Time consumption for writing database segment according to its criteria so it takes too long time for importing
the data.
In the second experiment, the ’selection of records’ oper-
ation has been evaluated for a different number of accessed
records distributed among different storage management algo-
rithms. The results of this experiment is shown in Figure 3.
All these records are in a single fragment and the transactions
are serial. The proposed storage algorithm consumes lower
time for executing large transactions and balanced storage
utilization although all storage algorithms sort out the data
and distribute it on the same attribute. In the proposed al-
gorithm, the fragment size is determined carefully and data
is fragmented with new horizontal fragmentation algorithm Fig. 5. Time consumption for writing database segment
that guarantees balance among storage devices during the
’read’ operations. The consumed time does not depend on
In the second experiment, the ’retrieval of records’ oper-
the proposed storage algorithm and other evaluated DBMSs
ation has been evaluated for a different number of accessed
algorithms for accessing data records only, but it also depends
records on the proposed DBMS with the storage module,
on the testing machine buses bandwidth especially monitor bus
MySQL and finally with Oracle ASM. The results of this
which makes a great bottle-neck. Also, using virtual SAN does
experiment is shown in Figure 6. The proposed storage algo-
not achieve the same efficiency as real SAN.
rithm consumes lower time for executing large transactions as
data is distributed between storage drives although all storage
algorithms sort out the data and distribute it on the same
attribute. Oracle with ASM consumes more time than MySQL
as in the insert data operation MySQL has sorted the data for
speed read access and decreasing bottle-neck for large queries.

Fig. 3. Time for read operation from a fragment

In the third experiment, the selection operation has been

evaluated. However, this time the accessed records are not in
the same fragment and the transactions are parallel 4 shows the
results of this experiment. According to the proposed storage
algorithm the result was better than in a single fragment as ’all
records lock’ manager are on different threads and validation
achieves in parallel. In RAID 0 and Oracle ASM algorithm,
there is no change happening as there is no fragmentation.
2) Results for second trial: In the first experiment, the
’import’ operation has been evaluated on the proposed DBMS
with the storage module, MySQL and finally with Oracle
ASM, see Figure 5. The consumed time for writing database
segment in these storage management solutions is higher than
Oracle as it partitions the data into fragments and inserts each
record into its fragment. Oracle writes the data physically on
storage drives as it is inserted. MySQL also physically sort data
Fig. 6. Time for retrieval operations with no predicates
In the third experiment, the selection operation with pred-
icates on three most frequently accessed columns has been
evaluated. Figure 7 shows the results of this experiment. The
proposed DBMS determines the accessed fragments and the
start and end position for each one, then it directly access its
data. Oracle reads the indexes for columns in the predicates and
determine the required records then it catches them resulting
in many seek operations are executed. MySQL uses the same
algorithm as Oracle, but it physically sort the data so the seek
operations number is lower than Oracle and the consumed time


is lower than RAID 0 and Oracle ASM algorithm, whereas
there is no change happening as there is no fragmentation.
Fig. 7. Time for Select records with predicates on three columns
In the fourth experiment, the selection operation with pred-
icates on most frequently accessed column has been evaluated.
Figure 8 shows the results of this experiment. The proposed
DBMS determines the accessed fragments and the start and end
position for each one. It takes lower time than time consumed
in determining fragments for predicates on three columns.
It gets the results rapidly than MySQL and Oracle as the
selected records is physically sorted and no seek operations
are executed. In MySQL this column was not indexed, so
select operations with predicates on it consume longer time
than time consumed on three columns and select with no
predicates. In Oracle, the consumed time for selecting the same
number of records was higher than selecting with no predicates
and selecting records with predicates on three columns as this
column was not indexed.
Fig. 8. Time for select operations with predicates on most frequently column
In the fifth experiment, the update operation with no
predicates has been evaluated. Figure 9 shows the results of
this experiment. The consumed time for update operation in
the proposed DBMS is lower than in Oracle ASM and MySQL
as it manages the storage better than them and no bottle-neck
occurs.
VI. C ONCLUSIONS AND F UTURE W ORK
This paper has proposed a DBMS architecture for cloud
data centers with new storage management, monitoring mod-
ule, and concurrency control algorithm. This work has in-
creased throughput for transactions and decreases transactions
abort rate. The results show that the proposed storage man-
agement module consumes lower time than other storage man-
agement systems, like RAID and Oracle ASM, for managing
the ’write and read’ operations. When the applications access
database on different columns with different frequencies, the
proposed algorithm processes the transactions better than other

Fig. 9. Time for update operation with no predicates
storage management systems, as it parallelizes the ’read’
operation among storage devices, depending on applications.
Reading data on different fragments is less response time than
on single fragment, as many servers handle the transaction
parallel.
In the future, a heuristic model will be built for fragmenting
the data, depending on expected statistics for accessing the
database, using the applications information and database
objects storage properties. The heuristic model is expected to
decrease the storage reconfiguration frequency ratio.
R EFERENCES
[1] P. Mell and T. Grance, “The NIST definition of Cloud
computing,” 2011.
[2] M. V. Srimathi, M. N. Sathyabhama, and M. D.
Hemalatha, “A Survey on Cloud Database Management,”
International Journal of Engineering and Computer Sci-
ence, vol. 2, no. 1, pp. 229–233, January 2013.
[3] D. J. Abadi, “Data management in the Cloud: limitations
and opportunities,” IEEE Data Eng. Bull., vol. 32, no. 1,
pp. 3–12, 2009.
[4] S. Das, D. Agrawal, and A. El Abbadi, “G-store: a
scalable data store for transactional multi-key access in
the Cloud,” in Proceedings of the 1st ACM symposium
on Cloud computing. ACM, 2010, pp. 163–174.
[5] J. Baker, C. Bond, J. C. Corbett, J. Furman, A. Khorlin,
J. Larson, J.-M. Leon, Y. Li, A. Lloyd, and V. Yushprakh,
“Megastore: Providing scalable, highly available storage
for interactive services,” in 5th Biennial Conference on
Innovative Data Systems Research (CIDR 11), Asilomar,
California, USA, 2011, pp. 223–234.
[6] F. Chang, J. Dean, S. Ghemawat, W. C. Hsieh, D. A. Wal-
lach, M. Burrows, T. Chandra, A. Fikes, and R. E. Gruber,
“Bigtable: A distributed storage system for structured
data,” ACM Transactions on Computer Systems (TOCS),
vol. 26, no. 2, p. 4, 2008.
[7] S. Das, A. El Abbadi, and D. Agrawal, “ElasTraS: An
Elastic Transactional Data Store in the Cloud,” HotCloud,
vol. 9, pp. 131–142, 2009.
[8] C. Curino, E. P. Jones, R. A. Popa, N. Malviya, E. Wu,
S. Madden, H. Balakrishnan, and N. Zeldovich, “Rela-
tional cloud: A database-as-a-service for the Cloud,” pp.
235–240, 2011.
[9] O. Corporation, “Delivering Database as a Service
(DBaaS) using Oracle Enterprise Manager 12c,” White
paper, October 2013.
[10] W. Cao, F. Yu, and J. Xie, “Realization of the low
cost and high performance MySQL Cloud database,”
 Proceedings of the VLDB Endowment, vol. 7, no. 13,
pp. 1742–1747, 2014.
[11] P. A. Bernstein, I. Cseri, N. Dani, N. Ellis, A. Kalhan,
G. Kakivaya, D. B. Lomet, R. Manne, L. Novik, and
T. Talius, “Adapting Microsoft SQL server for Cloud
computing,” in 2011 IEEE 27th International Conference
on Data Engineering. IEEE, 2011, pp. 1255–1263.
[12] A. Pavlo, C. Curino, and S. Zdonik, “Skew-aware au-
tomatic database partitioning in shared-nothing, parallel
OLTP systems.” ACM, 2012, pp. 61–72.
[13] M. Serafini, E. Mansour, A. Aboulnaga, K. Salem,
T. Rafiq, and U. F. Minhas, “Accordion: elastic scalability
for database systems supporting distributed transactions,”
Proceedings of the VLDB Endowment, vol. 7, no. 12, pp.
1035–1046, 2014.
[14] J. Shute, R. Vingralek, B. Samwel, B. Handy, C. Whip-
key, E. Rollins, M. Oancea, K. Littlefield, D. Menestrina,
S. Ellner et al., “F1: A distributed SQL database that
scales,” Proceedings of the VLDB Endowment, vol. 6,
no. 11, pp. 1068–1079, 2013.
[15] R. Liu, A. Aboulnaga, and K. Salem, “Dax: a widely dis-
tributed multitenant storage service for DBMS hosting,”
in Proceedings of the VLDB Endowment, vol. 6, no. 4.
VLDB Endowment, 2013, pp. 253–264.
[16] O. Corporation, “A Technical Overview of New Features

for Automatic Storage Management in Oracle Database
12c,” White paper, January 2013.
[17] K. Dutta and R. Rangaswami, “STORM: An Approach
to Database Storage Management in Data Center En-
vironments,” Florida International University, Technical
Report, TR-2006-09-02, 2006.
[18] S. Das, S. Nishimura, D. Agrawal, and A. El Abbadi, “Al-
batross: lightweight elasticity in shared storage databases
for the Cloud using live data migration,” Proceedings of
the VLDB Endowment, vol. 4, no. 8, pp. 494–505, 2011.
[19] D. Jacobs, S. Aulbach et al., “Ruminations on Multi-
Tenant Databases,” in BTW, vol. 103, 2007, pp. 514–521.
[20] A. J. Elmore, S. Das, D. Agrawal, and A. El Abbadi,
“Towards an elastic and autonomic multitenant database,”
in Proc. of NetDB Workshop. sn, 2011.
[21] I. VMware, “Configuration Maximums: vSphere 6.0,”
https://www.vmware.com/pdf/vsphere6/r60/vsphere-60-
configuration-maximums.pdf, 2016, [Online; accessed
25-February-2016].
[22] L. Registry, “Land Registry Price Paid Data,”
https://data.gov.uk/dataset/land-registry-monthly-price-
paid-data, 2012, [Online; accessed 10-March-2016].
[23] A. GOV, “Health Insurance Data,”
https://www.healthdata.gov/search/fieldt opic/health −
17816, 2014, [Online; accessed12 − January − 2017].