I am not going to link to this article - no point in giving it more attention. The anonymous post claimed data loss and basic disaster using MongoDB. I call bullshit on this anonymous rant. Why was it posted anonymously? I am sitting in an airport waiting to fly home right now: just finished extending a Java+MongoDB+GWT app and I am starting to do more work on a project using Clojure+Noir+MongoDB. I do have a short checklist for using MongoDB: For each write operation I decide if I can use the default write and forget option or slightly slow down the write operation by checking CommandResult cr = db.getLastError(); - every write operation can be fine tuned based on the cost of losing data. I usually give up a little performance for data robustness unless data can be lost with minimal business cost. I usually use the journalling option. Use replica pairs or a slave. I favor using MongoDB for rapid prototyping and research. I use the right tool for each job. PostgreSQL, va...

I have been running 1.7.5 on my laptop and just upgraded to 1.8 stable. While the normal way to run MongoDB (at least in my work) is to use read-only slaves for analytics, etc., I am still glad to see the single server robustness changes, including optional journaling. I also noticed that in the admin shell, showing databases provides database size estimates. Another useful change is replica set authentication using identical key files that are placed on each server. You then let one server know about the others (as before). You can read about other improvements here .

In my work for customers in recent years almost everything that I do uses PostgreSQL (sometimes PostGIS) and/or MongoDB. (I write a lot about the Semantic Web but so far no one has paid me to work on a project with an RDF data store like Sesame or AllegroGraph.) While I think PostgreSQL and MongoDB are great, their replication stories have not been great. MongoDB's master/slave and replica pairs work OK, and replica sets (MongoDB 1.6 and above) look to be a big improvement (it only takes a few minutes to try the MongoDB 1.6.x replica set tutorial example; follow the instructions .) I have not tried replica sets yet in a production environment but I am looking forward to it! I find MongoDB to be extremely developer friendly with convenient client libraires in Clojure and Ruby (I don't like dealing with JSON data and hashes in Java). PostgreSQL 9 replication is easier to set up and administer than Slony but I have not had to use it in production. The replication supports m...

I have been using MongoDB for about a year for customer jobs and my own work and I have a few practices that are worth sharing: I use two levels of backup and vary the details according to how important or replaceable the data is: I like to perform rolling backups to S3 periodically. This is easy enough to do using cron , putting something like this in crontab : 5 16 * * 2 (cd /mnt/temp; rm -f -r *.dump*; /usr/local/mongodb/bin/mongodump -o myproject_tuesday.dump > /mnt/temp/mongodump.log; /usr/bin/zip -9 -r myproject_tuesday.dump.zip myproject_tuesday.dump > /mnt/temp/zip.log; /usr/bin/s3cmd put myproject_tuesday.dump.zip s3://mymongodbbackups) The other level of backup is to always run at least one master and one read-only slave. By design, the preferred method for robustness is replicating mongod processes on multiple physical services. Choose master/slave or replica set installations, but don't run just a single mongod. I often need to do a lot of read operations for ...

No original material here, I just wanted to link some else's cool article on using mongosniff to watch all network traffic going into and out of a mongod process. The output format is easy to read and useful.

I wrote a few days ago about my Clojure and Compojure setup that automatically reloads modified files while I am developing. I have added support for accessing MongoDB using the congomongo library. My new project.clj file: (defproject kbsportal "0.1.0" :description "test using Compojure for KBSportal.com" :dependencies [[compojure "0.4.0-SNAPSHOT"] [ring/ring-devel "0.2.0-RC2"] [ring/ring-httpcore-adapter "0.2.0-RC2"] [ring/ring-jetty-adapter "0.2.0-RC2"] [ring/ring-servlet "0.2.0-RC2"] [org.clojars.liebke/congomongo "1.0.0"]] :main kbsportal) My Compojure setup file kbsportal.clj: (ns kbsportal (:use compojure.core ring.adapter.jetty) (:use ring.middleware.reload) (:use ring.middleware.stacktrace) (:use somnium.congomongo) (:use mongo) (:use nlp)) ;; set up test use of congomongo + MongoDB: (mongo! :db "notes", :host "127.0.0.1"...

After I finish up some client work this morning, I am planning on finishing a DevX article on using Heroku as a deployment platform. Since deploying to Heroku is so simple and so well documented, you might think that I would have a difficult time writing new material :-) After a short tutorial on getting started, I am writing mostly about using both CouchDB and MongoDB as data store, either hosted yourself on EC2 (or another server external to Heroku, which is itself hosted on EC2) or commercial managed solutions like Cloudant for CouchDB and MongoHQ for a managed MongoDB service. I like to manage my own and customer deployments on EC2 - frankly, it is fun :-) That said, I think that there are sometimes business reasons for using hosted solutions like Heroku, Cloudant, and MongoHQ. It is a balance between development and admin costs and paying for managed platform as a service offerings.

I have been spoiled by great support for indexing and search in relational databases (e.g., Sphinx, native search in PostgreSQL and MySQL, etc.) I was pleased to discover, after a little bit of hacking this morning, how easy it is to do indexing and search using the MongoDB document-centered database. I have two common use cases for search, and MongoDB seems to handle both of them fairly well: Search for words inside of text fields Efficient word prefix search to support AJAX "suggest" style lists My approach does require combining search results for multiple search terms in application code, but that is OK. Assuming the use of MongoRecord, here is a code snippet: class Recipe collection_name :recipes fields :name, :directions, :words def to_s "recipe: #{name} directions: #{directions[0..20]}..." end def Recipe.make collection, name, directions collection.insert({:_id => Mongo::ObjectID.new, :name => name, :directions =...

I spend a lot of time experimenting with infrastructure software, sometimes for customer jobs and sometimes just because it is fun to learn new things. For non-SQL data stores, I have spent a lot of time in the last year experimenting with and using CouchDB, AppEngine datastore, Tokyo Cabinet, MongoDB, Cassandra, and SimpleDB. Tokyo Cabinet and SimpleDB store hash values as strings, and don't have the great client APIs that the others have because limitations in string-only hash values. That said, for an Amazon hosted application SimpleDB can be a good choice and Tokyo Cabinet is light weight and easy to install and use. Casandra looks great, and as I have written about here before , Cassandra is easy to use from ruby and has great features. MongoDB has great performance and similar capabilities as Casandra. Chris Kampmeier has a great writeup that covers installing MongoDB on OS X, including setting it up as a system service. I followed Chris's directions. A pleasant surprise...