![](https://csdnimg.cn/release/download_crawler_static/10625998/bg10.jpg)
But reality is not that simple. There are many database systems with different charac‐
teristics, because different applications have different requirements. There are vari‐
ous approaches to caching, several ways of building search indexes, and so on. When
building an application, we still need to figure out which tools and which approaches
are the most appropriate for the task at hand. And it can be hard to combine tools
when you need to do something that a single tool cannot do alone.
This book is a journey through both the principles and the practicalities of data sys‐
tems, and how you can use them to build data-intensive applications. We will explore
what different tools have in common, what distinguishes them, and how they achieve
their characteristics.
In this chapter, we will start by exploring the fundamentals of what we are trying to
achieve: reliable, scalable, and maintainable data systems. We’ll clarify what those
things mean, outline some ways of thinking about them, and go over the basics that
we will need for later chapters. In the following chapters we will continue layer by
layer, looking at different design decisions that need to be considered when working
on a data-intensive application.
Thinking About Data Systems
We typically think of databases, queues, caches, etc. as being very different categories
of tools. Although a database and a message queue have some superficial similarity—
both store data for some time—they have very different access patterns, which means
different performance characteristics, and thus very different implementations.
So why should we lump them all together under an umbrella term like data systems?
Many new tools for data storage and processing have emerged in recent years. They
are optimized for a variety of different use cases, and they no longer neatly fit into
traditional categories [1]. For example, there are datastores that are also used as mes‐
sage queues (Redis), and there are message queues with database-like durability guar‐
antees (Apache Kafka). The boundaries between the categories are becoming blurred.
Secondly, increasingly many applications now have such demanding or wide-ranging
requirements that a single tool can no longer meet all of its data processing and stor‐
age needs. Instead, the work is broken down into tasks that can be performed effi‐
ciently on a single tool, and those different tools are stitched together using
application code.
For example, if you have an application-managed caching layer (using Memcached
or similar), or a full-text search server (such as Elasticsearch or Solr) separate from
your main database, it is normally the application code’s responsibility to keep those
caches and indexes in sync with the main database. Figure 1-1 gives a glimpse of what
this may look like (we will go into detail in later chapters).
4 | Chapter 1: Reliable, Scalable, and Maintainable Applications