Section: New Results

Hosted database replication service

Participant : Mesaac Makpangou [ correspondent ] .

Today, the vast majority of content distributed on the web are produced by web 2.0 applications. Examples of such applications include social networks, virtual universities, multi-players games, e-commerce web sites, and search engines. These applications rely on databases to serve end-users' requests. Hence, the success of these applications/services depends mainly on the scalability and the performance of the database backend.

The objective of our research is to provide a hosted database replication service [45] . With respect to end-users applications, this service offers an interface to create, to register, and to access databases. Internally, each hosted database is fragmented and its fragments are replicated towards a peer-to-peer network. We anticipate that such a service may improve the performance and the availability of popular web applications, thanks to partial replications of backend databases. Partial database replication on top of a peer-to-peer network raises a number of difficult issues: (i) enforcing replica consistency in presence of update transactions, without jeapordizing the scalability and the performance of the system? (ii) accommodating the dynamic and the heterogenity of a peer-to-peer network with the database requirements?

In 2009, we focus on the partial database replication protocol. We proposed a database access protocol, capable to spread out a transaction's accesses over multiple database fragments replicas while guarenteeing that each transaction observes a consistent distributed snapshot of a partially replicated database. We have also proposed a replica control substrate that permits to enforce 1-Copy SI for database fragments replicated over a wide area network. For that, unlike most database replication, we separate the synchronistation from the certification concerns.

A small-scale group of schedulers that do not hold database replicas, cooperate with one antoher to certify update transactions. Only certified transactions are notified to replicas. Futhermore, each replica will be notified only the transactions that impact the that it stores. Thanks to this separation, we avoid waste of computaion resource at replicas that will be used to decide whether to abord or commit an update transaction; Our design choices also permit to reduce bandwidth consumption.