Databases Reference
In-Depth Information
Application 1
Application 2
Application 3
Data store
1
Data store
2
Data store
3
Scenario 1
Scenario 2
Scenario 3
Fig. 1. The three possible scenarios
However, a single application can use only one data store to store all its data.
So in some cases, an application may want to migrate its data from one data
store (i.g. a relational DBMS) to another (i.g. a NoSQL DBMS). The problem
here is to decide if a data store is convenient for an application and if not how to
eciently migrate data from one DBMS to another. Added to the requirement
R 0 , we identify two new data requirements:
- R 1 : Choosing a data store based on data requirements. In this context, we
present three sub-requirements: ( R 11 ) defining application needs and require-
ments towards data, ( R 12 ) defining data store capabilities, and ( R 13 ) defining
a matching between application needs and data stores capabilities.
- R 2 : Migrating application from a data store to another (i.e. migrating data
and adapting the application source code to a new API).
In the third scenario S 3 an application can use multiple data stores. For instance,
an application can use a relational data store and a NoSQL data store at the
same time or partition its data into multiple data stores. This scenario is illus-
trated by the dotted lines in Fig.1. Moreover, these data stores may belong to
different clouds (e.g. a public cloud and a private one). This ensures a high level
of eciency and modularity. This case corresponds to what is popularly referred
to as the polyglot persistence. Nevertheless, this scenario represents some limits
and diculties. Linking an application with multiple data stores is very complex
due to the different APIs, data models, query languages or consistency models.
If the application needs to query data coming from different data sources (e.g
joining data, aggregating data, etc.), it can not do it declaratively unless some
kinds of mediation have been done before. Finally, the different data stores may
use different transaction and consistency models (for example classical ACID
and eventual consistency). It is not easy for programmers to understand these
 
Search WWH ::




Custom Search