MongoDB 3.0 with WiredTiger introduces a new feature called ‘Index prefix compression’ which greatly reduces the memory consumed by the indexes. Less memory used by indexes means more memory for document storage or other indexes which implies better performance.
MongoDB 3.0 with the wired tiger storage engine enables you to transparently compress the data stored in your database. This is a fairly exciting and useful feature that can be used to reduce the disk space usage of your fast growing data. By default wired tiger uses the ‘Snappy’ block compression engine for all the collections. You can turn off compression by default using the following options in the mongodb server config file .
MongoDirector supports SSL configuration for MongoDB. Configuring and setting it up is easy and our earlier post talks all about it. It also discusses the need and pros and cons of MongoDB with TLS/SSL.
MongoDirector currently uses self signed certificates for SSL when creating nodes for a new cluster. Since Node.js applications over the MongoDB Node.js driver or Mongoose are very popular choices on our platform, in this post we discuss a step by step plan to workaround most common issues faced in using MongoDB SSL with self signed certificates in Node.js. This discussion pertains to the MongoDB Node.js version 2.0 and Mongoose version 4.0.3.
While talking about system performance characteristics, most DBaaS providers limit themselves to providing information about the hardware that their systems are provisioned on. Indeed, it is hard to talk accurately about the actual throughput/latency characteristics of a cloud based deployment given the number of variables in such a system. Virtualized environments, unpredictable workloads, network latencies, different geographies are only some of the considerations.
However it is a good idea to have a fair understanding of the actual performance of your Mongodb deployment: so that you can provision accurately based on your application needs; so that you can actually compare various DBaaS providers to ensure that you are getting the most “bang for the buck”.
Everybody claims to be fast – but our fast is faster! Over the past few weeks our team has been busy benchmarking our systems on Azure and the results have been fantastic.
Earlier this year before we ported our existing infrastructure from AWS to Azure, we spent a lot of time understanding the structure of the Azure cloud and optimizing for best performance. The reality is that Azure is fairly different from AWS and the performance strategy that works on one cloud probably will not work on the other. Our development team did a lot of custom work over the disk architecture that we use in our clusters – the goal was to provide the best disk performance on Azure.
You have chosen MongoDB as your application database. You probably have a lot of production data in your database already. Now you need to make a major change to your application. How do you go about testing to make sure the new version of your application behaves well with your production data?
Production data is always infinitely more varied that your test data and exercises more edge cases consequently leading to more bugs. It is not recommend to export production data into your test environment due to policy, privacy & security issues. On the other hand it is fairly difficult and expensive to identify and test bugs in production. So how do you go about ensuring that the new version of your application works well with production data? Here is what we recommend at MongoDirector
Azure is now a popular platform to deploy and manage MongoDB servers. Once you have chosen Azure as the platform for MongoDB one of the first decisions that you need to make is to select the instance type that you need to deploy. In this matter Azure fortunately is much simpler than AWS . Azure basically offers three types of instances
1. A series
A series offers general purpose instances that fit most workloads. They are available in various sizes ranging from 0.75 GB to 56 GB. Inside A series you are offered two options – ‘Basic’ and ‘Standard’. The ‘Basic’ version costs less but does not offer load balancing, auto-scaling etc. From a database perspective the most important difference is that with ‘Basic’ instances your azures disks (page blobs) are limited to to 300 IOPS/disk whereas with ‘Standard’ instances you can go upto 500 IOPS/disk. This can make a big difference especially with larger instances when you can RAID the disks. Our recommendation is to use ‘Standard’ machines whenever possible to leverage the enhanced I/O. The number of disks that can be attached to a VM depends on the size of the VM. You can go upto 16 disks for A7 machine. More details can be found here – Virtual machine sizes for Azure.
MongoDB Security has been in the news this week for all the wrong reasons. All the talk has been about the 40,000 or so databases that were found exposed by a group of students based in Germany. Some of the databases even contained production data. It’s egregious on several levels – not only do you have production data on a unauthenticated database but it is also left open to the internet. The only surprising thing is that it took this long to get exposed. If you don’t want your mongodb servers to be on the news here are three simple steps to improve the security of your mongodb installation
Performance is an important consideration when deploying MongoDB on the EC2 platform. From a hardware perspective MongoDB performance on EC2 is gated primarily by two factors – RAM and disk speed. Typically ( there are always exceptions) CPU should not be an issue. Memory is no longer a issue – there are plenty of size options (R3, I2, C3/C4) offering a large amount of RAM. For more details on how to choose the right instance type check my other blog post – “How to choose the right EC2 Instance type“.