Você está na página 1de 12

A 10gen White Paper

Agility in the Age of Apps:


How the Next Generation of Databases Can Create New Opportunities for Telecoms

February 2013

Table of Contents
E XECU TI V E SU M M A RY What Is MongoDB? Telecoms Adapt to Slow Growth CUS TOM E R C A SE S T U DIE S Outside the Box: Capitalizing on Online Video Shared Experiences: Consumer Cloud Storage as a Way to Reduce Churn Featured Case Study: How 02 Turned Cost into an Opportunity One-Stop Shop: A Universal Product Catalog Across Multiple Channels Small Sensors, Big Data: Building a Machine-to-Machine Platform All in One Place: A True Subscriber Identity Management System Know Your Customer Like Yourself: Customer Sentiment Analysis MongoDB: Speed, Siz e, S tability Resources 1 1 3 3 3 4 4 5 5 6 6 7 8

Executive Summary
With consumers and businesses spending ever more time connected to the Internet, telecoms can expect growing demand for their services. But demand doesnt always translate to profit, as competition, commoditization, operational complexity, and network investment costs threaten to turn telecommunications providers into low-margin dumb pipes. More than perhaps any other industry, telecommunications is disrupted every few years by market-shifting innovations. To compete, telecoms need to develop new services, and to do so rapidly, before their competitive advantage is neutralized. Telecoms need tools that allow them to adapt to changing needs quickly and affordably, with the reliability they expect from their long-lived legacy systems. MongoDB, the leading NoSQL database, allows telecommunication companies to develop new applications quickly and adapt them as needs change. It is highly scalable, perfect for an age in which companies are capturing exponentially increasing volumes of data. And in an environment buffeted by many economic challenges, MongoDBs total cost of ownership can be orders of magnitude less than that of traditional databases like Oracle.1

What is MongoDB?
In traditional relational databases like Oracle and MySQL, data are stored in linked tables organized into rows and columns. Each row is associated with a unique entity, often a customer account, and each column is associated with a field defining an attribute of the account. Separate tables store different types of information about an account (e.g., mailing address, billing history), with common identifiers linking tables together. Schemas, or maps, that diagram these links and define allowable fields are locked in during the database development period, and managed by database administrators (DBAs), who must approve any changes. This approval process creates a bottleneck for developers trying to create and modify applications quickly. MongoDB uses a more flexible data model. A document database, MongoDB allows for varied data types and rapid addition of new fields. While entities in relational databases must pull information from fields in multiple tables, a single MongoDB document can store an entitys entire information. These documents can contain as many or as few fields as necessary. Creating new fields doesnt necessarily require admin-

See the 10Gen White Paper, A Total Cost of Ownership Comparison of MongoDB & Oracle. http://www.10gen.com/sites/default/files/downloads/10gen.TCO%20-%20MongoDB%20vs.%20Oracle.pdf

istrative approval. Developers can create new fields as they create new documents, write a script to add the field to all documents or batch-populate documents with a new field when sending a request to the database. Since new fields can be added ad hoc, MongoDB works well with unstructured, semistructured and polymorphic dataunlike relational databases, which cant easily store different types of data and require data to be structured before they can be mapped. With MongoDB, notes from customer service calls can be stored first, and organized later. Because the documents in MongoDB are similar to the objects used in most modern applications and programming languages, developers find MongoDB easy to work with. Documents are described in the Javascript Object Notation (JSON) format, familiar to users of Javascript. Developers dont have to spend much time learning MongoDBs syntax, or mapping their application structure to the database structure. This contrasts sharply with relational databases. For relational databases, developers and database administrators must ensure that their database schemas are aligned across three layers: the application, the application-database interface (object-relational map, or ORM) and the database itself. The need to create and maintain three separate, but consistent, data maps creates administrative drag. With MongoDB, there is no need for separate data maps or approval processes for creating new fields. Developers can create new applications rapidly, and revise and enhance them quickly. The volume of data created by popular social, mobile and video applications is immense. As relational database deployments reach their processing and storage limits, companies are faced with the expensive and complex task of upgrading their purpose-built servers and storage area networks (SANs). Upgrading servers often means several hours or even days of downtime. MongoDB, however, allows companies to expand their processing power and storage capacity easily across multiple off-the-shelf machines, on-site or in the cloud, with no downtime. With MongoDB, large databases can be partitioned into groups of documents, known as shards. These shards are distributed across different machines, with both processing and storage occurring separately from

