<!Doctype html>
<html>
  <head>
    <title>NoSQL Databases</title>
    <link rel="stylesheet" type="text/css" href="../stylesheets/default.css">
    <link rel="stylesheet" type="text/css" href="../stylesheets/blog.css">
  </head>
  <body>
    <section>
      <br>
        <h1>NoSQL Databases</h1>
      <br>
        <p>Zollie Barnes<p>
        <p>December 13th, 2015</p>
      <br>
        <hr>
      <br>
        <h3>Summary</h3>
      <br>
        <p>
          NoSQL has been around since the late 1960's - that's before the creation of the internet (1982). But they've been gaining in popularity since the early 2000's.
        </p>
      <br>
        <h3>NoSQL versus Relational Databases</h3>
      <br>
        <p>
          Amazon, Google and Facebook are credited for the initial surge in populartiy for NoSQL. It's considered a simple, "horizontal" design that scales well. It has been increasingly referred to as "Not Only SQL" because these databases may support SQL-like querry languages. The data structures to choose from in NoSQL system vary - key-value, wide column, gragh, or document. But the big idea is that they depart from relational databases.
        </p>
      <br>
        <p>
          Processing speed is relative to what you're trying to accomplish when comparing NoSQL to relational databases. But there doesn't seem to be any debate that NoSQL structures are more flexible than relational databases. They can be created on relatively short time tables (a week or two rather than twelve to eighteen months) by "small, agile" teams. They can serve wide audiences using multiple platforms.
        </p>
      <br>
        <p>
          Rather than favoring consistency, NoSQL favors availability, processing data despite communication errors (partition tolerance), and speed. Instead they pursue "eventual consistency," meaning data queries might return improperly,  more slowly than ideal. There are instances of data loss, but some systems have created saftey mechanisms to prevent that.
        </p>
      <br>
        <p>
          To give you some more finite examples of NoSQL in action, I've included some exerpts I gleaned from a <a href="https://www.mongodb.com/collateral/top-5-considerations-when-evaluating-nosql-databases">white paper</a>. There is far more to learn about than the three models I've included here. So I highly recommend downloading the white paper if you'd like to learn more.
        </p>
      <br>
        <p>Document Model</p>
      <br>
        <p>
          Whereas relational databases store data in rows and columns, document databases store data in documents. Documents provide an intuitive and natural way to model data that is closely aligned with object-oriented programming – each document is effectively an object. Documents contain one or more fields, where each field contains a typed value, such as a string, date, binary, or array. Rather than spreading out a record across multiple columns and tables connected with foreign keys, each record and its associated data are typically stored together in a single document. This simplifies data access and, in many cases, eliminates the need for expensive operations and complex, multi-record transactions.
        </p>
      <br>
        <p>Graph Model</p>
      <br>
        <p>
          Graph databases use graph structures with nodes, edges and properties to represent data. In essence, data is modeled as a network of relationships between specific elements. While the graph model may be counter-intuitive and takes some time to understand, it can be useful for a specific class of queries. Its main appeal is that it makes it easier to model and navigate relationships between entities in an application. Graph databases are useful in cases where traversing relationships are core to the application, like navigating social network connections, network topologies or supply chains.
        </p>
      <br>
        <p>Consistency Model</p>
      <br>
        <p>
          From a data model perspective, key-value stores are the most basic type of non-relational database. Every item in the database is stored as an attribute name, or key, together with its value. The value, however, is entirely opaque to the system; data can only be queried by the key. This model can be useful for representing polymorphic and unstructured data, as the database does not enforce a set schema across key-value pairs. Key value stores and wide column stores are useful for a narrow set of applications that only query data by a single key value. The appeal of these systems is their performance and scalability, which can be highly optimized due to the simplicity of the data access patterns and opacity of the data itself.
        </p>
      <br>
      <br>
    </section>
  </body>
</html>