Key Points from NoSQL Distilled Modeling Data for NoSQL Document Databases https://www.youtube.com/watch?v=-o_VGpJP-Q0
This presentation was recorded at GOTO Aarhus 2012
Martin Fowler - Author, Speaker, Consultant & General Loud-mouth on Software Development
Martin gives a rapid introduction to NoSQL databases: where they came from, the nature of the data models they use, and the different way you have to think about consistency. From this he outlines what kinds of circumstances you should consider using them, why they will not make relational databases obsolete, and the important consequence of polyglot persistence.
Domain Driven Design Video - Eric Evans Domain Driven Design Book - Eric Evans
Document - MongoDb RavenDb CouchDb
Key-Value - Redis Riak Project Voldemort
Column n- Family - Cassandra Apache/Hbase
Graph - Neo4j
Aggregate Oriented - Relational
In computing, a graph database is a database that uses graph structures for semantic queries with nodes, edges and properties to represent and store data. A key concept of the system is the graph (or edge or relationship), which directly relates data items in the store. The relationships allow data in the store to be linked together directly, and in many cases retrieved with one operation.
Graph databases, by design, allow simple and fast retrieval of complex hierarchical structures that are difficult to model in relational systems. Graph databases are similar to 1970s network model databases in that both represent general graphs, but network-model databases operate at a lower level of abstraction[1] and lack easy traversal over a chain of edges.
The underlying storage mechanism of graph databases can vary. Some depend on a relational engine and store the graph data in a table. Others use a key-value store or document-oriented database for storage, making them inherently NoSQL structures. Most[according to whom?] graph databases based on non-relational storage engines also add the concept of tags or properties, which are essentially relationships lacking a pointer to another document. This allows data elements to be categorized for easy retrieval en masse.
Graph databases are based on graph theory, and employ nodes, edges, and properties.
Nodes represent entities such as people, businesses, accounts, or any other item to be tracked. They are roughly the equivalent of the record, relation, or row in a relational database, or the document in a document database. Edges, also termed graphs or relationships, are the lines that connect nodes to other nodes; they represent the relationship between them. Meaningful patterns emerge when examining the connections and interconnections of nodes, properties, and edges. Edges are the key concept in graph databases, representing an abstraction that is not directly implemented in other systems. Properties are germane information that relate to nodes. For example, if Wikipedia were one of the nodes, it might be tied to properties such as website, reference material, or word that starts with the letter w, depending on which aspects of Wikipedia are germane to a given database.
An atomic transaction is an indivisible and irreducible series of database operations such that either all occur, or nothing occurs. A guarantee of atomicity prevents updates to the database occurring only partially, which can cause greater problems than rejecting the whole series outright.
In computer science, ACID (Atomicity, Consistency, Isolation, Durability) is a set of properties of database transactions. In the context of databases, a sequence of database operations that satisfies the ACID properties and, thus, can be perceived as single logical operation on the data is called a transaction.
For example, a transfer of funds from one bank account to another, even involving multiple changes such as debiting one account and crediting another, is a single transaction.
Offline Lock - Give each update a version stamp
sharding data
replicate data
availibility over consistency
Cap Theorem (Pick 2) - Consistency - Availibility - PartitionTolerance
Large scale data