the original server. Machines can be simple commodity servers found in cloud services like Amazons EC2. No expensive purpose-built hardware needs to be upgraded or replaced. Companies can therefore quickly and cost-effectively scale their applications in response to demand, and easily re-deploy system resources as needs change. Sharding brings performance benefits as well, as companies can place groups of documents on machines closer to the geographic source of those documents so, for example, customers in a particular region can access their user information more quickly. MongoDB provides many of the features that will be familiar to users accustomed to relational databases. MongoDB uses a rich query language for searching the database and supports indexing of documents on secondary fields. MongoDB provides an interface for interacting directly with the database, and drivers for most popular programming languages, including Java, C++, C#, PHP and Python. To provide the high level of uptime that users expect from relational databases, MongoDB supports the automated replication of database shards on up to 14 back-up servers and automated failover to back-ups when primary servers fail. With users as varied as Viber, Disney and Cisco, MongoDB has proven its versatility as a generalpurpose database. Unlike some other NoSQL databases, MongoDB allows analytics tools to record and analyze changes to the database in real-time. There is none of the lag-time associated with batch processing tools like Hadoop. MongoDB can be used with a diverse set of applications, from content management to data mining, allowing developers to focus their time on application development, rather than database maintenance and schema updates. With its flexible, simple and developer-friendly data model, MongoDB empowers organizations to be agile, to act like startups. They can get new applications to market quickly, and revise, upgrade and expand them as needs evolve. In many companies, administrators of relational databases limit the number of changes that can be made to the database structure to one or two times per year. With MongoDB, theres no need for such limits.

Telecoms Adapt to Slow Growth


Telecoms tackled the problem of big data before many other industries. Telecoms implemented the original operating support systems in the early 1970s as a way to automate and speed up the massive number of tasks they needed to do: taking orders, assigning lines, configuring network components, collecting payments and so on. They were some of the early adopters of relational databases, with Bell Labs purchasing an Oracle machine as early as 1979, only a year after Oracles commercial launch. Billing support systems and operating support systems from the 70s allowed for mass automation, but rules had to be hard-coded and data relationships were fixed. Getting different legacy systems to speak to each other remains an ongoing problem for many telecoms. Today, telecoms face different challenges. In mature markets, telecoms confront competition not only from companies offering similar technologies (e.g., two wireless operators) but from companies offering the same applications over different technologies (e.g., a landline and wireless operator), wholesale operators with different cost structures and nimble startups offering competitive applications over the Internet. Opportunities for new subscriber growth are limited, with mobile penetration in most rich countries exceeding 100%, fixed-line subscriptions falling and pay-TV subscriptions flat in many countries. Telecoms are therefore turning to their existing subscriber bases for revenue growth. They are considering new revenue streamslike targeted advertisingand additional value-added services, like over-the-top video and consumer cloud storage, to increase their revenue per user. Even if these applications cannot easily be monetized, they can help strengthen brand loyalty, reducing customer churn and therefore increasing the lifetime value of subscribers. At the same time, increasing demands on telecoms networks are creating a need for increased capital investment. To maintain margins, telecommunication service providers are looking for ways to reduce their costs across all parts of the business, including network operations, customer service and marketing. Reducing customer acquisition costs is a particular focus of many rich world telecoms.

Customer Case Studies


Outside the Box: Capitalizing on Online Video
As consumers have watched increasing amounts of video online, pay-TV providers have had to adapt. Many providers have pursued TV Everywhere strategies that enable their customers to watch content on devices other than their TVs. A few have pursued standalone Internet-based video services to compete directly with Netflix, NOW TV, LOVEFiLM and other streaming video providers. A major pay-TV provider recently launched an online video site that allows users to subscribe on a monthly basis or order movies a la carte. Users can choose from a catalogue of more than 1,500 films, and pause, rewind or fast-forward programs easily. Users can mark films for future viewing, and automatically receive recommendations for other films they might like. The provider chose MongoDB to power its system because of its flexibility and scalability. The company wanted a system that could support 70,000 concurrent users during peak hours, with users making constant calls to the database to search, browse, rewind, pause and fast-forward films. The database also stores data on where exactly in a film viewers pause watching so they can return to the content later. The ease of adding new fields to documents in MongoDB permits developers to rapidly add new meta-tags to characterize films in a variety of ways, alongside the traditional tags like actor, director and genre. Over time, the recommendation engine becomes smarter, as it leverages a growing base of content, meta-tags and information about user behavior. In the future, MongoDBs support for mixed hierarchies will allow the provider to add new content types like TV show collections and even live events. MongoDBs ability to support documents nested inside other documents means that developers wont have to categorize individual episodes of TV shows at the same level as standalone films. Users will be able to access a particular content typefor example, a football teams seasonand find programs organized in an intuitive way.

Shared Experiences: Consumer Cloud Storage as a Way to Reduce Churn


