The first question that you will have when you start your NoSQL journey is “How is data modeled in NoSQL?” The important thing to understand is the data does not change just because it is managed differently. If the data does not change, then the entities and the relationships contained in the data cannot change either. The entities and the relationships between them have not changed since the dawn of time. They were the same in the days of network database management systems which came before relational database management systems, they stayed the same when object-oriented database management systems came along, and they are the same now that we have NoSQL databases.

The key NoSQL concept is that of a functional segment. As I explained in The Rise and Fall of the NoSQL Empire, Amazon’s pivotal design decision was to break its monolithic enterprise-wide database service into simpler component services such as a best-seller list service, a shopping cart service, a customer preferences service, a sales rank service, and a product catalog service. This avoided a single point of failure. In an interview for the NoCOUG Journal, Amazon’s first database administrator, Jeremiah Wilton explains the rationale behind Amazon’s approach: “The best availability in the industry comes from application software that is predicated upon a surprising assumption: The databases upon which the software relies will inevitably fail. The better the software’s ability to continue operating in such a situation, the higher the overall service’s availability will be. But isn’t Oracle unbreakable? At the database level, regardless of the measures taken to improve availability, outages will occur from time to time. An outage may be from a required upgrade or a bug. Knowing this, if you engineer application software to handle this eventuality, then a database outage will have less or no impact on end users. In summary, there are many ways to improve a single database’s availability. But the highest availability comes from thoughtful engineering of the entire application architecture.” As an example, the shopping cart service should not be affected if the checkout service is unavailable or not performing well.

I said that this was the pivotal design decision made by Amazon. I cannot emphasize this enough. If you resist functional segmentation, you are not ready for NoSQL. If you miss the point, you will not understand NoSQL.

Note that functional segmentation results in simple hierarchical schemas. Here is an example of a simple hierarchical schema from Ted Codd’s 1970 paper on the relational model (meticulously reproduced in the 100th issue of the NoCOUG Journal). This schema stores information about employees, their children, their job histories, and their salary histories.

  • employee (man#, name, birthdate)
  • children (man#, childname, birthyear)
  • jobhistory (man#, jobdate, title)
  • salaryhistory (man#, jobdate, salarydate, salary)

In NoSQL-land, all the data about a single employee will be “blobbed” together; for example, as a “JSON” structure.

Functional segmentation is the underpinning of NoSQL technology but it does not present a conflict with the relational model; it is simply a physical database design decision. Amazon originally envisaged that functional segments would be managed by different servers. However, that was soon realized to be unnecessary. Nowadays, functional segments are variously referred to as “tables” (DynamoDB), “collections” (MongoDB), or “table families” (Oracle Database 12c Release 2 sharding).