Performance Tips: MongoDB at Firescope
Guest post by Pete Whitney
Starting to work with any new technology or new API is always challenging at first. You’re often not quite sure of the best ways to get things done or if you’re are using the new technology in the most efficient manner. Furthermore, the early learning process is often littered with trial and error improvements that unfortunately take time to rework and reengineer into more optimal solutions. It sure would be nice if we could short circuit this learning process and simply arrive at nirvana on the first cut. While I won’t proclaim that the destination of the blog is nirvana, I will try to short circuit the learning process by sharing four specific performance related tips that we learned at FireScope Inc. when we transitioned from MySQL to MongoDB for our improved cloud based Stratis product. This blog will share the shorthand version of these tips and point the reader to a more in depth rendering if further understanding is desired.
- Through a comparative analysis FireScope found that accessing MongoDB via the MongoDB java driver was three times faster than doing the same access using SpringData. While SpringData yields many benefits it accomplishes its job using a reflection based solution that is performed on top of the native MongoDB java driver. So for FireScope’s performance centric considerations paying a 3X performance penalty for its benefits was not a tradeoff we were willing to make.
- When retrieving (querying) for a document consider returning only the fields that are needed to fulfill the current use case. In our analysis FireScope found that using this approach delivered an astounding nine times (9X) performance improvement.
- Aggregate data via nesting as much as makes sense for your application. By aggregating data, in particular historical related data, the future access of this data is improved because the accessed data, due to nesting, is always proximally close. Also index size can often be significantly reduced by aggregating historical data due to a reduction in the number of entries in the index. Smaller indexes yield smaller memory footprint, and faster index access times.
- When possible allocate documents early with the appropriate amount of space and update them later. If your updates do not change the size of the document than the document will not be moved. If the document is not moved then index updates are not required. This approach provides that most optimal approach for document creation with subsequent updates.
As noted earlier these are the shorthand tips. If you are interested in learning more about the research and analysis that produced these recommendations, you can read the following article on real-world application performance with MongoDB.
- Learn more about SpringData
- Learn more about FireScope Inc.
Pete serves as Vice President of Cloud Development at FireScope Inc. Pete’s primary role at FireScope is overseeing the architecture and development of FireScope Stratis and ensuring that our product line is the envy of the IT world. The architectural cornerstones of the Stratis product are unlimited scalability, built in redundancy, and no single point of failure. In the advertising industry Pete designed and delivered DG Fastchannel’s internet based advertising distribution architecture. Pete also excelled in other areas including design enhancements in robotic machine vision systems for FSI International Inc. These enhancements included mathematical changes for improved accuracy, improved speed, and automated calibration. Pete also designed a narrow spectrum light source, and a narrow spectrum band pass camera filter for controlled machine vision imaging. Pete graduated Cum Laude from the University of Texas at Dallas, and holds a Bachelor’s of Science in Computer Science. Pete can be contacted via Email at pwhitney@firescope.com.
