Nosql for Mere Mortals Chapter 1 Review Questions and Answers
Addison-Wesley Professional'south NoSQL for Mere Mortals provides an introduction to NoSQL databases spanning across the major types of databases that autumn under the NoSQL umbrella and explaining both advantages and shortcomings that each database type offers. InfoQ has spoken with the book'southward author, Dan Sullivan.
The books starts with a full general discussion of the ACID (Atomic, Consistent, Isolated, Durable) and Base of operations (Basically Available, Soft state, Eventually consistent) paradigm for databases. This provides an overarching analytical frame where the comparison between NoSQL and SQL databases can be situated. The four NoSQL database properties (Base) are explained in item and a specially compelling explanation is provided of the different choices that different NoSQL databases accept made to ensure eventual consistency.
The book then goes on to describe each of the four main types of NoSQL database: key-value databases, document databases, cavalcade family databases, and graph databases. For each type, the book provide a curtailed introduction of its main features and what features differentiate it from other NoSQL databases, so devote a full chapter to considerations about designing a database of that specific type. This covers material such every bit, e.k.:
- how to correctly define the key and how to represent structured information for Fundamental-Value databases;
- how to handle the normalization/denormalization rest and most effectively use joins for Document databases;
- how to design tables, denormalize them, handle indexing, etc. for Cavalcade family databases;
- how to query a graph, utilize indexes, define graph edges etc., for Graph databases.
The final part of the book deals with choosing the right database for an application by providing a set of guidelines that can help in the determination process.
Overall, the book stands out for its clarity and highly structured arroyo to presenting NoSQL databases. The book furthermore provides a few case report examples of NoSQL databases applied to a business application to make the whole discussion even more than concrete and easily-down. InfoQ has taken the chance to speak to Dan Sullivan, writer of the book.
InfoQ: What has motivated y'all to write this book? What makes it unique among other NoSQL books?
Dan: This is an active time of research and experimentation in the database field. For decades, relational databases dominated the field. Advances focused on improving the functioning of relational databases, which led to important developments such as columnar storage. NoSQL databases emerged because demanding use cases in companies like Google, Yahoo and Facebook could not be met with relational databases. The idea of writing a book virtually the recent advances in database technology was too tempting to turn down. This volume is different from other NoSQL books in that it does not focus on a particular NoSQL database but describes each of the 4 major types: central value, certificate, cavalcade family and graph databases. In improver, this book delves into the technical details that someone implementing a NoSQL database will demand to know. Some NoSQL books focus on explaining loftier level principles for business users and these are valuable resources. NoSQL for Mere Mortals takes a dissimilar approach and addresses the needs of someone who must select a NoSQL platform, pattern an awarding using a NoSQL database, or tune and maintain NoSQL databases as office of their piece of work.
InfoQ: What should a reader expect from reading "NoSQL for Mere Mortals"?
Dan: Readers should expect a quick introduction to why NoSQL databases have emerged and how they fit into the broader database landscape. The bulk of the volume is organized into iv sections, ane on each of the 4 main types of NoSQL databases. Each section introduces a NoSQL model, such as document databases, provides a detailed description of key concepts and terminologies, and concludes with blueprint guidelines and tips. The concluding affiliate of the book offers assist on choosing the all-time database for your awarding needs.
Some other indicate that is emphasized throughout the book is that NoSQL databases complement relational databases, they practise not replace them. Relational databases accept successfully served the needs of an expanding array of application requirements since the 1970s and that will not change. NoSQL databases add to our tool chest, they don't displace other tools.
InfoQ: The relational data model has served programmers for a long fourth dimension. What made programmers start looking for alternative models?
Dan: Relational databases were designed to address limitations plant in before data direction systems, such as hierarchical databases and block storage systems. The rules of normalization in relational database design assist us avoid data anomalies. This is essential in many business applications, especially fiscal systems. As developers created new types of applications driven by the Web, such as search engines, they confronted scalability issues. While relational databases are well suited to handle thousands of enterprise users, information technology is more difficult to make them scale to meet the needs of hundreds of thousands or millions of Web users. While scalability was a key concern, other factors such equally firsthand consistency and ACID transactions were less important. This gave NoSQL designers that latitude they needed to experiment with new database models that could encounter a new set of requirements based on the Web and not enterprise applications.
InfoQ: What are, on the other hand, the advantages that developers tin await from using a NoSQL database?
Dan: I of the most obvious advantages of using NoSQL databases is that developers tin can cull a data model that aligns with their problem domain. Someone modeling a transportation system or social network might opt for a graph database. Someone requiring high performance writes and reads based only on keys might plough to primal value database. Document databases are well suited to applications requiring flexible schemas and support for semi-structured information. Column family unit databases are particularly well suited for big data applications requiring flexible schemas.
InfoQ: What kind of drawbacks can one expect from abandoning the rubber harbour of a theoretically well grounded model such as the relational model?
Dan: There are a number of drawbacks. NoSQL databases typically practice not support the level of constraint enforcement found in RDBMSs. Too, attributes tin be added to a certificate database dynamically by an application without the need to have a data modeler update a schema and deploy those changes to production. Information modelers might cringe at this. Afterwards all, if at that place is no master schema, who is responsible for managing it? The answer is: nosotros all are. We demand to develop new procedures for tracking changes in flexible schema and no schema data models.
InfoQ: What is the main claiming when trying to make the decision to move away from the relational model to NoSQL?
Dan: The first question to address is, exercise y'all really need to move to a NoSQL database? If you have a team that is experienced with relational databases and you have procedures in place for maintaining your relational database you lot should ask yourself, what are the benefits of moving to NoSQL?
- If you find yourself working around the relational model, for example, heavily de-normalizing for query operation, and so it makes sense to consider a NoSQL database.
- If you are confronted with the prospect of having to upgrade your database server at significant cost, and so it's time to consider NoSQL databases. Most of the NoSQL databases are designed to scale horizontally on commodity hardware.
- If you observe it hard to efficiently implement some queries in a relational database, such every bit recursively searching a network, so consider a NoSQL database.
InfoQ: Could yous broadly sketch the main characteristics of the various flavours of NoSQL databases that the volume covers?
Dan: There are four main types of NoSQL databases covered in the book: key value, certificate, column family and graph databases.
Cardinal value databases apply the simplest data model. Data is stored and referenced by an index or key. This kind of database provides dictionary-like look ups but lack SQL-like query support. Key value databases, such as Redis and Riak, are good fits for applications that need loftier performance reads and writes of relatively atomic data structures. Riak has added search capabilities to provide more flexible retrieval options.
Document databases are probably the almost popular of the NoSQL databases. A document is a collection of key value pairs. The set of key value pairs is roughly coordinating to a row in a table but the keys, or attributes, can vary from one document to another. Documents also back up non-atomic structures such as arrays and embedded documents. Document databases are skilful choices when you need a flexible schema and more avant-garde query back up than provided in key value databases. Joins are generally avoided in document databases but if you demand them, you should plan to implement them yourself in the application layer.
Column family databases, such as HBase and Cassandra, are based on Google'southward BigTable. Column family databases are similar to relational databases on the surface but utilise fundamentally different implementations. Column family unit databases utilize map information structures to implement thin matrix-like structures. Column families are designed to support millions of columns and billions of rows. Needless to say, this introduces the opportunity for new design techniques not available in relational databases.
InfoQ: When it comes to the design process, how would you depict any differences between designing a RDBMS-based organization and a NoSQL-based organisation?
Dan: Ane of the main differences is the questions we ask when we pattern a data model. In relational modeling, we ask how are entities related and what are their attributes? When designing NoSQL models nosotros typically start with the queries we volition run against the database. This may non sound like a big divergence at start but the implications are important.
In relational modeling we start by understanding, as much as we can, the relation between entities because in one case we have that we can reply whatever queries about the entities. This approach lends itself to normalizing the data which reduces the risk of information anomalies.
In NoSQL blueprint, there are no mathematical models akin to relational algebra from which nosotros derive design principles. Instead, we consider utilize cases and query patterns and design structures that balance performance with data redundancy. For example, when modeling a master-item relation in a certificate database, such as MongoDB, yous could embed a reference to a item document or the details document itself. Embedding references is similar to using foreign central references in relational databases while embedding details is a de-normalizing approach. Which is better? That depends on the query admission patterns. If you query the chief attributes frequently but rarely need attributes of the detail record then embedding references is a better option. In cases in which yous demand both principal and detail attributes in frequently run queries, embedding particular documents may be a better option.
InfoQ: Could y'all share your view about the future of NoSQL databases?
Dan: NoSQL databases are speedily advancing and incorporating additional features. The advances are coming on three fronts.
NoSQL databases are incorporating features of relational databases, such equally support for transactions. Some NoSQL databases have at least limited back up for transactions at present but the trend will exist to incorporate more robust transaction control. This may innovate functioning hits, but application designers will take the option of using transactions when they need them and avoiding the functioning cost of transactions when they don't.
NoSQL databases are becoming multi-modal, supporting more than than one blazon of NoSQL information model. Amazon's DynamoDB started as a fundamental value information shop but now supports documents as well. OrientDB is a certificate database with support for graph databases every bit well. DataStax, a commercial venture supporting the Cassandra column family database, recently acquired the development team behind Titan, a highly scalable graph database. Eventually, we will take the option of storing our data in a single database while accessing the information as graphs, documents, etc. depending on which makes the nearly sense for the particular application.
The cloud will lower the barriers to adoption. Google has recently made BigTable, the original column family database, generally available. Amazon offers DynamoDB and Microsoft offers DocumentDB. Using a database as a service (DBaaS) platform allows developers to get started with NoSQL databases without having to accept on all the database assistants and tuning tasks associated with a self-managed platform.
InfoQ: Practice you think there could be a trend leading to using a RDBMS to store schema less information?
Dan: Yes, I call up we are already seeing that. This pattern of relational databases adopting non-relational models is not new. Object databases were something of an alternative to relational databases in the 1990s but did not catch on as much as NoSQL is today. Instead, databases like Oracle incorporated object database features into the relational model.
The limiting gene will be how well relational storage models support the performance demands of NoSQL databases. Relational databases may be used to store cardinal value, documents or graphs right now, but is that the best option? Column family databases exercise not employ the row or columnar storage models normally used in relational databases. Instead, they utilize maps to efficiently shop thin data in tables with potentially millions of attributes and billions of rows.
There are some use cases where storing NoSQL data structures in relational database will make sense, especially when dealing with relatively small volumes of data. One time you get-go pushing the limits of your relational database server and need to scale up, it is time to consider using a database with a storage model that is a more natural fit with your information model.
Virtually the Book Author
Dan Sullivan is a data architect and data scientist with more 20 years of experience in business concern intelligence, machine learning, data mining, text mining, Big Information, data modeling, and application design. His well-nigh recent piece of work has focused on NoSQL database modeling, information analysis, cloud computing, text mining and data integration in life sciences. Dan has extensive experience in relational database design and works regularly with NoSQL databases.
Source: https://www.infoq.com/articles/nosql-for-mere-mortals-review/
0 Response to "Nosql for Mere Mortals Chapter 1 Review Questions and Answers"
Post a Comment