Object Relational Mapping (ORM) - mattoattacko/class GitHub Wiki

General

  • NoSQL databases are usually compared by non-functional criteria like scalability, performance, and consistency.
  • Specific non-functional properties are usually the reason we use NoSQL, and its ability to use fundamental results on distributed systems (such as CAP theorem).
  • NoSQL data not well studied.
  • Key-Value model is not good at situations that need processing of key ranges. Ordered key-value model is better and does not have that limitation.
  • The ordered key-value model is good but does not give us any framework for value modeling.
  • NoSQL data modeling often starts from the application-specific queries, where a rational modeling is driven by the structure of available data. "What answers do I have?"
  • NoSQL data modeling is driven by application-specific access patterns (types of queries to be supported). "What questions do I have?"

Principals of NoSQL Data Modeling

  • Denormalization: copying the same data into multiple documents or tables in order to better optimize query processing or to fit the user's data into a particular data model. Query data volume or IO per query VS total data volume means we need duplicate data, which increases total data volume. Processing complexity VS total data volume. Denormalization allow us to store data in a query-friendly structure to simplify query processing.
  • Applicability: key-value stores, document databases, BitTable-style databases
  • Aggregates: key-value stores and graph databases usually don't put constraints on values, thus values can be comprised of arbitrary format. BigTable models support soft schema via a variable set of colums w/in a column family and variable number of versions for one cell.
  • Soft schema lets us form classes of entities with complex internal structures and vary the structure of particular entities. This allows us to minimize one-to-many relationships via nested entities and reduction of joins. It also masks technical differences between business entities and modeling of same business entities using on collection of documents or just one table.
  • Also of note is application side joins, atomic aggregates, enumerable keys, dimensionality reduction, index tables, composite key index, aggregation w/ composite keys, inverted search - direct aggregation, tree aggregation, adjacency lists, materialized paths, nested sets, etc.

SQL vs NoSQL Databases

  • SQL = structured query language
  • SQL DBs = MySql, Oracle, Sqlite, Postgres, MS-SQL
  • NoSQL DBs = MongoDB, BigTable, Redis, RavenDb, Cassandra, Hbase, Neo4j, CouchDb
  • SQL DBs are usually called "relational databases (RDBMS)".
  • NoSQL DBs are usually called as non-relational/distributed DBs
  • SQL DBs are table based, NoSQL DB's are document based, key-value pairs, graph DBs, or wide-column stores. Thus SQL DBs represent data in form of tables that have "n" number of rows of data. NoSQL DBs are the collection of key-value pair, documents, graph DBs, or wide-column stores that don't have standard schema definitions that it needs to follow.
  • SQL DBs have a predefined schema, while NoSQL DBs have a dynamic schema for unstructured data.
  • SQL DBs are vertically scalable. NoSQL DBs are horizontally scalable. You scale SQL DBs via increasing the power of the hardware. NoSQL DBs are scaled via increasing the DBs servers in the pool of resources to reduce the load.
  • SQL DBs use SQL to define and manipulate data. NoSQL uses queries that are focused on collection of documents.
  • SQL DBs are not good for hierarchical data storage. NoSQL DBs are better at hierarchical data storage since it uses the key-value pair way of storing data. Much like JSON.
  • NoSQL DBs are preferred for large data sets.
  • More support is available for SQL databases (via their vendors). NoSQL less so.