Microservices Expo Authors: Elizabeth White, Lori MacVittie, Derek Weeks, Liz McMillan, David Sprott

Related Topics: Java IoT, Microservices Expo, Open Source Cloud, IoT User Interface, @CloudExpo

Java IoT: Article

Real-World Application Performance with MongoDB

Choosing a data mapping technology

Recently FireScope Inc. introduced the general availability of its Stratis product. Stratis brings all of the FireScope Unify capabilities to the cloud, with the added advantage of a new architecture that delivers near infinite scalability. Moreover, the new Stratis architecture provides scalability at all application layers including its back-end operations, which were newly designed to leverage the benefits of MongoDB. In this article we will discuss several of the architecture choices that were made as part of this effort with the hope that others might benefit from the research and analysis that was performed to bring this product to market.

As background a functioning FireScope deployment has the ability to gather metrics from all forms of existing IT assets, normalize the gathered metrics, provide historical analysis of the metrics, and most importantly provide service views for worldwide operations which is unparalleled in the IT industry. In the early phases of designing the Stratis product, FireScope undertook significant research into the scalable persistence architectures that were production ready at the time of this effort. FireScope ultimately chose MongoDB for its ability to scale and its flexibility in supporting an easy transition from a relational persistence model to a NoSQL model. While researching MongoDB FireScope took the time to understand the application impact of the following architecture facets:

  1. Data mapping technologies
  2. Minimal field retrieval vs full document retrieval
  3. Data aggregation
  4. Early space allocation

In this article we detail each of the above mentioned research efforts and discuss the impact that our subsequent choices had on the FireScope Stratis product.

Application performance was a key driver in all research activities. Even though we were deploying these new application elements to the cloud, ignoring the importance of performance would mean more resources would be needed to get the job done. It's also worth noting that not all applications have the same considerations, so what may be an appropriate technology or architecture choice for FireScope Stratis might not be the appropriate choice for your application. With that said, let's address these research efforts in more detail.

Data Mapping Technologies
The FireScope Stratis application accesses persistent storage via Java, and PHP. As a result, we needed to make persistence access choices that would be compatible between Java and PHP. While Java and PHP were both requirements the main performance driven consideration was access via Java. In considering how to get information into and out of the database with Java, FireScope researched access using the following two approaches:

  1. Java Mongo driver with an in-house developed DAO layer
  2. Spring Data

We built narrowly focused prototype access solutions using both of these options. We saved and retrieved the same large graph of objects and compared the relative performance for each approach. One of the key findings in this analysis was the performance impact of "single binding" versus "double binding" of retrieved data.

When data is returned via the MongoDB Java driver each document is returned in the form of a HashMap where the fields of the persisted document form the keys of the HashMap and the corresponding values associated with each field are stored as HashMap values. FireScope designed its domain model to use getters and setters that simply accessed the appropriate field in the HashMap and ensured that each corresponding field has the correct Java type. In this model there is no additional overhead to bind each field to a corresponding Java field, we simply referenced the data in the HashMap. We refer to this model as "single binding" because the only binding performed is that of the Mongo Java driver.

By contrast, when Spring Data is used to render a document from MongoDB all fields in the HashMap returned by the Mongo Java driver are subsequently bound to a member field in the appropriate Java object. This binding is performed using reflection during the object retrieval process. We refer to this model as "double binding" because the initial HashMap rendering is then reflectively bound to the appropriate Java object fields and the initial HashMap is subsequently discarded.

In our comparative analysis we found that the "double binding" process used by Spring Data carried with it a performance overhead of greater than 2X but less than 4X. These comparative results were derived from multiple runs using each technology retrieving and saving the same large data graph on the same hardware. Furthermore, we alternated between technology choices in order to prevent differences in class loading, network, CPU, disk, and garbage collection from obscuring the analysis results.

Please do not take from the above that I have some issue with Spring Data. I absolutely love Spring, and nearly everything they do is 100% top notch! It just so happens that in this instance our performance-centric considerations directed us away from the use of Spring Data for FireScope's Stratis back-end operations. We do however use Spring in nearly every other area of the FireScope Stratis product. As a final thought, we also briefly considered the use of Morphia, but due to time constraints we never completed a comparative analysis using Morphia.

