SQL and NoSQL
NoSQL Data Model Categories
Document Model
Rather than spreading out a record across multiple columns and tables connected with foreign keys, each record and its associated (i.e., related) data are typically stored together in a single document. This simplifies data access and, in many cases, eliminates the need for expensive JOIN operations and complex, multi-record transactions. It easier to evolve an application during development, such as adding new fields. Additionally, document databases generally provide the query robustness that developers have come to expect from relational databases. In particular, data can be queried based on any combination of fields in a document. Document databases are general purpose, useful for a wide variety of applications due to the Pexibility of the data model. Examples: MongoDB and CouchDB.
The document data model is the most natural and most productive because it maps directly to objects in modern object-oriented languages
Graph Model
Graph databases use graph structures with nodes, edges and properties to represent data. Its main appeal is that it makes it easier to model and navigate relationships between entities in an application. Applications: navigating social network connections, network topologies or supply chains. Examples: Neo4j and Giraph
Key-Value and Wide Column Model
It is the most basic type of non-relational database. This model can be useful for representing polymorphic and unstructured data, as the database does not enforce a set schema across key-value pairs.
Wide column stores, or column family stores, use a sparse, distributed multi-dimensional sorted map to store data. Each record can vary in the number of columns that are stored. Columns can be grouped together for access in column families, or columns can be spread across multiple column families. Data is retrieved by primary key per column family.
Examples: : Riak and Redis (Key-Value); HBase and Cassandra (Wide Column).
The wide column model provides more granular access to data than the key value model, but less Pexibility than the document data model.
NoSQL Query Model Categories
Document Model
MongoDB, provide a rich set of indexing options to optimize a wide variety of queries, including text indexes, geospatial indexes, compound indexes, sparse indexes, time to live (TTL) indexes, unique indexes, and others. MongoDB, for instance, provides both the Aggregation Framework for providing real-time analytics (along the lines of the SQL GROUP BY functionality), and a native MapReduce implementation for other types of sophisticated analyses. To update data, MongoDB provides a Ond and modify method so that values in documents can be updated in a single statement to the database, rather than making multiple round trips.
Document databases provide the richest query functionality, which allows them to address a wide variety of operational and real-time analytics applications.
Graph Database
Relationship-type analysis tends to be very efOcient in these systems, whereas other types of analysis may be less optimal. As a result, graph databases are rarely used for more general purpose operational applications.
MongoDB 3.4 introduces graph computing natively within the database, enabling eficient traversals across graphs, trees, and hierarchical data to uncover patterns and surface previously unidentiOed connections.
Key-Value and Wide Column Database
To perform an update in these systems, multiple round trips may be necessary: first and the record, then update it, then update the index.
Consistency Model
Maintain multiple copies of the data for availability and scalability purposes. With a consistent system, writes by the application are immediately visible in subsequent queries. With an eventually consistent system writes are not immediately visible.
Consistent Systems
Document databases and graph databases can be consistent or eventually consistent. MongoDB provides tunable consistency. By default, data is consistent — all writes and reads access the primary copy of the data. As an option, read queries can be issued against secondary copies where data maybe eventually consistent if the write operation has not yet been synchronized with the secondary copy; the consistency choice is made at the query level.
Eventually Consistent Systems
This may be acceptable for read-only applications and data stores that do not change often, like historical archives. Eventually consistent systems must be able to accommodate conPicting updates in individual records. Because writes can be applied to any copy of the data, it is possible and not uncommon for writes to conPict with one another. Some systems like Riak use vector clocks to determine the ordering of events and to ensure that the most recent operation wins in the case of a conPict. Other systems like CouchDB retain all conPicting values and push the responsibility to resolving conPict back to the user. Another approach, followed by Cassandra, is simply to assume the latest value is the correct one. For these reasons, inserts tend to perform well in eventually consistent systems, but updates and deletes can involve trade-offs that complicate the application signiOcantly
APIs
Idiomatic Drivers
For programmers, idiomatic drivers are easier to learn and use, and they reduce the onboarding time for teams to begin working with the underlying database. For example, idiomatic drivers provide direct interfaces to set and get documents or Oelds within documents. With other types of interfaces it may be necessary to retrieve and parse entire documents and navigate to speciOc values in order to set or get a Oeld. MongoDB supports idiomatic drivers in over ten languages: Java, .NET, Ruby, Node.js, Perl, Python, PHP, C, C++, C#, Javascript, and Scala. 30+ other drivers are supported by the community.
Thrift or RESTful APIs
Some systems provide RESTful interfaces. This approach has the appeal of simplicity and familiarity, but it relies on the inherent latencies associated with HTTP. It also shifts the burden of building an interface to the developers; and this interface is likely to be inconsistent with the rest of their programming interfaces. Similarly, some systems provide a Thrift interface, a very low level paradigm that shifts the burden to developers to develop more abstract interfaces within their applications.
SQL-Like APIs
Most support queries only, with no support for write operations. Therefore developers will still need to learn the database’s native query language. SQL-based BI, reporting, and ETL tools will not be compatible with a custom SQL implementation. Trying to impose a relational model on any non-relational database will have disastrous consequences for performance and application maintenance.