NoSQL books and blogs offer different opinions on what a NoSQL database is. Four core features of NoSQL, shown in the following list, apply to most NoSQL databases. The list compares NoSQL to traditional relational DBMS:
• Schema agnostic: A database schema is the description of all possible data and data structures in a relational database. With a NoSQL database, a schema isn't required, giving you the freedom to store information without doing up-front schema design.
• Nonrelational: Relations in a database establish connections between tables of data. For example, a list of transaction details can be connected to a separate list of delivery details. With a NoSQL database, this information is stored as an aggregate - a single record with everything about the transaction, including the delivery address.
• Commodity hardware: Some databases are designed to operate best (or only) with specialized storage and processing hardware. With a NoSQL database, cheap off-the-shelf servers can be used. Adding more of these cheap servers allows NoSQL databases to scale to handle more data.
• Highly distributable: Distributed databases can store and process a set of information on more than one device. With a NoSQL database, a cluster of servers can be used to hold a single large database.
Schema agnostic
NoSQL databases are schema agnostic. You aren't required to do a lot of up-front design work before you can store data in NoSQL databases. You can start coding and store and retrieve data without knowing how the database stores and works internally. (If and when you need advanced functionality, then you can manually add further indexes or tweak data storage structures.) Schema agnosticism may be the most significant difference between NoSQL and relational databases.
The great benefit to a schema agnostic database is that development time is shortened. This benefit increases as you go through multiple development releases and need to alter the internal data structures in the database.
For example, in a traditional RDBMS, you go through a process of schema redesign. The schema instructs the database on what data to expect. Change the data stored, or structures, and you must reinstruct the database using a modified schema. If you were to make a change, you'd have to spend a lot of time deciding how to re-architect the existing data. In NoSQL databases, you simply store a different data structure. There's no need to tell the database beforehand.
You may have to modify your queries accordingly, maybe add the occasional specific index (such as an integer range index to allow less than and greater than data-type specific queries), but the whole process is much less painful than it is with an RDBMS.
RDBMS took off because of its flexibility and because, by using SQL, it sped up changing a query. NoSQL databases provide this flexibility for changing both the schema and the query, which is one of the key reasons that they will be increasingly adopted over time.
TIP: Even on query, you may not need to worry too much about knowing the schema changes - consider an index over a field account number, where account number can be located anywhere in a document that is stored in a NoSQL database. You can change the structure and relocate where account number is stored, and if the element has the same name elsewhere in the document, it's still available for query without changes to your query mechanism.
Note that not all NoSQL databases are fully schema agnostic. Some, such as HBase, require you to stop the database to alter column definitions. They're still considered NoSQL databases because not all defined fields (columns in this case) are required to be known in advance for each record - just the column families.
RDBMS allows individual fields in records to be identified as null values. The problem with an RDBMS is that stored data size and performance are negatively affected when storage is reserved for null values just in case the record may at some future time have a value in that column. In Cassandra, you simply don't provide that column's data, which solves the problem.
Nonrelational
Relational database management systems have been the dominant way to store application data for more than 20 years. A great deal of mathematical work was done to prove the theory that underpins them.
This underpinning describes how tables relate to each other. A single Order row may relate to many Delivery Address rows, but each Delivery Address row also relates to multiple Order rows. This is a many-to-many relationship.
NoSQL databases don't have this concept of relationships between their records. They instead denormalize data. This means that in a NoSQL database would have an Order structure with the Delivery Address embedded. This means the delivery address is duplicated in every Order row that uses it. This approach has the advantage of not requiring complex query time joins across multiple data structures (tables) though.
NoSQL databases don't store information about how individual records relate to other records in the database, which may sound like a limitation. However, NoSQL databases are more flexible in terms of the data structures you can store.
Consider an order from an online retailer. The order could include product codes, quantities, item prices, and item descriptions, as well as information about the person ordering, such as delivery address and payment information.
Rather than insert ten rows in a variety of tables in a relational database, you can instead store a single structure for all of this order information - say, as a JSON or XML document.
In relational database theory, the goal is to normalize your data (that is, to organize the fields and tables to remove duplicate data). In NoSQL databases - especially Document or Aggregate databases - you often deliberately denormalize data, storing some data multiple times.
You can store, for example, “Customer Delivery Address” multiple times across many orders a customer makes over time, rather than store it once and refer to it in multiple orders. Doing so requires extra storage space, and a little forethought in managing in your application. So why do it?
There are two advantages to storing data multiple times:
• Easy storage and retrieval: Just save and get a single record.
• Query speed: In relational databases, you join information and add constraints across tables at query time. This may require the database engine to evaluate many tables. The more query constraints you have across different tables, the more you reduce your query speed. (This is why an RDBMS has precomputed views.) In a NoSQL database, all the information you need to evaluate your query is in a single document. Therefore, you can quickly determine the list of matching documents.
Relational views and NoSQL denormalizations are different approaches to the problem of data spread across records. In NoSQL, you may have to maintain multiple denormalizations representing different views of the same data. This approach increases the cost of storage but gives you much better query time.
TIP: Given the ever-reducing cost of storage and the increased speed of development and querying, denormalized data (aka materialized views) isn't a killer reason to discount NoSQL solutions. It's just a different way to approach the same problem, with its own advantages and disadvantages.
NoSQL is highly distributable and uses commodity hardware
In many NoSQL databases, a key design decision is to use multiple computers to store data for a single database, rather than have the whole database on a single server.
Storing data across multiple machines and allowing it to be queried is difficult. You must send the query to all the servers and wait for a reply. Hopefully, you set up the machines so that they're fast enough to talk to each other to handle distributed queries!
The main advantage of this approach is in the case of very large datasets, because for some storage requirements, even the largest available single server couldn't store or process all the data you need. Consider all the messages on Twitter and Facebook. You need a distributed mechanism to effectively manage all that data, even if it's mostly about what people had for breakfast and cute cat videos.
An advantage of distributing your database is that you can use cheaper servers, called commodity servers. Even for smaller datasets, it may be cheaper to buy three commodity servers instead of a single, higher-powered server.
Another key advantage is that adding high availability is easier; you're already halfway there by distributing your data. If you replicate your data once or twice across other servers in the cluster, your data will still be accessible, even if one of the servers crashes, burns, and dies.
WARNING: Not all open-source databases support high availability unless you buy the supported, paid-for version of the database from the company that develops it.
An exception to the highly distributable rule is that of graph databases. In order to effectively answer certain graph queries in a timely fashion, data needs to be stored on a single server. No one has solved this particular issue yet.
TIP: Carefully consider whether you need a triple store or a graph store. Triple stores are generally distributable, whereas graph stores aren't. Which one you need depends on the queries you must support.
About the Book Author
Adam Fowler is a principal sales engineer with MarkLogic, Inc. He has previously worked for IPK, FileNet, and IBM as well as smaller companies. Adam writes for and runs a popular blog on NoSQL and big data, which is republished on DZone.com. He's a frequent speaker at NoSQL conferences.
Get up to speed on the nuances of NoSQL databases and what they mean for your organization
This easy to read guide to NoSQL databases provides the type of no-nonsense overview and analysis that you need to learn, including what NoSQL is and which database is right for you. Featuring specific evaluation criteria for NoSQL databases, along with a look into the pros and cons of the most popular options, NoSQL For Dummies provides the fastest and easiest way to dive into the details of this incredible technology. You'll gain an understanding of how to use NoSQL databases for mission-critical enterprise architectures and projects, and real-world examples reinforce the primary points to create an action-oriented resource for IT pros.
If you're planning a big data project or platform, you probably already know you need to select a NoSQL database to complete your architecture. But with options flooding the market and updates and add-ons coming at a rapid pace, determining what you require now, and in the future, can be a tall task. This is where NoSQL For Dummies comes in!
• Learn the basic tenets of NoSQL databases and why they have come to the forefront as data has outpaced the capabilities of relational databases
• Discover major players among NoSQL databases, including Cassandra, MongoDB, MarkLogic, Neo4J, and others
• Get an in-depth look at the benefits and disadvantages of the wide variety of NoSQL database options
• Explore the needs of your organization as they relate to the capabilities of specific NoSQL databases
Big data and Hadoop get all the attention, but when it comes down to it, NoSQL databases are the engines that power many big data analytics initiatives. With NoSQL For Dummies, you'll go beyond relational databases to ramp up your enterprise's data architecture in no time.