Minimal Field Retrieval
One of the key performance impacting areas of the FireScope Stratis product is the data normalization engine. Every metric retrieved by FireScope passes through this engine and as a result the ability to do more with less is critically important to FireScope. In an effort to verify our architecture choices, FireScope performed another analysis comparing the relative performance of retrieving all fields of a queried document to an alternative scenario where only one-fourth of the full fields were retrieved. The intent here is that many use cases do not need all of the data for a given object. Of course we knew that reducing the bandwidth between the database servers and the application servers would be a good thing, but being new to Mongo we weren't sure if the overhead of filtering some fields from the document would outweigh the benefits of the reduced bandwidth between the servers.

In this analysis we setup long running retrieve / save operations. Once again, we alternated between retrieve / save operations where the full document was passed, and retrieve / save operations where the one-fourth populated document was passed. Alternation was used to prevent the impact of class loading, network, CPU, disk, and garbage collection from obscuring the analysis results. When the one-fourth populated document was used we specified a set of fields for Mongo to retrieve. For the full document no field specification was provided and as a result the full document was retrieved.

The analysis results indicated an overwhelming 9X performance benefit to using limited field retrieval. But be aware that using limited field retrieval also has its downside. If other developers on your team are not keenly aware that the object they just queried for might not have all of its fields populated, then application defects can easily result from using this approach. To avert possible defects, FireScope leverages an extensive unit testing, functional testing, and peer review / test process to ensure that such defects do not arise.

Data Aggregation
A portion of the section is based on ideas from this blog.

We acknowledge and thank Foursquare Labs Inc. for its contributions.

The suggestion offered in the blog is to aggregate a series of historical entries into a single document, rather than creating a separate document for each historical record. The motivation for aggregation is to improve the locality of associated information and as a result improve its future access time. While the FireScope system performance is not driven by user access, it does rely extensively on aggregated historical metrics collected throughout a day and we leveraged aggregation to achieve improved locality.

What was not discussed in the Foursquare Labs blog was a second and equally significant benefit of aggregation which is a huge reduction in the size of an index for the FireScope historical records. For those not familiar with Mongo it is important to understand that Mongo attempts to keep all indexes in memory for fast access. As a result any reduction in the size of an index allows Mongo to keep more data in memory which improves overall system performance.

For better understanding consider the following two data storage scenarios where a reference id, time stamp, and value of several collected metrics are stored using two alternative approaches:

  1. Collected metrics are simply added to a collection which is indexed on the ref_id + time fields.
    { ref_id : ABC123, time : 1336780800, value : XXX }
    { ref_id : ABC123, time : 1336780800, value : ZZZ }
  2. All collected metrics for one day are added to an array. The document for the day is indexed on the ref_id and midnight fields.
    { ref_id : ABC123, midnight : 1336780800, values : [ time : 1336780805, value : XXX, ... ] }

Note that for option 1 both the ref_id and the time are two elements in an index. If the system collects this metric once every 5 minutes, then the system would collect 288 ref_id, time, value entries in one day. If each entry is added to an index then the corresponding index size will be significantly larger for option 1 above than for option 2, because option 2 does not index the actual collection time but only midnight of the current day. As a result, the index size is reduced nearly 300 to one due to the aggregation of data with no loss of information.

Early Space Allocation
If documents are created from metrics collected throughout the day, then both space allocation, as well as index updates are required throughout the day as a part of normal business operations. As discussed above if documents are nested then locality of accessed information is improved. But if normal operations append to an existing document then in most instances, the document must be moved and all associated indexes must be updated in order to accomplish the document append operations.

With FireScope Stratis optimal update operations are achieved by allocating a full days worth of history records for each expected metric. Each history record contains default values for the expected collection interval. The space for one day's worth of data is created in a scheduled operation that is run once per day. Then as metrics are collected throughout the day the appropriate bucket (array entry) is simply updated. Since the update does not change the size of the document no document movements are needed throughout the day nor are index updates needed. The end result is a system that achieves optimal performance. While I am unable to share actual performance metrics for this approach, I can share that the relative performance difference is significant. It is also worth noting that you would need to take great care in measuring the performance impact of this architecture choice because MongoDB has the inherent ability to queue update operations, thus masking the real performance benefit of this enhancement.

