Databases Reference
In-Depth Information
Proposal A uses Java programs that call a
SQL
database and generate the appropriate
HTML
and bitmapped images for the tables and charts of each dashboard every time a
widget is viewed. In this scenario, two views of the same data, a bar chart in one view
and an
HTML
table in another view, will rerun the exact same
SQL
code on the data
warehouse. There's no caching layer.
Proposal B has a functional programming
REST
layer system that first generates an
XML
response from the
SQL
SELECT
for each user interface widget and then caches
this data. It then transforms the data in the cache into multiple views such as tables
and charts. The system looks at the last-modified dates in the database to know if any
of the data in the cache should be regenerated.
Proposal B also has tools that prepopulate the cache with frequent reports after
the data in the warehouse changes. The system is 25% more expensive, but the vendor
claims that their solution will be less expensive to operate due to lower demand on the
database server. The vendor behind proposal B claims the average dashboard widget
generates a view in under 50 milliseconds if the data is in cache. The vendor also
claims that if Sally uses
SVG
vector charts, not the larger bitmapped images, then the
cached
SVG
charts will only occupy less than 30
KB
in cache, and less than 3
KB
if
they're compressed.
Sally looks at both proposals and selects proposal B, despite its higher initial cost.
She also makes sure the application servers are upgraded from 16
GB
to 32
GB
of
RAM
to provide more memory for the caches. According to her calculations, this should be
enough to store around 10 million compressed
SVG
charts in the
RAM
cache. Sally
also runs a script on Sunday night that prepopulates the cache with the most common
reports, so that when users come in on Monday morning, the most frequent reports
are already available from the cache. There's almost no load on the database server
after the reports are in the cache. When the project rolls out, the average page load
times, even with 10 charts per page, are well under 3 seconds. Susan is happy and gives
Sally a bonus at the end of the year.
You should notice that in this example, the additional
REST
caching layer in a soft-
ware application isn't dependent on your using a NoSQL database. Since most
NoSQL databases provide
REST
interfaces that provide cache-friendly results, they
provide additional ways your applications can use a cache to lower the number of calls
to your database.
10.7
Summary
In this chapter, you've learned about functional programming and how it's different
from imperative programming. You learned how functional programming is the pre-
ferred method for distributing isolated transformations of data over distributed sys-
tems, and how systems are more scalable and reliable when functional programming
is used.
Understanding the power of functional programming will help you in several ways.
It'll help you understand that state management systems are difficult to scale and that
