Mariano Vazquez explains how to configure MongoDB replica sets on Microsoft Azure and how that works:

• MongoDB will run the native binaries on a worker role and will store the data in Windows Azure storage using Windows Azure Drive (basically a hard disk mounted on Azure Page blobs)
• The good thing about using Azure Storage is that the data is georeplicated. It will also make backup easier because of the snapshot feature of blob storage (which is not a copy but a diff).
• It will use the local hard disk in the VM (local resources in the Azure jargon) to store the log files and a local cache.
• You can scale out to multiple Mongo Replica Sets by increasing the instance count of the MongoDB role

Original title and link: Using MongoDB Replica Sets With Node.js on Microsoft Azure: NoSQL Tutorials (NoSQL database©myNoSQL)

via: http://nodeblog.cloudapp.net/running-mongodb-on-azure-and-connect-from-a-nodejs-web-app

Paul Querna describes the original architecture of Cloudkick and the one that powers the recently announced Rackspace Cloud Monitoring service:

Development framework: from Twisted Python and Django to Node.js

Cloudkick was primarily written in Python. Most backend services were written in Twisted Python. The API endpoints and web server were written in Django, and used mod_wsgi. […] Cloud Monitoring is primarily written in Node.js.

Storage: from master-slave MySQL to Cassandra

Cloudkick was reliant upon a MySQL master and slaves for most of its configuration storage. This severely limited both scalability, performance and multi-region durability. These issues aren’t necessarily a property of MySQL, but Cloudkick’s use of the Django ORM made it very difficult to use MySQL radically differently. The use of MySQL was not continued in Cloud Monitoring, where metadata is stored in Apache Cassandra.

Even more Cassandra:

Cloudkick used Apache Cassandra primarily for metrics storage. This was a key element in keeping up with metrics processing, and providing a high quality user experience, with fast loading graphs. Cassandra’s role was expanded in Cloud Monitoring to include both configuration data and metrics storage.

Event processing: from RabbitMQ to Zookeeper and a bit more Cassandra

RabbitMQ is not used by Cloud Monitoring. Its use cases are being filled by a combination of Apache Zookeeper, point to point REST or Thrift APIs, state storage in Cassandra and changes in architecture.

And finally Scribe:

Cloudkick used an internal fork of Facebook’s Scribe for transporting certain types of high volume messages and data. Scribe’s simple configuration model and API made it easy to extend for our bulk messaging needs. Cloudkick extended Scribe to include a write ahead journal and other features to improve durability. Cloud Monitoring continues to use Scribe for some of our event processing flows.

Original title and link: Cassandra, Zookeeper, Scribe, and Node.js Powering Rackspace Cloud Monitoring (NoSQL database©myNoSQL)

via: http://journal.paul.querna.org/articles/2011/12/17/technology-cloud-monitoring/

Allan Ebdrup:

The frontend interfaces with the backend entirely through JSONP calls and the only thing passed through those JSONP calls is pure data as JSON strings. There is no html-markup whatsoever on the backend. The separation between frontend and backend is logical as well as physical. The frontend is hosted on entirely different servers than the backend and on a different domain. […] The backend is build with Node.JS and MongoDB. The backend is also layered in tiers. There is a layer for security, a layer for returning uniform error messages and status codes and other layers.

Among the listed advantages of such an architecture:

• one programming language in the entire technology stack: JavaScript.
• scalable
• very fast load time for the users of the application
• schemaless database
• no ORM

And obviously this is a much better solution than having the front-end directly access the data store.

Original title and link: Muscula Architecture: Node.js, MongoDB, and CDN (NoSQL database©myNoSQL)

via: http://www.muscula.com/architecture

Janos stands for: JavaScript, Node.js, and a NoSQL database. Dr. Axel Rauschmayer:

It is very fortunate for JavaScript programmers that two things have become popular: JSON as a data transfer format (for web services etc.) and NoSQL databases. Both are perfect fits for JavaScript: JSON uses JavaScript syntax. Schema-less databases make things as flexible on the database side as they are on the programming language side; you get the advantages of object-oriented databases without their messiness.

Even if I’m collecting some more interesting examples of Node.js + NoSQL database, I’m still not convinced that Node’s event-oriented approach is meant to replace the Apache + Perl/Python/PHP/Ruby or the heavy lifting Tomcat + Java server side components. But I can see it used in the “small- to medium-scale” apps.

