Databases Reference
In-Depth Information
GIS
systems store items once and then provide multiple access paths (queries) to
let you view the data. They're designed to cluster similar row
ID
s together and result in
rapid retrieval of all images/points that are near each other on the map.
4.3.6
Case study: using a column family to store user preferences
Many websites allow users to store preference information as part of their profile. This
account-specific information can store privacy settings, contact information, and how
they want to be notified about key events. Typically the size of this user preference
page for a social networking site is under 100 fields or about 1
KB
in size, which is rea-
sonable as long as there's not a photo associated with it.
There are some things about user preference files that make them unique. They
have minimal transactional requirements, and only the individual associated with the
account makes changes. As a result, ensuring an
ACID
transaction isn't as important as
making sure the transaction occurs when a user attempts to save or update their pref-
erence information.
Other factors to consider are the number of user preferences you have and system
reliability. It's important that these read-mostly events are fast and scalable so that
when a user logs in, you can access the preferences and customize their screen regard-
less of the number of concurrent system users.
Column family systems can provide the ideal match for storing user preferences
when combined with an external reporting system. These reporting systems can be set
up to provide high availability through redundancy, and yet still allow reporting to be
done on the user preference data. In addition, as the number of users increases, the
size of the database can expand by the addition of new nodes to your system without
changing the architecture. If you have large datasets, big data stores may provide an
ideal way to create reliable yet scalable data services.
Column family systems are known for their ability to scale to large datasets but
they're not alone in this regard; document stores with their general and flexible
nature are also a good pattern to consider when scalability is a requirement.
4.4
Document stores
Our coverage of NoSQL data patterns wouldn't be complete without talking about the
most general, flexible, powerful, and popular area of the NoSQL movement: the doc-
ument store. After reading this section, you'll have a clear idea of what document
stores are and how they're used to solve typical business problems. We'll also look at
some case studies where document stores have been successfully implemented.
As you may recall, key-value and Bigtable stores, when presented with a key, return
the value (a
BLOB
of data) associated with that key. The key-value store and Bigtable
values lack a formal structure and aren't indexed or searchable. Document stores
work in the opposite manner: the key may be a simple
ID
which is never used or seen.
But you can get almost any item out of a document store by querying any value or con-
tent within the document. For example, if you queried 500 documents associated with