If you are undertaking a transition to MongoDB, or new development on MongoDB then choosing a data mapping technology wisely can have a significant impact on your application performance. Consider also the performance benefits of Minimal Field Retrieval, Data Aggregation, and Early Space Allocation as vehicles to optimize your applications' performance. You may also realize additional benefits, such as the reduced network bandwidth that comes with minimal field retrieval, and the reductions of index size that might result from data aggregation. We sincerely hope that you have benefited from the time invested in reading this article and wish you the best in all of your Mongo development endeavors.


More Stories By Pete Whitney

Pete Whitney is a Solutions Architect for Cloudera. His primary role at Cloudera is guiding and assisting Cloudera's clients through successful adoption of Cloudera's Enterprise Data Hub and surrounding technologies.

Previously Pete served as VP of Cloud Development for FireScope Inc. 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. He 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 BS in Computer Science. Pete can be contacted via Email at [email protected]

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

@MicroservicesExpo Stories
In case you haven’t heard, the new hotness in app architectures is serverless. Mainly restricted to cloud environments (Amazon Lambda, Google Cloud Functions, Microsoft Azure Functions) the general concept is that you don’t have to worry about anything but the small snippets of code (functions) you write to do something when something happens. That’s an event-driven model, by the way, that should be very familiar to anyone who has taken advantage of a programmable proxy to do app or API routing ...
More and more companies are looking to microservices as an architectural pattern for breaking apart applications into more manageable pieces so that agile teams can deliver new features quicker and more effectively. What this pattern has done more than anything to date is spark organizational transformations, setting the foundation for future application development. In practice, however, there are a number of considerations to make that go beyond simply “build, ship, and run,” which changes ho...
Analysis of 25,000 applications reveals 6.8% of packages/components used included known defects. Organizations standardizing on components between 2 - 3 years of age can decrease defect rates substantially. Open source and third-party packages/components live at the heart of high velocity software development organizations. Today, an average of 106 packages/components comprise 80 - 90% of a modern application, yet few organizations have visibility into what components are used where.
SYS-CON Events announced today that Enzu will exhibit at the 19th International Cloud Expo, which will take place on November 1–3, 2016, at the Santa Clara Convention Center in Santa Clara, CA. Enzu’s mission is to be the leading provider of enterprise cloud solutions worldwide. Enzu enables online businesses to use its IT infrastructure to their competitive advantage. By offering a suite of proven hosting and management services, Enzu wants companies to focus on the core of their online busine...
With emerging ideas, innovation, and talents, the lines between DevOps, release engineering, and even security are rapidly blurring. I invite you to sit down for a moment with Principle Consultant, J. Paul Reed, and listen to his take on what the intersection between these once individualized fields entails, and may even foreshadow.
In many organizations governance is still practiced by phase or stage gate peer review, and Agile projects are forced to accommodate, which leads to WaterScrumFall or worse. But governance criteria and policies are often very weak anyway, out of date or non-existent. Consequently governance is frequently a matter of opinion and experience, highly dependent upon the experience of individual reviewers. As we all know, a basic principle of Agile methods is delegation of responsibility, and ideally ...
Monitoring of Docker environments is challenging. Why? Because each container typically runs a single process, has its own environment, utilizes virtual networks, or has various methods of managing storage. Traditional monitoring solutions take metrics from each server and applications they run. These servers and applications running on them are typically very static, with very long uptimes. Docker deployments are different: a set of containers may run many applications, all sharing the resource...
When we talk about the impact of BYOD and BYOA and the Internet of Things, we often focus on the impact on data center architectures. That's because there will be an increasing need for authentication, for access control, for security, for application delivery as the number of potential endpoints (clients, devices, things) increases. That means scale in the data center. What we gloss over, what we skip, is that before any of these "things" ever makes a request to access an application it had to...
Virgil consists of an open-source encryption library, which implements Cryptographic Message Syntax (CMS) and Elliptic Curve Integrated Encryption Scheme (ECIES) (including RSA schema), a Key Management API, and a cloud-based Key Management Service (Virgil Keys). The Virgil Keys Service consists of a public key service and a private key escrow service. 

