Archive | MongoDB RSS feed for this section

MongoDB driver tips & tricks: Mongoose

Many of the support requests we get at MongoLab are questions about how to properly configure and use particular MongoDB drivers and client libraries.

This blog post is the 2nd of a series where we are covering the popular MongoDB drivers in depth (we covered Mongoid last time). The driver we’re covering today is Mongoose, which is maintained by Aaron Heckmann (@aaronheckmann) and officially supported by MongoDB, Inc. Continue Reading →

MongoDB driver tips & tricks: Mongoid 3

Many of the support requests we get at MongoLab are questions about how to properly configure and use particular MongoDB drivers.

This blog post is the first of a series where we plan to cover each of the major MongoDB drivers in depth. The driver we’ll be covering today is Mongoid, developed by Durran Jordan (@modetojoy). Continue Reading →

{ "comments": 1 }

Finding and terminating long-running operations in MongoDB

When your MongoDB becomes unresponsive, it’s imperative that you can quickly identify the cause.

Although there can be many reasons for unresponsiveness, we sometimes find that particularly long-running and/or blocking operations (either initiated by a human or an application) are the culprit. Some examples of common operations that can bog down the database are:

  • operations on unindexed fields

  • index builds

  • expensive map-reduce jobs

One way to quickly see if one or more operations are particularly long-running is to use db.currentOp().

Continue Reading →

Managing disk space in MongoDB

In our previous post on MongoDB storage structure and dbStats metrics, we covered how MongoDB stores data and the differences between the dataSize, storageSize and fileSize metrics. We can now apply this knowledge to evaluate strategies for re-using MongoDB disk space.

When documents or collections are deleted, empty record blocks within data files arise. MongoDB attempts to reuse this space when possible, but it will never return this space to the file system. This behavior explains why fileSize never decreases despite deletes on a database.

If your app frequently deletes or if your fileSize is significantly larger than the size of your data plus indexes, you can use one of the methods below reclaim free space. Continue Reading →

{ "comments": 3 }

How big is your MongoDB?

As your MongoDB grows in size, information from the db.stats() diagnostic command (or the database “Stats” tab in our management portal) becomes increasingly helpful for evaluating hardware requirements.

We frequently get questions about the dataSize, storageSize and fileSize metrics, so we want to help developers better understand how MongoDB storage works and what these particular metrics mean.

Continue Reading →

{ "comments": 4 }

Tuning MongoDB Performance with MMS

At MongoLab we manage thousands of MongoDB clusters and regularly help customers optimize system performance. Some of the best tools available for gaining insight into our MongoDB deployments are the monitoring features of MongoDB Management Service (MMS). MMS allows us to quickly determine the health of a MongoDB system and identify the root cause of performance issues. This post covers our general approach to using MMS and MongoDB log files and provides techniques to help you optimize your own MongoDB deployment, whether you’re in the cloud or on your own hardware.

First, we will define the key metrics that we use to guide any performance investigation. Then we will go through the various combinations of metric values, discuss what they mean, and explore how to address the problems they indicate.

Continue Reading →

{ "comments": 2 }

MongoDB 2.4 now available on all MongoLab plans

Greetings, mongoers!

The team here at MongoLab is very excited to announce that version 2.4 of MongoDB is now available for all of our plans!

What about current databases, you might ask? Users will be receiving an email sometime this week containing everything they need to know about the upgrade process. Keep your eyes posted on your inboxes!

Continue Reading →

{ "comments": 5 }

Build your own lead capture page with Meteor and MongoDB in minutes

This is a guest blog post written by Niall O’Higgins and Peter Braden at Frozen Ridge, a full-stack web consultancy offering services around databases, node.js, testing & continuous deployment, mobile web and more. They can be contacted at

Meteor is a framework for building real-time client-server applications in JavaScript. It is build from the ground up to work with MongoDB – a JSON database which gives you storage that’s idiomatic for JavaScript.

We were incredibly impressed with how easy it is to write apps with Meteor using MongoLab as our MongoDB provider. With less that 100 lines of Javascript code we were able to build a fully-functioning newsletter signup application, and with MongoLab we don’t have to think about database management or hosting.

To demonstrate Meteor working with MongoLab, we’ll walk you though building a lead capture web application.

Since MongoDB is a document-oriented database, it is very easy to modify the application to store any data you want. In our example, we are building this as an email newsletter signup system. However, you could just as easily make this into a very simple CRM by capturing additional fields like phone number, full name etc.

Overview of our newsletter signup app

Our newsletter signup app will consist of two views:

  • A user-facing landing page for people to enter their email address
  • An internal-facing page with tabular display of signups and other metadata such as timestamp, referrer, etc.

