Leaf in the Wild: China Eastern Airlines Migrates from Oracle to MongoDB to Deliver a World-Class Customer Experience

Mat Keep

Leaf in the Wild posts highlight real world MongoDB deployments. Read other stories about how companies are using MongoDB for their mission-critical projects.

Slashes costs, builds apps never before possible, and increases performance: from serving tens to serving tens of thousands of customers.

The airline industry is growing fast with revenues tripling to nearly $750B in just 10 years1. However, margins remain slim, forcing airlines to survive by providing a differentiated customer experience and driving out cost. As one of the world’s leading carriers, China Eastern Airlines is at the forefront of using technology to gain competitive advantage – breaking free from the shackles of legacy technology by upgrading to MongoDB to transform customer experience and reduce Total Cost of Ownership (TCO).

To learn more, I met with Shuaihua Tong, Engineering and Project Manager, and Chong Huang, Lead Engineer at China Eastern Airlines.

Can you start by telling us a little bit about China Eastern Airlines? China Eastern Airlines Corporation Limited serves nearly 80 million travelers every year, making us one of the world's top 5 airlines by passenger volume. We are headquartered in Shanghai and have a fleet of more than 430 aircraft. We are also a member of the SkyTeam airline alliance, extending our flight network from Shanghai to over 1,000 cities in nearly 200 countries around the world.

Please describe how you are using MongoDB. As part of our aggressive growth plans, we have embarked on a major digital transformation project that puts customer service at the heart of our operations. The Passenger Service System strategy is sponsored by our CEO, and requires implementing a new generation of modern IT systems to deliver high quality customer experiences.

A critical part of this strategy is improving how passengers search, discover and book flights on our web and mobile properties.

MongoDB is powering our new search platform. It is central to delivering the differentiated customer experience that is essential to assure future growth.

What did you use before MongoDB? Our original search application was built on the Oracle database. As our requirements evolved, we found it constrained how quickly we could innovate and release new search features to our customers.

What were the specific issues you faced with Oracle? We need to offer passengers the freshest flight availability information to search against. Previously we batch loaded inventories to Oracle from travel data systems such as Travel Sky.

We also want to offer passengers more flexibility in product search. Beyond just flight availability, we need to include criteria such as multi-city travel, current and historical pricing, airport locations, and more. With complex joins between multiple tables, Oracle quickly became I/O bound. It could not serve this data at scale to thousands of concurrent users and maintain millisecond response times.

How did MongoDB help you solve these challenges? MongoDB’s document data model, which eliminates the requirements for table JOINs, and its memory-centric design enables us to meet our performance SLAs. In testing, we achieved 30,000 queries per second while concurrently handling 6,000 writes per second. That's across a database with 100 million documents. Perhaps most impressive was that this was all done on a single node that was running at just 15% system utilization. This proved we could scale to thousands of simultaneous customers, while giving us plenty of headroom for future expansion.

Using MongoDB’s expressive query language and rich secondary indexes, we can now deliver the search flexibility our customers demand. They can use complex search criteria to quickly discover the best flight options with an end-to-end application latency of less than 95 milliseconds, of which the database is just a tiny fraction.

Migrating data from Oracle to MongoDB was very simple. We used the Pentaho ETL tools to move data between the two systems.

Did you consider other alternatives for this project? Yes, we also evaluated GemFire’s data grid as a potential solution. During our testing, both systems provided comparable performance, but GemFire’s costs were much higher, driving up TCO.

Can you describe your deployment environment? We are currently running the application on a single replica set, providing us both redundancy and self-healing recovery to ensure there is no application downtime. We plan to expand to a multi-data center deployment in the future.

As well as scale-out, MongoDB also gives us high scale-up performance, which helps reduce server sprawl. We have provisioned MongoDB 3.0 with the WiredTiger storage engine onto 64-core Linux-based servers, each configured with 512GB of RAM and SSDs. This impressive hardware footprint gives us room for future growth, and the ability to co-locate additional instances powering more apps in the future.

We use a mixture of programming languages including Java, JavaScript, and Python, and so MongoDB’s native drivers have been a huge ease-of-use benefit to our developers.

China Eastern Airlines online services architecture: MongoDB connecting thousands of flights to millions of passengers

How are you managing your MongoDB deployment? We use MongoDB Ops Manager for provisioning and monitoring. The telemetry collected from MongoDB, coupled with proactive alerts from Ops Manager, provides us immediate insight into any issues that could potentially impact user experience. The provisioning tools help us quickly spin up and upgrade instances in both test and production, without having to rely on manual configuration at the command line.

Because of Ops Manager, our administrators are much more productive.

Do you use other services from MongoDB? We use MongoDB Enterprise Advanced to reduce risk for this critical application. As discussed above, Ops Manager brings us operational efficiency. In addition, we have access to 24x7 support with guaranteed SLAs and direct engagement with the MongoDB engineering team, providing the assurances we need to keep the application available and performant.

We were very new to MongoDB, so to help get our development moving in the right direction from the outset, we used MongoDB Consulting Services.

The assistance we received around schema design, hardware selection, and operational best practices has proven invaluable in accelerating time to market.

How are you measuring the impact of MongoDB on your business? Across three dimensions:

  1. Building an application that was just not possible on Oracle. Providing a powerful, real-time search capability against fresh data with low latency across multiple online channels enables us to create a differentiated experience for our customers
  2. Significant cost savings. This project has proven MongoDB as a viable alternative to Oracle, and will serve to reduce our reliance on them in the future
  3. Improved developer efficiency. The simplicity of the document data model, the dynamic schema, idiomatic drivers and indexing flexibility means our development teams can build new applications faster

Do you have plans to use MongoDB for other applications?
We do. There are two specific projects we are working on now:

  • A recommendations system that uses MongoDB to run real time analytics against passenger data
  • Social enablement of existing applications, with MongoDB storing profile data and social streams

What advice would you give someone who is considering using MongoDB for their next project? Whenever you are considering a new technology, do not be surprised to encounter some pushback. A particular concern we heard from some of our team was the lack of multi-record transactions in non-relational databases. We took the time to demonstrate how MongoDB’s data model and ACID-compliant document updates provided the transactional consistency we needed for this and many other projects. That doesn’t mean to say that adding multi-document transactions in the future would not be useful for a small set of applications!

The second piece of advice we’d offer is around scaling. MongoDB’s auto-sharding is incredibly powerful, but just because you can shard, doesn’t mean you always need to. We have been able to achieve phenomenal performance from just a single replica set. If you do need to shard, invest the time to select the most appropriate shard key.

What are your thoughts on MongoDB 3.2? We are very excited by the release. All of our engineers are currently undergoing training on 3.2, and we intend to begin evaluation soon.

Thank you for taking the time to share your experiences with the MongoDB community!

If you are considering breaking free from relational databases, read our RDBMS to MongoDB Migration Guide to set you on the right track.
RDBMS to MongoDB Migration Guide

1 2015 Aviation Trends

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.