Thèse de doctorat: Algorithmes de classification répartis sur le cloud
Thèse de doctorat: Algorithmes de classification répartis sur le cloud
Thèse de doctorat: Algorithmes de classification répartis sur le cloud
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
tel-00744768, version 1 - 23 Oct 2012<br />
32 CHAPTER 2. PRESENTATION OF CLOUD COMPUTING<br />
Availability, Consistency, and Partition To<strong>le</strong>rance.<br />
More specifically, this theorem is a theoretical translation of the well-known<br />
practical chal<strong>le</strong>nges of applying ACID transactions on data split on multip<strong>le</strong><br />
machines. The ACID constraints require a lot of inter-machines communications<br />
to comp<strong>le</strong>te a sing<strong>le</strong> transaction (see for examp<strong>le</strong> [100]) and <strong>le</strong>ad to serious lock<br />
contentions that <strong>de</strong>eply <strong>de</strong>crease the transactional throughput.<br />
Moreover, guaranteeing that the data stored in cheap and unreliab<strong>le</strong> hardware are<br />
highly availab<strong>le</strong> implies multip<strong>le</strong> replications of each sing<strong>le</strong> piece of data. Since<br />
data servers are expected to fail from time to time, the data are duplicated several<br />
times (Azure storage is reported to hold for each data 6 replicas: 3 replicas in a<br />
first data center and 3 others in a backup data center ([36])), so that a data server<br />
can die without any data loss. To guarantee strong consistency whi<strong>le</strong> keeping<br />
multip<strong>le</strong> versions of any data pieces in different locations causes large overheads,<br />
as reported in [19].<br />
Scaling traditional ACID-compliant relational databases to distributed sharednothing<br />
architectures with cheap machines therefore turned out to be very difficult.<br />
Data storage systems <strong>de</strong>veloped in the 2000s known as NoSQL storage (for Not<br />
Only SQL) such as Cassandra, HBase, BigTab<strong>le</strong>, Simp<strong>le</strong>DB, etc. therefore<br />
dropped some of the ACID guarantees to achieve better scaling and lower latency.<br />
As stated by Daniel Abadi and A<strong>le</strong>xan<strong>de</strong>r Thomson in their blog, “NoSQL really<br />
means NoACID” (see [15]).<br />
Some of these systems (like BigTab<strong>le</strong> or Azure BlobStorage) <strong>de</strong>ci<strong>de</strong>d to provi<strong>de</strong><br />
weakened atomicity and isolation guarantees for transactions. In<strong>de</strong>ed, transactions<br />
that modify more than one piece of data are not guaranteed to be either all<br />
done or none. Therefore, no logical transaction implying several pieces of data<br />
can be guaranteed to be atomic at the storage <strong>le</strong>vel. It is up to the storage user to<br />
en<strong>sur</strong>e logical transactionality, and that user-specified invariants are not modified.<br />
Other <strong>cloud</strong> storage systems like Cassandra have been dropping strong consistency<br />
between replicas to provi<strong>de</strong> only a weakened consistency guarantee cal<strong>le</strong>d<br />
eventual consistency. We refer the rea<strong>de</strong>r to [108] for an introduction to eventual<br />
consistency, whi<strong>le</strong> an introduction to BASE (Basically Availab<strong>le</strong>, Soft state,<br />
Eventually consistent) can be found in [99]. Whi<strong>le</strong> the eventual consistency is<br />
satisfactory enough for a given number of well-known web applications such as<br />
Facebook, the loss of strong consistency is a very difficult issue for many other<br />
real world applications, which makes application <strong>de</strong>velopment much har<strong>de</strong>r. This<br />
is a key aspect of No-SQL storage: the responsibilities are partly shifted and the
Change language