Original title and link: LAMP Replacement: The Jason Stack (NoSQL database©myNoSQL)

via: http://www.2ality.com/2011/11/janos.html

Continuing my search for non trivial node.js + NoSQL database application, here’s Factual stack for serving their API:

Factual architectural components:

• Varnish
• HAProxy
• Node.js
• Redis
• Solr

Why Node.js?

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.

Also worth mentioning is that data served through Factual API is always JSON, so having a server side JavaScript engine alsa takes reduces the need for converting data to different formats.

Original title and link: Factual API Powered by Node.js and Redis (NoSQL database©myNoSQL)

via: http://blog.factual.com/v3-api-stack-faster-data

Impressive stats for 1 x Varnish - 1 x Nginx/Node.js - 1 x MongoDB architecture. And about MongoDB:

While we tried to make MongoDB non-relational, it almost never worked. TV-Guide data contains several many-to-many relationships, and you simply can’t store them as nested objects. […] What MongoDB really does well, though, is make every JOIN explicit. This encouraged us to denormalize data onto the most specific documents to avoid a second query.

I file AolTV as a solid Node.js + NoSQL database application.

Original title and link: AolTV Powered by Node.js and MongoDB (NoSQL database©myNoSQL)

via: http://seanhess.posterous.com/surviving-a-production-launch-with-nodejs-and

A proper ending for a long but shallow chapter from Node.js in Action book:

Don’t be afraid to use more than one type of storage mechanism in an application. If you were building a content management system, for example, you might store web application configuration options using SQLite, stories using MongoDB, and user-contributed story ranking data using Redis. How you handle persistence is limited only by your imagination.

I still need to see some solid Node.js applications, as so far except visualizing Wikipedia, Node.js + NoSQL Database => Real Time Chat Applications.

Original title and link: NoSQL Databases and Node.js (NoSQL database©myNoSQL)

via: http://www.cloudcomputingdevelopment.net/nosql-databases-and-node-js/

Fascinating story about the volume of edits happening on Wikipedia and how using Redis Pub/Sub and node.js helped building some visualization tools—wikistream and wikipulse—for the activity stream:

For both of these apps I needed to log into the wikimedia IRC server, listen on ~30 different channels, push all the updates through some code that helped visualize the data in some way, and then get this data out to the browser. I had heard good things about node for high concurrency network programming from several people. I ran across a node library called socket.io that reported to make it easy to stream updates from the server to the client, in a browser independent way, using a variety of transport protocols. Instinctively it felt like the pub/sub model would also be handy for connecting up the IRC updates with the webapp. I had been wanting to play around with the pub/sub features in redis for some time, and since there is a nice redis library for node I decided to give it a try.

Original title and link: Visualizing Wikipedia Update Stream With Redis Pub/Sub and Node.js (NoSQL database©myNoSQL)

via: http://inkdroid.org/journal/2011/11/07/an-ode-to-node/

Pair Joyent Cloud’s hosted node.js SmartMachine Appliance with MongoLab’s hosted MongoDB and the integration becomes downright operatic. Angels sing. Trumpets blare. Grey storm thunderheads of object-relational-mapping haze part. Revealed are golden rays of low-impedance JSON object storage and query. All in the fertile green valley of asynchronous JavaScript on the unflappable, cool bedrock of Joyent’s SmartMachine hosting platform. Songbirds tweet. Life is good. Metaphors strain.

All that until you have to debug your code to find a missing var or purely drown under a pile of unmaintainable async Javascript code.

Original title and link: Node.js + MongoDB = Love (NoSQL database©myNoSQL)

via: http://joyeur.com/2011/10/26/node-js-mongodb-love-guest-post-from-mongolab/

Nuno Job’s NanoCouch Node.js driver for CouchDB:

After doing development like this for a while some obvious patterns started to emerge, as well as some code duplication. So the idea of nano was born: Build the minimal abstraction possible that allows you to use CouchDB from nodejs while preserving stream#pipe capabilities.

NanoCouch was well received by the CouchDB community with comments like:

Mikeal Rogers: this post is really good because it doesn’t assume you know all the little things i always forget to explain, like how the callback arguments are structured. perfect beginner article! :)

Joe McCann: This is why CouchDB and Node.js are made for each other

Original title and link: Minimalistic CouchDB Client for node.js (NoSQL database©myNoSQL)

via: http://writings.nunojob.com/2011/08/nano-minimalistic-couchdb-client-for-nodejs.html