NoSQL Distilled Key Points

Why NoSQL?

1. Relational databases have been a successful technology for twenty years,providing rersistence,concurrency control,and integration mechanism.
2. Application developers have been frustrated with the impedance mismatch between the relational model and the in-memory data structures.
3. There is a movement away from using databases as integration points towards encapsulating databases within applications and integrating through services.
4. The vital factor for a change in data storage was the need to support large volumes of data by running on clusters.Relational databases are not designed to run efficiently on clusters.
5. NoSql is an accidental neologism.There is no prescriptive definition - all you can make is an observation of common characteristics.
6. The common characteristics of NoSQL database are
1. Not using the relational model
2. Running well on clusters
3. Open-source
4. Built for the 21st century web estates
5. Schemaless
7. The most important result of the rise of NoSQL is Polyglot Persistence.

Aggregate Data Models

1. An aggregate is a collection of data that we interact with as a unit.Aggregates form the boundaries for ACID operation with the database.
2. Key-value,document,and column-family databases can all be seen as forms of aggregate-oriented database.
3. Aggregates make it easier for the database to manage data storage over clusters.
4. Aggregate-oriented databases work best when most data interactions is done with the same aggregate;aggregate-ignorant databases are better when interactions use data organized in many different formations.

More Details on Data Models

1. Aggregate-oriented databases mak inter-aggregate relationships more difficult to handle than intra-aggregate relationships.
2. Graph databases organize data into node and edge graphs;they work best for data that has complex relationship structures.
3. Schemaless databases allow you to freely add fields to records,but there is usually an implicit schema expected by users of the data.
4. Aggregate-oriented databases often compute materialized views to provide data organized differently from their primary aggregates.This is often done with map-reduce computations.

Distribution Models

1. There are two styles distribution data:
1. Sharding distributes different data across multiple servers,so each server acts as the single source for a subset of data
2. Replication copies data across multiple servers,so each bit of data can be found in multiple places.
3. A system may use either or both technigues.
2. Replication comes in two forms:
1. Master-slave replication makes one node the authoritative copy that handles writes while slaves synchronize with the master and may handle reads.
2. Peer-to-peer replication allows writes to any node;the nodes coordinate to synchronize their copies of the data.
3. Master-slave replication reduces the chance of update conflicts but peer-to-peer replication avoids loading all writes onto a single point of failue.

Consistency

1. Write-write confilcts occur when two clients try to write the same data at the same time.Read-write conflicts occur when one client reads inconsistent data in the middle of another clients's write.
2. Pessimistic approaches lock data record to prevent conflicts.Optimistic approaches detect conflicts and fix them.
3. Distributed systems see read-write conflicts due to some nodes having received updates while other nodes have not.Eventual consistency means that at some point the system will become consistent once all the writes have propagated to all the nodes.
4. Clients usually want read-your-writes consistency,which means a client can write and then immediately read the new value.This can be difficult if the read and the write happen on different nodes.
5. To get good consistency,you need to involve many nodes in data operations,but this increases lantency.So you often have to trade off consistency versus latency.
6. The CAP theorem states that if you get a network partition,you have to trade off availability of data versus consistency.
7. Durability can also be traded off against latency,particularly if you want to survive failures with replicated data.
8. You do not need to contact all replicants to preserve strong consistency with replication;you just need a large enough quorum.

Version Stamps

1. Version stamps help you detect concurrency conflicts.When you read data,then update it,you can check the version stamp to ensure nobody updated the data between your read and write.
2. Version stamps can be implemented using counters,GUIDs,content hashes,timestamps,or a combination of thses.
3. With distributed systems,a vector of version stamps allows you to detect when different nodes have conflictiong updates.

Map-Reduce

1. Map-reduce is a pattern to allow computations to be parallelized over a cluster.
2. The map task reads data from an aggregate and boils it down to relevant key-value pairs.Maps only read a single record at a time and can thus be parallelized and run on the node that stores the record.
3. Reduce tasks take many values for a single key output from map tasks and summarize them into a single output.Each reducer operates on the result of a single key,so it can be parallelized by key.
4. Reducers that have the same form for input and output can be combined into pipelines.This improves parallelism and reduces the amount of data to be transferred.
5. Map-reduce operations can be composed into pipelines where the output of one reduce is the input to another operation's map.
6. If the result of a map-reduce computation is widely used,it can be stored as a materialized vies.
7. Materialized views can be updated through incremental map-reduce operation that only compute changes to the vies instead of recomputing everything from scratch.

Key-Value Databases

1. Suitable Use Cases
1. Storing Session Information
2. User Profiles,Preferences
3. Shopping Cart Data
2. When Not to use
1. Relationships among data
2. Multioperation transactions
3. Query by data
4. Operations by sets

Document Database

1. Suitable use cases
1. Event logging
2. Content management systems,blogging platforms
3. Web analytics of real-time analytics
4. E-Commerce applications
2. When not to uses
1. Complex transactions spanning different operations
2. Queries against varying aggregate structure

Column-family stores

1. Suitable use cases
1. Cvent logging
2. Content management system,blogging platforms
3. Counters
4. Expiring usage

Graph databases

1. Suitable use cases
1. Connected data
2. Routing,dispatch,and location-based services
3. Recommendation engines

Schema Migrations

1. Databases with strong schemas,such as relational databases,can be migrated by saving each schema change ,plus its data migration,in a version-controlled sequence.
2. Schemaless databases still need careful migration due to the implicit schema in any code that accesses the data.
3. Schemaless databases can use the same migration techniques as databases with strong schemas.
4. Schemaless databases can also read data in a way that's tolerant to changes in the data's implicit schema and use incremental migration to update data.

Ployglot Persistenc

1. Polyglot persistence is about using different data storage technologies to handle varying data storage needs.
2. Polyglot persistence can apply across an enterprise of within a single application.
3. Encapsulating data access into services reduces the impact of data storage choices on other parts of a system.
4. Adding more data storage technologies increases complexity in programming and operations,so the advantages of a good data storage fit need to by weighted against this complexity.

Beyond NoSQL

1. NoSQL is just one set of data storage technologies.As they increase comfort with polyglot persistence,we should consider other data storage technologies whether or not they bear the NoSQL label.

Choosing Your Database

1. The two main reasons to use NoSQL technology are:
1. To improve programmer productivety by using a database that better matches an application's needs.
2. To improve data access performance via some combination of handling larger data volumes,reducing latency,and improving throughput.
2. It's essential to test your expectations about programmer productivity and/or performance before committing to using a NoSQL technology.
3. Service encapsulation supports changing data storage technologies as needs and technology evolve.Separating parts of applications into services also allows you to introduce NoSQL into an existing application.
4. Most applications,particularly nonstrategic ones,should stick with relational technology - at least the NoSQL ecosystem becomes more mature.