Single v.
multiple data store solutions
This paper is published under the terms and conditions in the
footnote.
This paper outlines ways that data
representing a system’s state may be replicated in multiple data stores.
Contents
Different
tiers of one client-server application
Differently
structured update (OLTP) and reporting (OLAP) data stores
Data
copies in the data storage tier of one client-server application.
Different
databases at the bottom of different client-server applications
A logical
data model is a model that describes the data that must persist for the
processes of a business system to work.
It is a
kind of “domain model” that defines business terms and concepts.
It is a
data structure that shows entities and events of importance to a business.
It is
easy and natural to build a relational database to hold the data defined in a
logical data model.
Many
enterprise applications have been built on top of a single relational database.
It is the
default data architecture for an enterprise application, and should always be
considered.
Query
performance can be improved (sometimes dramatically) by enabled by adding
indexes and derived data.
You need
good reasons to store data in a different way – instead or as well.
And those
reasons are usually non-functional requirements rather than functional ones.
A goal of enterprise architecture is to reduce if not
eliminate issues arising because different people see different versions of the
same data.
Ideally, every data item important to a business would be
stored in one place, or if replicated, then it would have the same value in all
locations.
However,
the days of the enterprise maintaining a single database appear to be behind
us.
You need good
reasons to replicate data in several data stores.
And those
reasons are usually non-functional requirements rather than functional ones.
Data can
be replicated in several data stores in various ways.
This
replication creates work for enterprise and solution architects, who must
attend to how the data is coordinated.
Usually,
in a modern client-server system, data entry fields are checked on the client
device.
And to
ensure availability, the top-most tier on the server-side is scaled out.
Top-level
server-side components are typically stateless or maintain only
soft state (cached data).
And
they must continue to work, even if lower-level components and data sources are
temporarily inaccessible.
In short, the
higher-level components in a client-server system may sacrifice consistency of
data and responses for the sake of a faster response, and availability.
It can be
difficult to get management information out of a database that is continually
updated by on-line transactions.
The
non-functional requirements can drive you to separate data stores for
processing of update transactions and reporting.
And they
might drive you to using “event sourcing”.
Sometimes,
there is a very large and/or widely distributed population of clients for the
same data.
To ensure
the availability of data to all clients, that data may have to be may be copied
to many nodes.
The nodes
may be arranged in a cluster in one location; where nodes can be synchronised
with each other in microseconds.
Or else,
the nodes may be widely distributed to support dispersed user populations, and
synchronised over a longer timescale.
There are
very often accidental overlaps between data stores used by different business
functions
Most
substantial enterprises have a long history of application development and
package purchases.
An
outcome of this history is a messy data architecture; the same and related data
is maintained in several applications, some in-house, some in the cloud.
Enterprise architects assume
distributed applications, if they maintain the same or related data, should be
coordinated.
Synchronisation
of data in different database can be addressed by a variety of “master data
management” patterns and techniques.
Footnote: Creative Commons Attribution-No Derivative Works Licence 2.0 20/04/2015 17:16
Attribution: You may copy, distribute and display this copyrighted work
only if you clearly credit “Avancier Limited: http://avancier.website” before
the start and include this footnote at the end.
No Derivative Works: You may copy, distribute, display only complete and verbatim
copies of this page, not derivative works based upon it.
For more information about the
licence, see http://creativecommons.org