ALL COVERED TOPICS

NoSQL Benchmarks NoSQL use cases NoSQL Videos NoSQL Hybrid Solutions NoSQL Presentations Big Data Hadoop MapReduce Pig Hive Flume Oozie Sqoop HDFS ZooKeeper Cascading Cascalog BigTable Cassandra HBase Hypertable Couchbase CouchDB MongoDB OrientDB RavenDB Jackrabbit Terrastore Amazon DynamoDB Redis Riak Project Voldemort Tokyo Cabinet Kyoto Cabinet memcached Amazon SimpleDB Datomic MemcacheDB M/DB GT.M Amazon Dynamo Dynomite Mnesia Yahoo! PNUTS/Sherpa Neo4j InfoGrid Sones GraphDB InfiniteGraph AllegroGraph MarkLogic Clustrix CouchDB Case Studies MongoDB Case Studies NoSQL at Adobe NoSQL at Facebook NoSQL at Twitter

NAVIGATE MAIN CATEGORIES

Close

Creating a MongoDB Queuing System

The Boxed Ice guys have posted a very detailed article about the requirements, implementation, plus some pros and cons of building a custom queuing system on top of MongoDB. Embedded below is a slidedeck giving an overview, but I’d encourage you to read the whole post:

In case like you are wondering why the original title is “Replacing RabbitMQ with MongoDB” and the real reasons that led the guys to this migration, the answer is briefly mentioned at the end of the post and in an older post:

  • All of the PHP AMQP libraries we tried were too unstable – either they didn’t work at all or they worked in low load testing but at high loads, performed terribly. We saw excellent response times and then suddenly there would be a massive spike and the entire postbacks process would hang. This appeared to be being caused by the connection pool resetting and every insert trying to recreate its connection.
  • Fault tolerance – replica sets in MongoDB work extremely well to allow automatic failover and redundancy. The original reason we removed RabbitMQ was no in-built support for redundancy across multiple nodes/data centres. This is now possible as of RabbitMQ 2.6.0.

Original title and link: Creating a MongoDB Queuing System (NoSQL database©myNoSQL)