For years, a major European mobile operator was ahead of the curve in offering its subscribers the ability to store photos, music and video in the cloud. But recently, the operator found that the MySQL database it had built 13 years ago was reaching the limits of scalability, and did not allow for the kind of flexible access controls that users are accustomed to on social networking sites. The operator chose MongoDB to enable more flexible sharing. Subscribers can now share videos, photos, photo albums and mixed media albums with particular users or categories of users. The content itself is stored in a separate file system, while MongoDB is used to store metadata about the content, such as

viewing permissions, location data and timestamps. Because adding new fields to the previous relational database system was such a time-consuming process, much of this type of data was previously stored in text form or discarded. MongoDB, however, can automatically turn this data into new fields, so users can see where and when their photos or videos were taken. By tying document storage to mobile subscriptions, the operator increases the stickiness of its paid service and defends against churn in a market threatened by increasing competition. Improving the available features allows the operator to keep pace with standalone consumer cloud storage sites like Dropbox, social networking sites and online photo album services.

Featured Case Study

How O2 Turned a Cost into an Opportunity


O2 uses customer movement data to offer location-specific local offers. By necessity, wireless operators need to track the locations of their customers. Rational network investment hinges on knowing which cell sites require more capacity, or where more cell sites are needed. But where other operators saw a cost, O2, the United Kingdoms leading wireless operator, saw an opportunity. What if you could get businesses to pay to offer your subscribers location-specific special offers? O2s Priority Moments provides businesses a way to reach potential customers when theyre in the vicinity of one of their locations. O2 subscribers install a free mobile application and receive notifications about discounts and other special offers in their area. Deals are delivered by location, so its quick and easy to find the offers and experiences they want, said O2s Andrew Pattinson. Traditional relational databases are ill-equipped to handle the complex volumes of data generated by millions of subscriber movements. Nor are they particularly adaptable if the applications functionality needs to change. Selecting MongoDB as our database platform was a no-brainer, said Pattinson, as the technology offered us the flexibility and scalability that we knew wed need. With more than 20 million subscribers, O2 required a database that could scale as usage grew. Deployed on Amazon Web Services cloud, the Priority Moments database can easily expand due to MongoDBs support for database partitioning. MongoDBs native geospatial support made MongoDB a natural fit, while MongoDBs flexible data model will allow O2s developers to tweak the application as subscribers and advertisers needs evolve. O2 was so satisfied with its experience with MongoDB that O2 and its parent company, Spain-based Telefonica, have started using MongoDB for other next-generation applications. Said Pattinson, Were very excited about MongoDB and look forward to more projects in the near future.

Deals are delivered by location, so its quick and easy to find the offers and experiences they want. -Andrew Pattinson, O2

One-Stop Shop: A Universal Product Catalog Across Multiple Channels


A large European mobile operator was finding it difficult to maintain a consistent product catalog across all its channels: stores, telesales and the web. Because of the lag time in updating the catalogs, a user could find an offer online, go into a store and find that the offer was not available yet. The operator needed a system that allowed it to update offers once and have those offers be instantaneously available to consumers searching the catalog in any channel. They also needed the ability to add and change products quickly to respond to shifting market demands. The operator initially chose Oracle as the database to power its new omnichannel product catalog. But after spending more than $2 million and a year of work, the operator found it was getting nowhere. The database required an enormously complex schema, with 250 tables required to describe a single product. The schema had to be reproduced in object-relational maps (the database-application interface) and the application itselfundermining the original goal of developing a catalog that could be updated quickly. Oracle simply could not cope with the variations of payment options, devices, contract lengths, bolt-on services and bundles the provider was offering. However, MongoDBs highly flexible data model and economical approach to licensing allowed the operator to develop a true omnichannel product catalog within six months and for a substantially smaller investment. The product catalog includes an array of prepaid and postpaid products, a growing selection of devices (smartphones, tablets, wireless modems, SIMs) and bolt-ons, such as data top-ups and international calling packages. Different product types are organized in different hierarchies, and some products are simultaneously available in different sections of the site. In addition, the operator has found it easy to add new product detail to product listings, such as specifications and regulatory-required safety notifications.

Small Sensors, Big Data: Building a Machine-to-Machine Platform


With the number of mobile subscriptions exceeding the size of the population in most mature markets, operators have looked to alternative sources for subscription growth. One highly promising area is machine-to-machine (M2M) communication in enterprises, with estimates of future M2M connections running into the tens of billions. Analyzing a constant stream of readings from a large number of sensors allows businesses to create efficiencies and identify pain points in their infrastructures. But how do you enable companies to store, process, analyze and quickly act upon all this data? While investigating database options for its M2M enablement platform, a European mobile operator realized that using an Oracle database would be cost-prohibitive. The operator needed a system that could take in up to 10 billion sensor readings for a single customer, with each reading a separate record or document. But typical M2M use cases, such as fleet tracking systems for shipping companies, do not generate enough return to justify the large investment required for an Oracle system that could handle the desired data volumes. The operator chose MongoDB due to its lower total cost of ownership, flexible data model, scalability and support for real-time analytics. The operators beta customer is a power company collecting readings from electric meters every few minutes, eliminating the need to send out technicians and allowing the company to keep a closer eye on household-level usage in its distribution network. MongoDBs support for real-time analytics allows the customer to set up alerts that can be triggered when specified performance or utilization benchmarks are breached. MongoDBs flexibility will also allow the operator to easily adapt the platform for other types of sensor readings, such as temperature, speed and acceleration. And MongoDBs scalability permits the platform to grow as more customers use the operator for M2M solutions, and as their needs grow.

