This Week in MongoDB Nov 25-Dec 1

Amy Berman
November 25, 2013 | Updated: May 22, 2015
#Company

Here's what's going on in the MongoDB community this week:

Learn More

Events this Week:

Upcoming Events:

← Previous

Employee Profile: Barrie Segal

As part of a series showcasing our wonderful employees, we're featuring interviews each week, structured as a light Q&A. Last time you met Brendan Coleman , our director of Business Development. This week we're introducing you to Barrie Segal, the Project Manager for the Development Experience team. What is your role at MongoDB? I started off as a Support Engineer. Now I’m the Project Manager for the Developer Experience team, which is comprised of our nine drivers, the documentation team and the internal tools team, which totals around 35 people. I’m also temporarily moonlighting as a PM for the MMS team right now. Where were you before MongoDB? Why did you choose to come to MongoDB? I was at Columbia University’s School of General Studies, studying Economics and Sustainable Development. I learned about MongoDB through a friend who founded a company that used it as their datastore. He took me to the MongoDB 2.0 launch party, where I met Eliot and some other members of the team. I had a chance to talk to them and walked away fascinated by the team and the product. Eliot invited me to come interview and the rest is history. How has your role evolved at MongoDB? As a Support Engineer, I started off focusing on our community support channels , learned a lot from shadowing and training, and eventually started working with customers. A year later I became Project Manager of the Developer Experience team. What’s your hometown? I grew up in New Haven, Connecticut, and then my family immigrated to The Netherlands in the middle of my Junior year of high school. It was a crazy move (literally) but like most teenagers I didn’t need a lot of convincing to move to Amsterdam. Since moving back to NYC the things I miss the most are the canals, bitterballen, anything from FEBO, and cruising around on my bike. Citibike is great here but I still feel like every bike ride through NYC might be my last. Did you have previous experience using MongoDB before you arrived? If so, how are things different now that you work at MongoDB? If not, how did you learn MongoDB and how was the education process? Similar to many others who started around the same time, I had no experience with MongoDB. I learned through a combination of trial and error, and exploiting the infinite patience of my coworkers, who answered all of my many questions (thanks, guys). The reality is, MongoDB is constantly changing, so we’re all constantly learning. This keeps everyone humble, curious and always willing to teach others. Have you had any personal projects where you’ve used MongoDB? I’m working on a weightlifting application that allows me to spend less time tracking workouts on my phone at the gym. Bike or public transportation to work? Subway. What’s a typical day (or week) for you? Wake up at 7 am, take my imaginary standard poodle on an imaginary walk. At the risk of sounding cheesy or insane, I actually really love working by Times Square and walking through it every morning. Once I get to the office I check my calendar and task list for the day and map certain tasks to blocks of time between meetings. I’m a big fan of Lifehacker’s How I Work Series and will usually consult this for tips under the guise of ‘research’. Right now the kernel team is working on a new version of the server, so my main focus is making sure all of our drivers and documentation are ready to go at the same time. On any given day we’ve got about a third of the team working with customers or giving a talk at a conference, so I also spend a great deal of time coordinating across the other teams. After work it’s usually the gym, dance class or a show. Last week I got to see the Hagen Quartet perform some of Beethoven’s String Quartets on the Upper East Side and during intermission two senior citizens got into a fight over a cell phone and security had to break them up. That’s not a typical day though, at least for me. Maybe it was for them. What do you love most about MongoDB? I love working on a product that fulfills a real need, at a company that, despite its rapid growth, still feels small. Also, by virtue of being PM for so many different projects, I get to work across many different teams and see how different parts of the organization work. What’s the most challenging project here at MongoDB that you’ve worked on, and how did you succeed? I arrived on the support team at a critical moment-- there were only two dedicated Support Engineers and the rest of the work was handled by the kernel and driver engineers (this was BC, Before Cloud), and there was an immediate need to grow the dedicated support team and gracefully transition the responsibilities away from the other engineers. We built the process and the team from scratch. By the end of my year we went from 2 Support Engineers in the US to 15 dedicated Support Engineers across 3 continents. What’s the most rewarding experience you’ve had working here so far? Seeing the Sydney and Dublin offices come online, meaning we had MongoDB support in every time zone. What it really meant was that our entire customer base had all the support they needed and the US engineers could sleep through the night. What’s your favorite Seamless lunch order? Whatever someone else orders for me. I have bad taste. Name one secret skill you have, unrelated to work. Positioning myself on the subway platform in front of where the doors will open. Kindle or book? What’s your favorite book? Kindle Paperwhite without a doubt. My favorite book is “The Moon is a Harsh Mistress” by Robert Heinlein. Describe your perfect weekend. One that is loosely planned (if at all). If a song played when you walked into the office every day, what would it be? Black Box - Ride on Time Leave us with a YouTube video. This is one of my favorites.

November 21, 2013
Next →

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 .

May 31, 2023