Databases Reference
In-Depth Information
from a single flat file. Over time, they need to do more and evolve into systems that
manage multiple tables, perform join operations, do query optimization, replicate
transactions, run stored procedures, set triggers, enforce security, and perform index-
ing. NoSQL systems use a different approach to solving these complex problems by
creating simple applications that distribute the required features across the network.
Keeping your architectural components simple allows you to reuse them between
applications, aids developers in understanding and testing, and makes it easier to port
your application to new architectures.
From the NoSQL perspective, simple is good. When you create an application, it's
not necessary to include all functions in a single software application. Application
functions can be distributed to many NoSQL (and
SQL
) databases that consist of sim-
ple tools that have simple interfaces and well-defined roles. NoSQL products that fol-
low this rule do a few things and they do them well. To illustrate, we'll look at how
systems can be built using well-defined functions and focus on how easy it is to build
these new functions.
If you're familiar with
UNIX
operating systems, you might be familiar with the con-
cept of UNIX pipes.
UNIX
pipes are a set of processes that are chained together so
that the output of one process becomes the input to the next process. Like
UNIX
pipes, NoSQL systems are often created by integrating a large number of modular
functions that work together. An example of creating small functions with
UNIX
pipes
to count the total number of figures in a topic is illustrated in figure 2.1.
What's striking about this example is that by typing about 40 characters you've cre-
ated a useful function. This task would be much more difficult to do on systems that
don't support
UNIX
-style functions. In reality, only a query on a native
XML
database
might be shorter than this command, but it wouldn't also be general-purpose.
Many NoSQL systems are created using a similar philosophy of modular compo-
nents that can work together. Instead of having a single large database layer, they often
From the input extract only
the lines that have '<figure'
and send them on to
the output.
Concatenate all files that
start with “ch” and end with
“.xml” and send them
to the standard out.
From the input use
“word count” and
return the number
of lines.
Pipe
Pipe
$ cat ch*.xml | grep '<figure' | wc -l
145
The result is the number of figures in all chapters.
Figure 2.1
UNIX pipes as an example of reusing simple tools to create new functions.
This figure concatenates (puts together) all chapter files in a topic into a single file and
counts the number of figures in all chapters. With UNIX pipes, we do this by stringing
together three simple commands: concatenate (
cat
), a search function called
grep
,
and word count (
wc
). No additional code is needed; each function takes the output from
the previous function and processes it.
