Browse Books

Reviewer: Michael O. Moorman

This book is about the world of databases and the challenge of NoSQL databases to the reigning relational database model. NoSQL is short for no structured query language, a language developed by IBM for retrieving data from relational databases. But the book is about nonrelational databases; NoSQL is simply a convenient, hip term for nonrelational databases. The authors state their purpose: "This book seeks to give you enough information to answer the question of whether NoSQL databases are worth serious consideration for your future projects." They provide a convincing argument for considering NoSQL databases for certain types of data-large volumes of data of multiple types that do not fit well into the relational database model. But in order to do that, they sacrifice some of the stability and concurrency of the relational database. The book is organized into two parts, with a total of 15 chapters. The first part is on understanding nonrelational databases, and the second part covers implementing nonrelational databases of different types. The seven chapters in Part 1 cover foundational material on nonrelational databases. In these chapters, the authors describe the emergence of nonrelational databases and how they operate without some of the capabilities of relational databases-for example, a schema composed of tables, records, and fields, where the fields for every record are the same size and kind of data (character, number, logical, and so on). As a result, one of the difficulties with relational databases is their inability to easily store different types of data for different entities in an established schema. For example, if you have a data record on an entity that does not include images, in order to store an image for just a small sample of the records, you would have to create an image field for every record in that data store; this could involve considerable effort and allocated storage space. Nonrelational databases can more easily provide this capability through the use of linked clusters of data where the clusters can contain many different kinds of items. There are, however, problems with this kind of structure. Unlike the relational model in which consistency is maintained through the use of transactions and locked records, the nonrelational model does not have the fixed structure that easily allows the transaction and locked record model to be implemented. The nonrelational model sacrifices some of its consistency in exchange for the more fluid model, which means that in some cases users will receive invalid data for a period of time. Much of this part of the text is spent discussing these types of issues. Part 2 is titled "Implement," and that is what it tells you-how to implement a nonrelational database. Chapters 8 to 11 cover specific nonrelational databases, using them as examples of different types of nonrelational databases that you could use to replace your relational database. Chapter 8 discusses key-value databases using the database Riak as an example. Similarly, chapter 9 covers document databases using MongoDB, chapter 10 presents column-family databases using Cassandra, and chapter 11 introduces graph databases using Neo4J. The second half of this part covers other aspects of converting to a nonrelational database. Chapter 12 talks about schemas and how to migrate data from your current relational database to a nonrelational database. Chapter 13 discusses how different needs can influence how you establish your database. Chapter 14 covers some database requirements that are not amenable to using a nonrelational database, and chapter 15 presents tips for choosing a database. Overall, this very interesting book presents some very valuable information. If you're interested in converting your database to a nonrelational database, it is an excellent source of basic information. However, I don't foresee a great rush to convert existing relational databases into nonrelational databases. The authors mention early in the book about the push in the 1990s to adopt object-oriented databases, which was overcome by inertia, cost, and the overall reliability of relational databases. I see the same situation applying to nonrelational databases. For those situations and operations that require moving an enterprise data storage and retrieval system to something that better suits the data that the enterprise stores, the choice may be a nonrelational database. However, inertia, cost, and reliability should keep relational databases around for a long time to come. Online Computing Reviews Service