All in One Place: A True Subscriber Identity Management System


Over a customers lifetime, operators collect enormous amounts of data about their subscribers: billing histories, usage patterns, total usage, location (for mobile operators), contract changes, service call histories and more. But a patchwork of legacy systems, some decades old, collects this data in different databases, many of which dont communicate with each other. To monetize this data and improve internal operations, operators need a single system that is scalable and flexible enough to incorporate new types of data. A major wireless operator chose MongoDB as the database for its subscriber identity management system. Trying to aggregate customer data from a variety of systems was proving a bottleneck for developers, who had to create numerous object-relational maps to get their applications to read from existing relational databases. The operators new personalization server will aggregate data from dozens of systems in one place, eventually allowing both customers and internal personnel the ability to see all data about a customer in a single location. An improved subscriber identity management system improves call center efficiency by reducing the amount of time customer service representatives need to pull data on customers. MongoDBs support for real-time analytics enables a live dashboard that shows trending customer service issues, which can help customer service representatives determine whether customer complaints are an isolated issue or part of a larger pattern. This complete view of a customers needs will improve customer satisfaction and increase retention. A single source of customer data also allows developers to build business intelligence systems more rapidly. Licenses to access these systems can be sold to retailers and others looking for data on subscribers movements and Internet usage.

Know Your Customer Like Yourself: Customer Sentiment Analysis


UberVu, a social media analytics company, uses MongoDB to aggregate and analyze data from social networks for clients seeking insight into customer sentiment on their products. Mentions of particular terms are annotated with pertinent data, such as source (Twitter, Facebook, etc.), language, sentiment and time, and indexed in MongoDB. UberVu can easily filter these streams by attribute (language, gender, etc.) to produce segmented cuts on customer sentiment. MongoDBs flexibility and scalability allows UberVu to add new sources and sentiment attributes over time, and grow its storehouse of data as social networking use grows. Telecommunications companies looking for insight into their products can use MongoDB in a similar way. They can aggregate data from social networks, blogs, bulletin boards and media websites to answer tough marketing questions, such as, are available download speeds affecting brand perception? MongoDB can help reduce the lag-time and expense involved in traditional market research, by greatly reducing the need for focus groups and customer surveys. MongoDBs ability to support rapid customer sentiment analysis allows companies to change course quickly if marketing campaigns prove ineffective, as well as anticipate emerging customer needs more rapidly. MongoDBs support for varied data types allows telecoms to store a mix of external and internal data (customer service calls, corporate website usage history, etc.), and determine how best to annotate, analyze and use the data at a later date.

MongoDB: Speed, Size, Stability


MongoDB enables telecoms to expand their customer bases, increase their revenue per user and improve their customer acquisition and retention. MongoDB doesnt require expensive licenses or proprietary hardware, making it a natural fit for greenfield deployments with unknown demand, like geo-targeted mobile advertising. Its cost-effective scalability and quick time-to-market makes it equally suitable to time-sensitive company-wide deployments, like an omnichannel product catalog. And its flexible data model provides companies with the agility to change applications like an M2M platform in response to customer demand. In addition, its support for real-time analytics makes it a great tool for improving internal operations, from customer sentiment analysis to increasing call center efficiency. For much of the last decade, telecoms have felt left behind by hardware and software vendors in the race for innovation, hamstrung by their reliance on legacy systems. With its agility and scalability, MongoDB allows telecoms to couple the resources of a multinational with the speed of a startup.

Resources
MongoDB Downloads Free Online Training Webinars and Events White Papers Case Studies Presentations Documentation Additional Info www.mongodb.org/downloads education.10gen.com www.10gen.com/events www.10gen.com/white-papers www.10gen.com/customers www.10gen.com/presentations docs.mongodb.org info@10gen.com

For more information on 10gen and MongoDB, please visit www.10gen.com and www.mongodb.org.

New York Palo Alto Washington, D.C. London Dublin Barcelona Sydney US (646) 237-8815 INTL (650) 440-4474 info@10gen.com
Copyright 2013 10gen, Inc. All Rights Reserved.

Published by 10gen, Inc. / Feb 2013

Você também pode gostar