US Department Of Veterans Affairs Goes From Wire Frame To Production App In Weeks, Not Months Or Years, With MongoDB
June 27, 2014 | Updated: April 28, 2016
#case study#MongoDB World Old#Business
Would it surprise you that one of the biggest open-source software shops in the world, in fact one of the biggest NoSQL shops in the world, resides in the U.S. government?
The Department of Veterans Affairs has more than 20 million primary customers and a $3.4B annual IT budget with 400,000 users and over 5,000 applications. The VA turned to MongoDB to unlock enterprise services with a schema agnostic enterprise CRUD (eCRUD) service.
Previously, the VA was paying millions of dollars to lock away data in relational databases and millions more to get it back out.
“It just didn’t make sense,” said Joe Paiva, Chief Technology Strategist at the U.S. Department of Veteran Affairs. “We realized early on we could never build all the apps that people want. We wanted to go from wire frame to app much, much faster.”
In order to get there, the VA used MongoDB as one logical, federated data store for all of its different types of data. Now, people can freely code as long as they know how to do an AJAX web services call.
“You can say you’re agile, that you’re incremental, but when you need change, you need all the change!" said Paiva.
With MongoDB, they achieved just that. The VA had the first version of the service up and running in weeks. “It was that fast,” said Paiva.
Through this effort, the VA has been able to provide efficiency and enhanced information agility. Plus, it has increased security by consolidating data under standardized enterprise controls… all in the name of keeping costs low while better serving a greater number of veterans.
To see all MongoDB World presentations, visit the [MongoDB World Presentations](https://www.mongodb.com/mongodb-world/presentations) page.
Eliot Horowitz: Making MongoDB Dramatically Faster, Much More Pluggable And Easier To Scale
As MongoDB has evolved over the past seven years, three design principles have guided its development: Developer Productivity - Never do anything that slows developer productivity and always seek to improve it; Horizontal Scalability - MongoDB development should always maximize scalability; and Operational Scalability - It should be as easy to manage 1,000 MongoDB servers as it is to manage one While much of the market focuses on #2, the reality is that horizontal scalability is mere table stakes for a modern database, and MongoDB has it in spades . No other database can boast as many 50+-node deployments as MongoDB, or even come close. With hundreds of thousands of deployments, ranging from a single node on a laptop to 1,000+ node clusters, MongoDB scales better than any other database. But horizontal scale, again, isn't the most interesting problem. Maximizing developer and operations productivity is, and this week at MongoDB World Eliot Horowitz, MongoDB co-founder and CTO, took to the stage to reveal big improvements to MongoDB that will excite developers and operations equally. (You can watch the full video of the keynote here .) While Eliot has blogged about the imminent arrival of document-level locking, pluggable storage and automated management of MongoDB, this was the first time the company has offered a live demo of each. Concurrency Over the last seven years we’ve made a lot of improvements, but we’re still improving it. Despite these improvements, Eliot humorously pointed out a definition of concurrency that says "Cooperative time sharing at database level using knowledge about file system cache to avoid locking around disk access" but reads like "database-level locking" to many in the MongoDB community. No more. On stage Eliot demoed document-level locking and indicated it will be ready in 2014. By making MongoDB's locking more granular, it's possible to allow more simultaneous writes to occur without locking up resources or hurting performance. In fact, Eliot commented that "we've easily seen a 10X speed increase” of MongoDB with the improvement, and that’s just on a pre-release beta build running on a standard desktop machine. On better hardware the improvements should be even more significant. Even better, Eliot noted that MongoDB will it will be a "textbook implementation that will be familiar to relational database engineers." Pluggable Storage MongoDB's storage engine has served the community well for seven years. But with hundreds of thousands of MongoDB deployments come a myriad of different use cases and work loads, and no single storage engine that perfectly fits all of them. As such Eliot announced a new pluggable storage API that allows developers to choose the storage engine that best suits their workloads. And, importantly, the API will be detailed enough to support all MongoDB features, so that in developers' chase for performance their operations counterparts don't have to give up operational scalability. "When MongoDB 2.8 comes out," declared Eliot, "We think it’s important that you be able to add a new node to a replica set and try a new storage engine out that may be focused on security, performance or whatever you want. You could actually have a replica set with multiple storage engines: one optimized for BI workloads, one focused on compression, etc." With a range of different storage engines to choose from, Eliot pointed to a few likely places to start In-memory (MongoDB has already done this one) RocksDB (MongoDB has built a preliminary version of this one, too) InnoDB TokuKV FusionIO Automation It has always been possible to do rolling upgrades of MongoDB. It has also always been a bit harder than necessary. To make it easier, Eliot announced (and demoed) MMS Automation, a core component of the MongoDB Management Service (MMS) going forward. As the audience watched, Eliot provisioned and upgraded a 10-node cluster in a matter of minutes. The crowd cheered, and for good reason: suddenly MongoDB is as easy to administer as it is to develop. In other words, MongoDB just lowered the bar for greater adoption of its wildly popular database, even as it raised the bar for every other database that hopes to compete for today's workloads. Good luck with that. To see all MongoDB World presentations, visit the [MongoDB World Presentations](https://www.mongodb.com/mongodb-world/presentations) page.
How Edenlab Built a High-Load, Low-Code FHIR Server to Deliver Healthcare for 40 Million Plus Patients
The Kodjin FHIR server has speed and scale in its DNA. Edenlab, the Ukrainian company behind Kodjin , built our original FHIR solution to digitize and service the entire Ukrainian national health system. The learnings and technologies from that project informed our development of the Kodjin FHIR server. At Edenlab, we have always been driven by our passion for building solutions that excel in speed and scale. With Kodjin, we have embraced a modern tech stack to deliver unparalleled performance that can handle the demands of large-scale healthcare systems, providing efficient data management and seamless interoperability. Eugene Yesakov, Solution Architect, Author of Kodjin Built for speed and scale While most healthcare projects involve handling large volumes of data, including patient records, medical images, and sensor data, the Kodjin FHIR server is based on a system developed to handle tens of millions of patient records and thousands of requests per second, to ensure timely access and efficient decision-making for a population of over 40 million people. And all of this information had to be processed and exchanged in real-time or near real-time, without delays or bottlenecks. This article will explore some of the architectural decisions the Edenlab team took when building Kodjin, specifically the role MongoDB played in enhancing performance and ensuring scalability. We will examine the benefits of leveraging MongoDB's scalability, flexibility, and robust querying capabilities, as well as its ability to handle the increasing velocity and volume of healthcare data without compromising performance. About Kodjin FHIR server Kodjin is an ONC-certified and HIPAA-compliant FHIR Server that offers hassle-free healthcare data management. It has been designed to meet the growing demands of healthcare projects, allowing for the efficient handling of increasing data volumes and concurrent requests. Its architecture, built on a horizontally scalable microservices approach, utilizes cutting-edge technologies such as the Rust programming language, MongoDB, ElasticSearch, Kafka, and Kubernetes. These technologies enable Kodjin to provide users with a low-code approach while harnessing the full potential of the FHIR specification. A deeper dive into the architecture approach - the role of MongoDB in Kodjin When deciding on the technology stack for the Kodjin FHIR Server, the Edenlab team knew that a document database would be required to serve as a transactional data store. In an FHIR Server, a transactional data store ensures that data operations occur in an atomic and consistent manner, allowing for the integrity and reliability of the data. Document databases are well-suited for this purpose as they provide a flexible schema and allow for storing complex data structures, such as those found in FHIR data. FHIR resources are represented in a hierarchical structure and can be quite intricate, with nested elements and relationships. Document databases, like MongoDB, excel at handling such complex and hierarchical data structures, making them an ideal choice for storing FHIR data. In addition to supporting document storage, the Edenlab team needed the chosen database to provide transactional capabilities for FHIR data operations. FHIR transactions, which encompass a set of related data operations that should either succeed or fail as a whole, are essential for maintaining data consistency and integrity. They can also be used to roll back changes if any part of the transaction fails. MongoDB provides support for multi-document transactions , enabling atomic operations across multiple documents within a single transaction. This aligns well with the transactional requirements of FHIR data and ensures data consistency in Kodjin. Implementation of GridFS as a storage for the terminologies in Terminology service Terminology service plays a vital role in FHIR projects, requiring a reliable and efficient storage solution for terminologies used. Kodjin employs GridFS , a file system within MongoDB designed for storing large files, which makes it ideal to handle terminologies. GridFS offers a convenient way to store and manage terminology files, ensuring easy accessibility and seamless integration within the FHIR ecosystem. By utilizing MongoDB's GridFS, Kodjin ensures efficient storage and retrieval of terminologies, enhancing the overall functionality of the terminology service. Kodjin FHIR server performance To evaluate the efficiency and responsiveness of the Kodjin FHIR server in various scenarios we conducted multiple performance tests using Locust, an open-source load testing tool. One of the performance metrics measured was the retrieval of resources by their unique ids using the GET by ID operation. Kodjin with MongoDB achieved a performance of 1721.8 requests per second (RPS) for this operation. This indicates that the server can efficiently retrieve specific resources, enabling quick access to desired data. The search operation, which involves querying ElasticSearch to obtain the ids of the searched resources and retrieving them from MongoDB, exhibited a performance of 1896.4 RPS. This highlights the effectiveness of polyglot persistence in Kodjin, leveraging ElasticSearch for fast and efficient search queries and MongoDB for resource retrieval. The system demonstrated its ability to process search queries and retrieve relevant results promptly. In terms of resource creation, Kodjin with MongoDB showed a performance of 1405.6 RPS for POST resource operations. This signifies that the system can effectively handle numerous resource-creation requests. The efficient processing and insertion of new resources into the MongoDB database ensure seamless data persistence and scalability. Overall, the performance tests confirm that Kodjin with MongoDB delivers efficient and responsive performance across various FHIR operations. The high RPS values obtained demonstrate the system's capability to handle significant workloads and provide timely access to resources through GET by ID, search, and POST operations. Conclusion Kodjin leverages a modern tech stack including Rust, Kafka, and Kubernetes to deliver the highest levels of performance. At the heart of Kodjin is MongoDB, which serves as a transactional data store. MongoDB's capabilities, such as multi-document transactions and flexible schema, ensure the integrity and consistency of FHIR data operations. The utilization of GridFS within MongoDB ensures efficient storage and retrieval of terminologies, optimizing the functionality of the Terminology service. To experience the power and potential of the Kodjin FHIR server firsthand, we invite you to contact the Edenlab team for a demo. For more information On MongoDB’s work in healthcare, and to understand why the world’s largest healthcare companies trust MongoDB, read our whitepaper on radical interoperability .