You can grab the complete source to the finished newsletter signup app on Github here and view a fully-functional, running example of the application here.

Create the Meteor app

First install Meteor:

> curl | sh

Once Meteor is on your system, you can create an app called “app” with the command:

> meteor create app

Now you will have a directory named app which contains files app.jsapp.css and app.html.

Landing page template

First we need a nice HTML landing page. In the Meteor app you just created, your templates are stored in app.html. At the moment, Meteor only supports handlebars for templating.

It’s worth noting that everything must be specified in template tags, as Meteor will render everything else immediately. This enforces thinking of your app as a series of views rather than a series of pages.

Let’s look at an example from our finished app to illustrate. We have a “main” template which looks like this:

Data is bound from client-side code to templates through the Meteor template API.

Hence, the variable showAdmin is actually bound to the return value of the JavaScript functionTemplate.main.showAdmin in the client-side code. In our app.js, the implementation is as follows:

Due to Meteor’s data bindings, when the session variable “showAdmin” is set to true, the “admin” template will be rendered. Otherwise, the “signup” template will be rendered. Meteor doesn’t have to be explicitly told to switch the views – it will update automatically when the value changes.

This brings us to the client-side code.

Client-side code

Since Meteor shares code between the client and the server, both client and server code are contained in app.js. We can add client specific code by testing Meteor.isClient:

Inserting data on form submit

For the user-facing landing page, we merely need to insert data into the MongoDB collection when the form is submitted. We thus bind to the form’s submit event in the “signup” template and check to see if the email appears to be valid, and if so, we insert it into the data model:

One of the nice things about Meteor is that the client and server side data model API’s are the same.  If we insert the data here in the client, it is transparently synced with the server and persisted to MongoDB.

This is very powerful. Because we can use any MongoDB client to also connect directly to the database, we can easily use this data from other parts of our system. For example,  we can later link-up mailmerge software to make use of our database of emails to send newsletters.

Adding authentication

Now that we’ve got our newsletter signup form working, we will want the ability to see a list of emails in the database. However, because this is sensitive information, we don’t want it to be publicly visible. We only want a select list of authenticated users to be able to see it.

Fortunately, Meteor makes it easy to add authentication to your application. For demonstration purposes, we piggy-back off our Github accounts via OAuth2. We don’t want to create additional passwords just to view newsletter signups. Instead, we’ll consider a hardcoded list of Github usernames to view the admin page:

Meteor makes it very easy to add a “login with Github” UI flow to your application with the accounts and accounts-ui packages. You can add these with the command:

> meteor add accounts-ui accounts-github

Once these are added to your app, you can render a “login with Github” button in your templates by adding the special template variable {{loginButtons}}. For example in our finished app we have:

Email list view

The data display table is simply a handlebars table that we’ll populate with data from the database. Meteor likes to live-update data, which means if you specify your templates in terms of data accessors, when the underlying data changes, the DOM will automatically reflect the changes:

This is a pretty different approach to typical frameworks where you have to manually specify when a view needs to refresh.

We also make it possible for admin users to toggle the display of the email list in the app by inverting the value of the ‘showAdmin’ Meteor session variable:

Server-side code

Meteor makes it super easy to handle the server-side component and marshalling data between MongoDB and the browser. Our newsletter signup simply has to publish the signups collection for the data display view to be notified of its contents and it will update the view in real-time.

The entire server-side component of our Meteor application consists of:

With a unified data model between client and server, Meteor.publish is how you make certain sets of server-side data available to clients. In our case, we wish to make the Github username available in the current user object. We also only wish to publish the emails collection to admin users for security reasons.

Bundling the Meteor app

For deployment, Meteor apps can be translated to Node.JS applications using the meteor bundle command. This will output a tarball archive. To run this application, uncompress it and install its only dependency – fibers.

Fibers can be installed with the command

> npm install fibers

Deploying the Meteor app with MongoLab

Now your Meteor application is ready to run. There are a number of configuration options which can be set at start-time via UNIX environment variables. This is where we specify which MongoDB database to use. MongoLab is a great choice, taking a lot of the hassle out of running and managing your database, with a nice free Sandbox plan that you can create in seconds here.

In order to have you Meteor application persist data to your MongoLab database, set the MONGO_URL environment variable to the MongoDB URI provided by MongoLab for your database:

> export MONGO_URL=mongodb://

For Meteor to correctly set up authentication with Github, you need to set the ROOT_URL environment variable:

> export ROOT_URL=http://localhost:8080

To run your Meteor application on port 8080, simply execute main.js:

> PORT=8080 node main.js

You should now be able to connect to it at http://localhost:8080!

{ "comments": 1 }