Kindle Notes & Highlights
CouchDB’s design lends itself to modularization and scalability.
Its internal architecture is fault-tolerant, and failures occur in a controlled environment and are dealt with gracefully.
In a nutshell: CouchDB doesn’t let you do things that would get you in trouble later on.
CouchDB combines an intuitive document storage model with a powerful query engine
CouchDB’s design borrows heavily from web architecture and the concepts of resources, methods, and representations. It augments this with powerful ways to query, map, combine, and filter your data. Add fault tolerance, extreme scalability, and incremental replication, and CouchDB defines a sweet spot for document databases.
CouchDB’s schema-free design unburdens you with a powerful way to aggregate your data after the fact, just like we do with real-world documents.
When you want to scale out, there are three distinct issues to deal with: scaling read requests, write requests, and data.
CouchDB is no silver bullet — but in the area of data storage, it can get you a long way.
CouchDB replication is one of these building blocks. Its fundamental function is to synchronize two or more CouchDB databases.
CouchDB replication uses the same REST API all clients use.
A core assumption CouchDB makes is that things can go wrong, like network connection troubles, and it is designed for graceful error recovery instead of assuming all will be well.
it just handles errors gracefully and lets you know when actions on your end are required.
CouchDB promotes simplicity in our applications and helps us naturally build scalable, distributed systems.
CouchDB differs from others by accepting eventual consistency, as opposed to putting absolute consistency ahead of raw availability, like RDBMS or Paxos.
Their approaches differ when it comes to which aspects of consistency, availability, or partition tolerance they prioritize.
CouchDB’s solution uses replication to propagate application changes across participating nodes. This is a fundamentally different approach from consensus algorithms and relational databases, which operate at different intersections of consistency, availability, and partition tolerance.
Map functions may not depend on any information outside of the document. This independence is what allows CouchDB views to be generated incrementally and in parallel.
When writing CouchDB map functions, your primary goal is to build an index that stores related data under nearby keys.
Everything in CouchDB has an address, a URI, and you use the different HTTP methods to operate on these URIs.
CouchDB uses this revision system, which is also called Multi-Version Concurrency Control (MVCC).
One of the aspects of the HTTP protocol that CouchDB uses is that it is stateless.
Another reason CouchDB uses MVCC is that this model is simpler conceptually and, as a consequence, easier to program. CouchDB uses less code to make this work, and less code is always good because the ratio of defects per lines of code is static.
What you just did is called local replication in CouchDB terms. You created a local copy of a database.
Using a local source and a remote target database is called push replication. We’re pushing changes to a remote server.
You can also use a remote source and a local target to do a pull replication.
Finally, you can run remote replication, which is mostly useful for management operations:
Virtual documents are useful in cases where the presented view will be created by merging the work of different authors;
CouchDB is designed to work best when there is a one-to-one correspondence between applications and design documents.
Design documents are just like any other CouchDB document — they replicate along with the other documents in their database and track edit conflicts with the rev parameter.
The most important feature of a view result is that it is sorted by key.
The view result is stored in a B-tree, just like the structure that is responsible for holding your documents.
