Customers want your business on their smartphone. And they expect it to get better weekly. Too bad your RDBMS makes it hard to iterate constantly. And it wasn’t built to support millions of users, either.
With MongoDB, you can build killer mobile apps that scale to millions of users. Faster. With less money.
Otto, Europe’s second-largest e-commerce company, continually updates its catalog of over 2M products to provide a one-to-one shopping experience for 30M shoppers and drive €2.3B in revenue.
Central repository of trades across multiple asset classes, exposing trades for operational applications as well as aggregated analysis.
One data store for thousands of assets under an organization’s purview, including vehicles, personnel, locations, and even information assets.
|Catalogs Are Hard||MongoDB Makes it Easy|
No Solution. Trying to consolidate different data in different formats from different systems in a relational database is hard and in many cases impossible
Do the Impossible. MongoDB can incorporate any product, entity, attribute or any other type of data, no matter what it looks like. And It does so while preserving all the functionality needed to build a powerful application, including advanced features like recommendations.
Stagnant. RDBMS technology leaves teams impotent to do what the business asks. Instead, they wrestle with data modeling, transformation and schema problems for months, or even years.
Faster. Your teams move faster with MongoDB because its dynamic schemas let them iterate. They spend less time figuring out how to accommodate new entities or attributes, and instead ship new products in weeks.
$$$$. Large teams tied up for long periods of time make RDBMS catalog applications expensive to build and maintain. Proprietary software and hardware add to the cost. The business case becomes hard for you to justify.
$. More productive teams, plus commodity hardware make your projects cost 10% what they would with a relational database.
Creating a catalog is easy. Evolving a catalog is hard.
Rigid Schemas. You should be able to store new pencils, parcels, or trades instantly. You should be able to build new features and track new attributes. But relational schemas are hard to change incrementally, especially without impacting performance or taking the database offline. Under Armour solved this by switching to MongoDB.
Heterogeneous Data. A catalog may need to store data from many types of assets with any number of attributes. Orange has to track hundreds of pre- and postpaid plans, smartphones, tablets, and accessories. Putting these in a single database is hard.
Feature Tradeoffs. A catalog is only as good as its ability to serve up fine-grained access to the data within it. You may need to search and browse a product catalog across dozens of dimensions, like brand, size, price and color. Key-value stores force you to sacrifice the functionality to get, set and analyze the data – like expressive query operators, atomic updates, secondary and geospatial indexes, and aggregation – for the flexibility to store it.
People love using MongoDB for catalogs because it lets them store any kind of data, retrieve it, and change the schema as they go.
Documents. MongoDB’s JSON document model makes it easy to store different assets with different attributes in a single place. It also makes it simple to represent complex, hierarchical relationships.
Dynamic Schemas. Schemas in MongoDB are self-describing. You can add new products and features – like recommendations – and evolve the schema instantly, without taking the database down or impacting performance.
MongoDB Query Language. An expressive query language, indexing – including text search and geospatial – and analytics provide flexible access to the data, no matter how the business needs to find it.