When we talk about MongoDB most of the discussions focus on how people have lost data and have had operational issues with it.
Are there any companies/teams that have successfully deployed and scaled MongoDB in the recent years? If so why did you choose it despite the negative publicity and what kind of data and access patterns are you using it for?
Yes, I'm working to a global company in a global project, its hard to describe how we use the database but in simple terms, we store the information of customers and their preferences about alerts & notifications, params & configuration about the alerts and of course the alerts sent by our application.
about the negaive publicity I think in most of cases it related with mistakes about how to work with mongodb.
Hi there,
guess there are plenty of companies out there with success stories. Personally I have been quite septic when I was asked to use MongoDB for a government project in the area of tax income prediction. We stared small more in terms of an POC, but the success came faster than we thought and we had to scale out. Luckily this was a really easy task with MongoDB. That it is purely made for it but it is one of its pros.
An other project, last year was in the area of health / hospital software with faily high security and HA targets. Also this was easier that thought in the beginning. The more I use MonogDb the more I like it.
Personally I think the success story of MongoDB is just in its Beginning but this is my own opinion. The best thing you can do it to give it a try. But please do not make the same error like me. First get a very good understaning of the document model than design your DB. Many calls for help I get can be boiled down to a design which was obviously make be some one who was still thinking in relations instead of documents.
Have fun and enjoy, as soon as you climbed the hill and start thinking in documents you have passed the line. :-)
We did in 2014 a rewrite of an API that was in SQL Server for MongoDB along with asp.net. It was very good, very fast and very satisfying. This was my first professional contact with mongodb.
We use MongoDB for performance, as a kind of caching layer in front of our relational DB. Since it's pretty well normalized, joining all the tables together for a web page render takes forever, so we do that once and store it in Mongo, then just return that whenever a site needs data!
I've used MongoDB extensively for the aggregation framework. The tools within that subset of mongo provide a rather granular and speedy approach to manipulating compound datasets into usable, normalized results. I recently built a translation service using MongoDB as the backend, and utilized the aggregation framework to weight and score translations based on different criterion.
We use MongoDB in several capacities on several projects: A cache/ speed layer for content distribution worldwide (relying on replica set across data centers), an event source for customer loyalty and profile management, and as a backend for an e-commerce style customer facing web store. In each of those projects we leveraged several mongo features that were well suited to the problems we had. Our mongo clusters have been remarkably stable and work very well. Our scale has not required sharding at this point. Our QPS and write rates have been well within the design SLA. We did have to periodically analyze query performance and apply index and or query syntax changes, but other than that didn't encounter any issues. The biggest wins for us was time to market and flexibility: Compared to the RDBMS counterparts, we move faster, resolve issues faster, and deliver web pages faster.
The negative publicity has been "in the noise" and typically reflected more negatively on the generators of such rather than the product itself.
We use mongodb shard cluster to support up to 10k simultaneous users for our web application. Without this sharding architecture, no matter how big our sql server is we can't handle that work load.
I have worked on several projects that successfully used MongoDB over the past six or seven years now with three different companies. One project had over 5TB of data spread out over a couple of databases with numerous collections each, and no we didn't shard that database. We also didn't have any issues with accessing the data at that size. When I see negative stories around a technology, especially databases/data storage, I personally like to dig in to see if things are as bad as people say. All platforms can have issues (don't get me started on SQL Server and torn pages ;) ). Most of the negative press I've seen around MongoDB was from people not understanding the technology. Sure there were valid issues/bugs and some people might have lost data, but I don't think it was as widespread as some posts would have you believe (except for those running old versions accessible from the internet without proper authentication that is). Also a lot of posts that keep coming up are from several years back. MongoDB has changed a lot over the past couple years, and they continue improving the platform with each release. Bottom line, understand the platform before using it, learn it's strengths and weaknesses and you should have a successful implementation as well.
In my company, we are currently working on several projects backed by MongoDB. All of them do it successfully. Everybody I work with is really happy with MongoDB. I only know one user that thinks MongoDB has not a really good performance, why? He compares it with ElasticSearch in a strict search use case. As you can see, he is not making a good comparison. So, it's better to learn and test before saying uncertain phrases.