Databases Reference
In-Depth Information
WHY ONLY MONGODB AND APACHE CASSANDRA?
The choice of MongoDB and Cassandra to illustrate NoSQL examples is quite
arbitrary. This chapter intends to provide a fi rst fl avor of the deep and wide NoSQL
domain. There are numerous NoSQL products and many offer compelling features
and advantages. Choosing a couple of products to start with NoSQL was not easy.
For example, Couchbase server could have been chosen over MongoDB and HBase
could have been used instead of Cassandra. The examples could have been based
on products like Redis, Membase, Hypertable, or Riak. Many NoSQL databases
are covered in this topic, so read through and you will learn a lot about the various
alternative options in the NoSQL space.
FIRST IMPRESSIONS — EXAMINING TWO SIMPLE EXAMPLES
Without further delay or long prologues, it's time to dive right into your fi rst two simple examples.
The fi rst example creates a trivial location preferences store and the second one manages a car make
and model database. Both the examples focus on the data management aspects that are pertinent in
the context of NoSQL.
A Simple Set of Persistent Preferences Data
Location-based services are gaining prominence as local businesses are trying to connect with users
who are in the neighborhood and large companies are trying to customize their online experience
and offerings based on where people are stationed. A few common occurrences of location-based
preferences are visible in popular applications like Google Maps, which allows local search, and
online retailers like Walmart.com that provide product availability and promotion information
based on your closest Walmart store location.
Sometimes a user is asked to input location data and other times user location is inferred. Inference
may be based on a user's IP address, network access point (especially if a user accesses data from a
mobile device), or any combination of these techniques. Irrespective of how the data is gathered, you
will need to store it effectively and that is where the example starts.
To make things simple, the location preferences are maintained for users only in the United States
so only a user identifi er and a zip code are required to fi nd the location for a user. Let's start with
usernames as their identifi ers. Data points like “John Doe, 10001,” “Lee Chang, 94129,” “Jenny
Gonzalez 33101,” and “Srinivas Shastri, 02101” will need to be maintained.
To store such data in a fl exible and extendible way, this example uses a non-relational database
product named MongoDB. In the next few steps you create a MongoDB database and store a few
sample location data points.
