100 | Big Data Simplied
Account balances are another such example. It is not ideal to update a customer’s account bal-
ance in one place and not in another, allowing the customer to then exceed the allowable balance.
On the other hand, think of something like the information in a product catalogue. If we add
a new product to the catalogue, do we really need to hold all of the servers locked for access until
they have all been updated or can we update the servers one at a time with the new product?
Well, that does mean that a customer in Los Angeles might actually see the information about
that product before a customer in New Jersey does, but is that really any worse than making the
entire catalogue unavailable to everyone until the customer in New Jersey has his own database
updated with new product information locally?
So, in that case, it is probably best to get things out as soon as possible, even if it gets staggered
geographically. We can dispense with consistency, but availability is quite important. Whereas, in
the earlier example of inventory, we might be able to sacrifice some amount of availability as long
as we can maintain consistency.
When some NoSQL databases save the data, they do not actually save the data to disc. That
data may only be saved in memory and those multiple saves may be aggregated and written to
the disc later on. Thus, it puts that data in a vulnerable position if there is an outage, because the
data has not been committed yet. While there are safeguards that can be taken to make sure that,
in the case of an outage, the data is recorded, but it is still different from a relational database that
makes sure that the updates are committed immediately.
5.3 NoSQL PRODUCT CATEGORIES
So far, we have witnessed the stance of NoSQL databases in a generic way. However, it is ne
because the concepts we have been discussing have been high-level and generic in nature as well.
In addition, it turns out that NoSQL databases can be classied into four major categories. At this
point, it makes sense for us to discuss about these four categories of NoSQL databases.
5.3.1 Key-value Stores
The most prominent type of NoSQL database is a key-value store.
Look at the example as shown in Figure 5.2. Here, we have a Customer table and an Order
table. Look at the Customer table. For a Row ID of 101, we have a few keys, such as First_Name,
Last_Name, Address and Last_Order_ID. Then, there is another row with ID of 102. In this
example, we have kept the structure of the rows constant, but you do not actually have to do
that. This underlies the point that the key-value stores are schema-free. You can have different
keys in each row. Now, we see that the Last_Order_ID for customer John Doe is 1701 and the
Last_Order_ID for customer Jane Doe is 1702. We have those two orders shown here in the
example as well. But, note that, there is no explicit relationship between the two tables. Just as
we mentioned earlier on, these tables exist rather independently and the way you need to con-
nect them is by creating your own program logic.
The key-value stores are the most common type of NoSQL database. As it turns out, the other
three types are often implemented using key-value stores as the underlying structure, by creating
a certain level of abstraction on top of what a key-value store does.
M05 Big Data Simplified XXXX 01.indd 100 5/20/2019 7:42:41 PM
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.