Databases Reference
In-Depth Information
When application designers begin to think about soft-
ware systems that store persistent data, they have many
options. One choice is to determine whether they need to
use application tiers to divide the overall functionality of
their application. Identifying each layer breaks the applica-
tion into separate architectural components, which allows
the software designer to determine the responsibility of
each component. This separation of concerns allows designers
to make the complicated seem simple when explaining the
system to others.
Application tiers are typically viewed in a layer-cake-like
drawing, as shown in figure 2.2. In this figure, user events
(like a user clicking a button on a web page) trigger code in
the user interface. The output or response from the user
interface is sent to the middle tier. This middle tier may
respond by sending something back to the user interface,
or it could access the database layer. The database layer may
in turn run a query and send a response back to the middle
tier. The middle tier then uses the data to create a report
and sends it to the user. This process is the same whether you're using Microsoft Win-
dows, Apple's OS X , or a web browser with HTML links.
When designing applications it's important to consider the trade-offs when putting
functionality in each tier. Because relational databases have been around for a long
time and are mature, it's common for database vendors to add functionality at the
database tier and release it with their software rather than reusing components
already delivered or developed. NoSQL system designers know that their software
must work in complex environments with other applications where reuse and seam-
less interfaces are required, so they build small independent functions. Figure 2.3
shows the differences between RDBMS and NoSQL applications.
In figure 2.3 we compare the relational versus NoSQL methods of distributing appli-
cation functions between the middle and database tiers. As you can see, both models
have a user interface tier at the top. In the relational database, most of the application
functionality is found in the database layer. In the NoSQL application, most of the
application functionality is found in the middle tier. In addition, NoSQL systems lever-
age more services for managing BLOB s of data (the key-value store), for storing full-text
indexes (the Lucene indexes), and for executing batch jobs (MapReduce).
A good NoSQL application design comes from carefully considering the pros and
cons of putting functions in the middle versus the database tier. NoSQL solutions
allow you to carefully consider all the options, and if the requirements include a high-
scalability component, you can choose to keep the database tier simple. In traditional
relational database systems, the complexity found in the database tier impacts the
overall scalability of the application.
Event triggers
Response
User interface
Middle tier
Database layer
Figure 2.2 Application
tiers are used to simplify
system design. The NoSQL
movement is concerned
with minimizing
bottlenecks in overall
system performance, and
this sometimes means
moving key components
out of one tier and putting
them into another tier.
Search WWH ::




Custom Search