Note: I’ve made some edits and added a little extra section about clustering at the end.
Nuno Job — nano - minimalistic CouchDB client for nodejs June 19, 2012 at 06:27PM
If you are asked to compare (or you just wonder about) the performance of link walking and map-reduce in Riak keep in mind the following details of how the two mechanism are implemented:
The biggest difference I see is that the link-walk uses an Erlang function where your MapReduce query uses…
Getting Started with CouchDB Extreme Scalability at Your Fingertips
By MC Brown
Publisher: O’Reilly Media
Released: January 2012
Doodle-Anleitung / Doodle-Tutorial
Original title and link: Interesting Data Sets and Tools: Monthly Twitter Activity for All Members of the U.S. Congress ( ©myNoSQL)
Basic strategies in building a decentralized and anonymous database
No central servers. A central server is a central point of failure.
No central authorities. A central authority over control of the database indicates another ( and much worse ) central point of failure.
Ability to encrypt and obscure data.
Ability to run in any combination of local / cloud / hosted. The database should be able to run locally, on hosted servers, and in the cloud.
- Ability to easily share and replicate data. The data should be able to easily transfer and replicate between multiple systems and users.
Till Klampaeckel und ich haben ein Buch über CouchDB geschrieben. Es ist im Galileo Computing Verlag erschienen. Till hat ausserdem eine coole website mit vielen Informationen, Code und Links zum Buch erstellt. Einfach mal hier gucken:
Quite some time has passed since I started having fun with CouchDB. After using the usual PHP/MySQL Combo for more than a decade now, I’m quite used to the thought of using a three layer model to build web applications. I was so blinded by that “usual” procedure that I didn’t even think about it any other way.
Continuing my search for non trivial node.js + NoSQL database application, here’s Factual stack for serving their API:
Factual architectural components:
We chose Node because of three F’s: it’s fast, flexible, and familiar. In particular, the flexibility is what allowed us to use our Node layer to handle things like caching logic and load balancing, in addition to the aforementioned authentication and authorization. To make our Node layer scalable, we use multiple instances of Node tied together with Redis to keep things in sync.
Original title and link: Factual API Powered by Node.js and Redis ( ©myNoSQL)