The best way to leverage your Cloud Expo presence as a sponsor and exhibitor is to plan your news announcements around our events. The press covering Cloud Expo and @ThingsExpo will have access to these releases and will amplify your news announcements. More than two dozen Cloud companies either set deals at our shows or have announced their mergers and acquisitions at Cloud Expo. Product announcements during our show provide your company with the most reach through our targeted audiences.
In his general session at 19th Cloud Expo, Manish Dixit, VP of Product and Engineering at Dice, will discuss how Dice leverages data insights and tools to help both tech professionals and recruiters better understand how skills relate to each other and which skills are in high demand using interactive visualizations and salary indicator tools to maximize earning potential. Manish Dixit is VP of Product and Engineering at Dice. As the leader of the Product, Engineering and Data Sciences team a...
SYS-CON Events announced today that eCube Systems, the leading provider of modern development tools and best practices for Continuous Integration on OpenVMS, will exhibit at SYS-CON's @DevOpsSummit at Cloud Expo New York, which will take place on June 7-9, 2016, at the Javits Center in New York City, NY. eCube Systems offers a family of middleware products and development tools that maximize return on technology investment by leveraging existing technical equity to meet evolving business needs. ...
Join Impiger for their featured webinar: ‘Cloud Computing: A Roadmap to Modern Software Delivery’ on November 10, 2016, at 12:00 pm CST. Very few companies have not experienced some impact to their IT delivery due to the evolution of cloud computing. This webinar is not about deciding whether you should entertain moving some or all of your IT to the cloud, but rather, a detailed look under the hood to help IT professionals understand how cloud adoption has evolved and what trends will impact th...
As we enter the final week before the 19th International Cloud Expo | @ThingsExpo in Santa Clara, CA, it's time for me to reflect on six big topics that will be important during the show. Hybrid Cloud This general-purpose term seems to provide a comfort zone for many enterprise IT managers. It sounds reassuring to be able to work with one of the major public-cloud providers like AWS or Microsoft Azure while still maintaining an on-site presence.
operations aren’t merging to become one discipline. Nor is operations simply going away. Rather, DevOps is leading software development and operations – together with other practices such as security – to collaborate and coexist with less overhead and conflict than in the past. In his session at @DevOpsSummit at 19th Cloud Expo, Gordon Haff, Red Hat Technology Evangelist, will discuss what modern operational practices look like in a world in which applications are more loosely coupled, are deve...
All clouds are not equal. To succeed in a DevOps context, organizations should plan to develop/deploy apps across a choice of on-premise and public clouds simultaneously depending on the business needs. This is where the concept of the Lean Cloud comes in - resting on the idea that you often need to relocate your app modules over their life cycles for both innovation and operational efficiency in the cloud. In his session at @DevOpsSummit at19th Cloud Expo, Valentin (Val) Bercovici, CTO of So...
DevOps is a term that comes full of controversy. A lot of people are on the bandwagon, while others are waiting for the term to jump the shark, and eventually go back to business as usual. Regardless of where you are along the specturm of loving or hating the term DevOps, one thing is certain. More and more people are using it to describe a system administrator who uses scripts, or tools like, Chef, Puppet or Ansible, in order to provision infrastructure. There is also usually an expectation of...
DevOps is speeding towards the IT world like a freight train and the hype around it is deafening. There is no reason to be afraid of this change as it is the natural reaction to the agile movement that revolutionized development just a few years ago. By definition, DevOps is the natural alignment of IT performance to business profitability. The relevance of this has yet to be quantified but it has been suggested that the route to the CEO’s chair will come from the IT leaders that successfully ma...
DevOps is being widely accepted (if not fully adopted) as essential in enterprise IT. But as Enterprise DevOps gains maturity, expands scope, and increases velocity, the need for data-driven decisions across teams becomes more acute. DevOps teams in any modern business must wrangle the ‘digital exhaust’ from the delivery toolchain, "pervasive" and "cognitive" computing, APIs and services, mobile devices and applications, the Internet of Things, and now even blockchain. In this power panel at @...
As software becomes more and more complex, we, as software developers, have been splitting up our code into smaller and smaller components. This is also true for the environment in which we run our code: going from bare metal, to VMs to the modern-day Cloud Native world of containers, schedulers and microservices. While we have figured out how to run containerized applications in the cloud using schedulers, we've yet to come up with a good solution to bridge the gap between getting your conta...