MongoDB and AXA France: Creating a Connected Homes Project

Mat Keep
August 22, 2016 | Updated: December 11, 2017
#Customer Stories#Business

The Internet of Things (IoT) is a transformative technology, touching all of our lives – in the workplace, in the gym, on the road, and in so many other places and contexts. But it’s in the home where the IoT is making some of its largest strides.

The concept of the smart, connected home is revolutionizing how we protect our families and most valuable personal assets – whether it’s from intruders, from fires and floods, through to environmental controls. Insurance companies have been quick to identify the opportunity smart homes present to them, and to their customers. By providing an “IoT Hub”, insurers can aggregate sensor data from multiple devices in the home to allow their customers complete control to defend, protect and monitor their families and property from a single user interface.

At this year’s MongoDB World customer conference, AXA France developers Guillaume Chervet and Vincent Gillot presented their connected homes project, built on MongoDB, node.js and the cloud. In their presentation, they discuss: - How they optimized schema design through multiple iterations to most efficiently represent customers, sensor data, and notifications - How they consume, process and alert against sensor events emitted within the same millisecond from multiple devices in a single connected home - How they use the MongoDB aggregation pipeline to analyse and report against sensor data. - How the move to MongoDB 3.2 has allowed them to simplify their application code. By taking advantage of new features such as document validation they are able to enforce structure over their IoT events schema; and the $lookup aggregation operator allows the team to JOIN data from multiple collections for richer analytics

Guillaume and Vincent shared how the development team had come from SQL Server and Oracle database backgrounds before working with MongoDB on this project. Selected quotes from the team included:

MongoDB is really easy to install, to configure. Its immediate ease of use impressed me.

Developing new features in agile with sprint modes is easier with a NoSQL database than with a relational database.

Querying system is rich, manipulating data in JSON becomes intuitive, and my algorithms are simpler!

View the slides to learn more about AXA’s connected home project with MongoDB

Download our IoT & Big Data whitepaper, co-authored with Bosch Software Innovations to learn more about the challenges presented by managing IoT data.

Download the white paper


*About the Author - Mat Keep

Mat is a director within the MongoDB product marketing team, responsible for building the vision, positioning and content for MongoDB’s products and services, including the analysis of market trends and customer requirements. Prior to MongoDB, Mat was director of product management at Oracle Corp. with responsibility for the MySQL database in web, telecoms, cloud and big data workloads. This followed a series of sales, business development and analyst / programmer positions with both technology vendors and end-user companies.*

← Previous

MongoDB and Stratio: Building an Operational Data Lake for One of Spain’s Largest Insurance Companies

MongoDB, Apache Spark, Zeppelin, Hadoop and Kafka Improve Customer Experience and Optimize Marketing ROI Data lakes are playing an increasingly critical role in modern enterprise data architectures. Providing a centralized repository to aggregate data from multiple internal and external sources, the data lake – often built on Apache Hadoop – provides a foundation for sophisticated analytics that can improve customer insights, deliver higher operational efficiency and reduce costs. Beyond just storing data, a key requirement of the data lake is being able to serve analytic models to real-time, operational applications. And that requires more than just Hadoop. Powerful operational databases are needed to make analytics models accessible and actionable within operational applications. Exposing these models to online applications makes our business processes smarter and more contextually aware – for example, presenting personalized recommendations to users, detecting and preventing fraudulent transactions while they are in flight, or predicting imminent failures in critical systems. Mutua Madrileña, one of the largest insurance companies in Spain, recognized the importance of creating a data lake in its goal to improve customer experience and optimize marketing spend. They worked with the Pure Spark Platform from Stratio to implement an operational data lake, bringing together: Apache Kafka and Apache Flume for data ingestion Apache Hadoop for storing raw data Apache Spark for analytical processing and machine learning, orchestrated by Apache Mesos MongoDB and Postgres for serving analytics models to operational applications and reporting tools R Studio and Apache Zeppelin for business intelligence and analytics *Figure 1: Stratio Pure Spark Platform: creating an operationalized data lake* Alvaro Santos, Big Data Architect at Stratio, presented the data lake built for Mutua Madrileña at this year’s MongoDB World conference. In his session, Alvaro discussed how the data lake is ingesting data from over 25 different sources to power a range of applications, including: The creation of machine learning models to personalize user experience across web and mobile channels, present product recommendations, and classify insurance applicants by risk Mapping of the customer journey through Mutua’s systems to understand user context and identify gaps in business processes Collection and analysis of marketing campaign data to measure impact and improve performance. Alvaro discussed the selection of technology for the data lake. Apache Spark was chosen because of its speed as a distributed processing engine, access to rich machine learning libraries, and developer-friendly APIs. MongoDB was chosen: To take advantage of its flexible data model, allowing rapidly changing, semi-structured data to be stored and processed with ease Rich secondary indexes that push query filtering down to the database. As a result, operational applications can execute complex queries with low latency Automatic sharding to support a doubling of data volumes in the data lake, and native replication for always-on availability View the slides to learn more about Mutua’s data lake journey: Learn more about unlocking operational intelligence from the data lake with our new whitepaper: Download the white paper

August 19, 2016
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