dynamic schema

3 results

AOL's targeted advertising business: Powered by MongoDB

While AOL may evoke thoughts of dial-up broadband for some, the company today drives over $2 billion in annual revenues connecting advertisers to consumers of its premium content, including Huffington Post, Moviefone, Engadget, TechCrunch, Patch, and Stylelist. MongoDB provides the data infrastructure for a significant portion of AOL’s business, both on the content and advertising sides of AOL. In the words of Jonathan Reed , formerly a senior software engineer at AOL, “AOL uses MongoDB a lot throughout our business,” and for very different use cases. As of June 2012 AOL had over 30 MongoDB projects running internally across over 500 servers. One of the important projects for which AOL uses MongoDB is advertising, as detailed in the video above. AOL’s Advertising.com platform helps advertisers reach highly-targeted audiences at scale, and MongoDB plays an essential role in storing Advertising.com’s user profiles. AOL turned to MongoDB for its flexible data model, as user profiles have various sizes and shapes, with different kinds of information stored for different users. One key feature that MongoDB offers is geospatial indexing, which enables AOL to advertise services based on a user’s location (e.g., showing airfare pricing based on the airport nearest to the user, even if all they’ve expressed is interest in flying to Paris). Importantly, all of this must be done in under five milliseconds, which means that AOL simply can’t afford to hit disk and must keep everything in RAM. MongoDB handles this easily, processing 12,000 transactions per second, or several billion each month. MongoDB’s performance was so good, as Reed describes, the company needed a special set-up to manage network traffic, which couldn’t keep up with MongoDB. While this seems like it must require a complex set-up, Reed suggests that MongoDB is “surprisingly simple” to set up and run. In the case of Advertising.com for this project, MongoDB runs in a single cluster spanning three data centers, two in the U.S. and one in Europe. Indeed, ease of use was one of the top-four reasons AOL chose MongoDB to power Advertising.com: Easy to learn and set up Easy to scale Great community Support contract available (“really good value for money”) None of this would matter, however, if MongoDB couldn’t handle AOL’s core requirement: dynamic data schema. AOL’s Advertising.com must constantly tweak the kind of user information it collects and stores, and has to be able to do so with super-high performance at scale. MongoDB ticks each of these boxes, and makes it easy to do so, leading Reed to conclude that hitting AOL’s scale requirements “would have been much harder with other technology.” Tagged with: AOL, Advertising, case study, use cases, flexibility, dynamic schema, high performance, scalability

March 26, 2013

MongoDB powers Mappy Health's tweet-based disease tracking

Twitter has come a long way from being the place to read what your friends ate for dinner last night (though it still has that). Now it’s also a place where researchers can track the ebb and flow of diseases, and take appropriate action. In early 2012, the U.S. Department of Health and Human Services challenged developers to design applications that use the free Twitter API to track health trends in real time. With $21,000 in prize money at stake, Charles Boicey , Chief Innovation Officer of Social Health Insights, and team got started on the Trending Now Challenge , and ultimately won with its MongoDB-powered solution, Mappy Health . Not bad, especially since the small team had only three weeks to put together a solution. Choosing a Database MongoDB was critical to getting the application done well, and on time, as Boicey tells it, MongoDB is just a wonderful environment in which to work. What used to take weeks with relational database technology is a matter of days or hours with MongoDB. Fortunately, Boicey had a running start. Having used MongoDB previously in a healthcare environment, and seeing how well it had ingested health information exchange data in an XML format, Boicey felt sure MongoDB could manage incoming Twitter data. Plus, Mappy Health needed MongoDB’s geospatial capabilities so as to be able to track diseases by location. Finally, while the team evaluated other NoSQL options, “MongoDB was the easiest to stand up” and is “extremely fast.” To make the development process even more efficient, Mappy Health runs the service on Amazon EC2. Processing the Data While UCI has a Hadoop ecosystem Mappy Health could have used, the team found that for processing real-time algorithms and MapReduce jobs, they run much faster on MongoDB, and so runs MapReduce within MongoDB, yielding insights like this: As Boicey notes, Writing MapReduce jobs in Javascript has been fairly simple and allows us to cache collections/hashes of data frequently displayed on the site easily using a Memcached middleman between the MongoDB server and the Heroku-served front-end web app. This jibes well with Mappy Health’s overall rationale for choosing MongoDB: MongoDB doesn’t require a lot of work upfront (e.g., schema design - “doing the same thing in a relational database would require a lot of advance planning and then ongoing maintenance work like updating tables) and MongoDB works really well and scales beautifully Since winning the Trending Now Challenge, Mappy Health has been working with a number of other organizations. We look forward to even bigger and better things from this team. Imagine what they could do if given a whole four weeks to build an application! Tagged with: Mappy Health, case study, disease tracking, US Department of Health and Human Services, flexibility, ease of use, Amazon, EC2, dynamic schema

March 18, 2013