Types
|
One type (SQL database) with minor variations
|
Many different types including key-value stores ,document databases, wide-column stores, and graph databases
|
Development History
|
Developed in 1970s to deal with first wave of data storage
applications
|
Developed in 2000s to deal with limitations of SQL databases,
particularly concerning scale, replication and unstructured data storage
|
Examples
|
MySQL, Postgres, Oracle Database
|
MongoDB, Cassandra, HBase, Neo4j
|
Data Storage Model
|
Individual records (e.g., "employees") are stored as rows
in tables, with each column storing a specific piece of data about that
record (e.g., "manager," "date hired," etc.), much like a
spreadsheet. Separate data types are stored in separate tables, and then
joined together when more complex queries are executed. For example,
"offices" might be stored in one table, and "employees"
in another. When a user wants to find the work address of an employee, the database
engine joins the "employee" and "office" tables together
to get all the information necessary.
|
Varies based on database type. For example, key-value stores function
similarly to SQL databases, but have only two columns ("key" and
"value"), with more complex information sometimes stored within the
"value" columns. Document databases do away with the table-and-row
model altogether, storing all relevant data together in single
"document" in JSON, XML, or another format, which can nest values
hierarchically.
|
Schemas
|
Structure and data types are fixed in advance. To store information
about a new data item, the entire database must be altered, during which time
the database must be taken offline.
|
Typically dynamic. Records can add new information on the fly, and
unlike SQL table rows, dissimilar data can be stored together as necessary.
For some databases (e.g., wide-column stores), it is somewhat more
challenging to add new fields dynamically.
|
Scaling
|
Vertically, meaning a single server must be made increasingly
powerful in order to deal with increased demand. It is possible to spread SQL
databases over many servers, but significant additional engineering is
generally required.
|
Horizontally, meaning that to add capacity, a database administrator
can simply add more commodity servers or cloud instances. The database
automatically spreads data across servers as necessary
|
Development Model
|
Mix of open-source (e.g., Postgres, MySQL) and closed source (e.g.,
Oracle Database)
|
Open-source
|
Supports Transactions
|
Yes, updates can be configured to complete entirely or not at all
|
In certain circumstances and at certain levels (e.g., document level
vs. database level)
|
Data Manipulation
|
Specific language using Select, Insert, and Update statements, e.g.
SELECT fields FROM table WHERE…
|
Through object-oriented APIs
|
Consistency
|
Can be configured for strong consistency
|
Depends on product. Some provide strong consistency (e.g., MongoDB)
whereas others offer eventual consistency (e.g., Cassandra)
|
Sunday, 1 February 2015
NoSQL vs. SQL
DBT - Models
Models are where your developers spend most of their time within a dbt environment. Models are primarily written as a select statement and ...
-
Upon using the custom query in the source object, the mapping fails with the following error: The select query for read operation failed bec...
-
Data mining is the process of finding patterns from large data sets and analyzing data from different perspectives. It allows business use...