Mongo vs. RDBMS: issues convincing others

[Hippo]

Hello MongoDB users,
I am also on the verge of becoming a MongoDB user...except that I have a slight problem.

TL;DR version: The other people working with me on my project have grown up with RDBMS, and I'm not able to get them to see the benefits of MongoDB. When I list the features offered by Mongo, they don't seem to be reading it properly, quoting old RDBMS lore without reference to context. At least, that's what it seems like to me. I'm wondering if any of the arguments actually make sense. Since I haven't really used Mongo yet, I'm not able to validate/counter their arguments, but maybe someone else in this community will be able to help me?

Skip the Some Details if you wish; what I want is info about how to deal with The Response that I'm getting. Are any of the points actually a valid concern against  using MongoDB? The main issue: how to get people to at least look at another database?

Some Details

Here's a brief outline of the app I'm developing. It's a program, for use in a library, to keep track of books and other items that have been borrowed. Similar to projects like OpenBiblio. (The difference is that, unlike other library management programs, this is one where the users themselves record which books they have borrowed, instead of the librarian doing all the recording). I'm developing it as a webapp using Python, Flask, and, until now, peewee+SQLite. While trying to set up the database structure, I've been running into several problems which, though not unsolvable in SQL, can be solved much more elegantly using Mongo.

One main thing is that a borrowable item can be a book, magazine, single article, or multiple other things. Each of these item types will have different fields (author and ISBN for book, issue and volume number for magazine, etc.) and yet will need to be stored in a single table as a "borrowable". The SQL solution says, "Put all the columns in one table and make the type-specific ones nullable". But this makes things very messy in the Python code, and things like DRY principles break down almost immediately. The Mongo solution of "Use one collection, but use a different set of fields on the document depending on the type" works much better, and works perfectly and Pythonically using the MongoEngine library. Then there are other features like list-fields and multi-value indexes which are going to make implementations like multiple authors and search-by-tag much easier.

If anyone is interested, https://github.com/badrihippo/growlin. Note that I haven't uploaded my experimental Mongo code yet.

Oh, and to put things into perspective: I'm 18 and doing the actual coding; the others (including the person helping with db design) are 40+.

The Response

Here is the kind of response I'm getting [annotated with my thoughts]:

1. On Mongo, we are not confident on meeting the performance and scalability objective that we defined earlier. [don't know about this...this is where I need help]
   
2. Similarly, we are not confident that Mongo is aligned to the constraint that we have pertaining to easy maintenance of the application and data in future – the fact that data handling itself may require scripting is quite a challenge for future. [actually, I don't see it as a problem so much as an extra feature. I doesn't seem like I'll need to use it anytime soon, anyway]
   
3. Our database design discussions and structure finalizations were done assuming MySQL or an RDBMS layer. If we need to move out of RDBMS, it is important to design again looking at what is the best design option for MongoDB – it doesn’t make sense to use the same DB design for Mongo – it may be suboptimal. [actually, coming from a Python/OOP background I can easily redesign the database layout for Mongo...and have already done a draft. Using ORMs for object-oriented interaction, MongoDB models come to the mind intuitively: it's actually the SQL design decisions that can sometimes seem wildly unobvious]
   
4. Mongo is not RDBMS and we do not know if it is suited for a library application whereas any RDBMS and therein MySQL gives us the following benefits
   a. RDBMS in general is proven for data handling, especially for applications like a library software. [judging by all the workarounds I've seen going into the app, it actually seems to me that RDBMS is definitely the wrong software to use!]
   b. It meets the objectives and is aligned to the constraints of easy maintenance and availability of expertise
   c. A proven database brings forth lot of stability
   d. How to handle issues with a proven database are pretty much documented
5. We need to give a huge importance to the fact that we have to migrate old data from [the previously existing program] to [the new program I'm developing] – RDBMS lends to ease of migration. [so does Mongo, if you haven't noticed. Data import is more about scripting, not about the database. And I think I heard a mention of server-side scripting somewhere...]
   
6. Decision on underlying database should never be driven by ease of development, but based on what is required for long term stability, scalability, performance and ease of handling of data. [um...but don't you think the developer, who is the one looking at the final queries, will also have a good idea about which database seems better suited for the purpose?]
   

My question

Are any of these points valid? Specially point 4 which seems to say "people have always used RDBMS, therefore MongoDB is bad". It'll be nice if anyone can share experiences of Mongo's performance and scalability (whether positive or negative) so that I can have concrete examples/statistics to base my arguments/decisions on.

Sorry for this sudden and long post. It seems a bit out of place with all the technical discussions going on, but, well, this is the only forum I could think of. And hopefully this different kind of issue will give you a bit of a break ;)

[sallgeud]

TL;DR; from me: They're wrong on nearly all of their responses except for migration. If you already have a significant code base and it's tied to RDBMS, it will not be easy to move. This has nothing to do with Mongo. This would be true when moving between any two technologies that are different when it comes to storing and searching data.

Details:

1. Unless you've got amazing mysql admins, you're not going to scale as well in SQL as you do in Mongo. So, unless they have previous experience managing Facebook's MySQL, they'll have more success scaling with NoSQL databases than with SQL databases. In our experience, performance in Mongo was magnitudes faster, for our specific scenario, versus SQL Server. However, while our data is relational in nature, it's not heavily dependent upon JOINs across the model. That is, we merge much of the relational data into one document, which may relate to other documents, but does not require JOINs.
   
2. If you configure mongo in a replicaset only, and avoid sharding, it's actually just as easy to manage as MySQL. Sharding is somewhat complex, but can be avoided if you don't need massive collections.
3. You can actually just simplify your design when moving to any document database. Instead of thinking of it in terms of how you store data, you can focus on how you program. We find that Mongo allows us to avoid the majority of data structure questions at the storage level, and instead simply write our code around our class and property structures. This means that "the design is the code". Certainly you have to make sure you're writing your code correctly and properly to be queryable and allow you ease of use.  This is actually where the largest benefit lies to Mongo in my opinion. No more data architects jacking up your ability to quickly evolve your code.
4. Mongo is a document database. It can replace the majority of RDBMSes.
1. That could be true of ALL SOFTWARE prior to 2010. RDBMS was the primary choice in 99% of solutions. Document / NoSQL databases of today are mature and just as good as most RDBMSes out there.
2. That's probably true... but it's not exclusive of RDBMS... 
3. Use version 2.6 of Mongo. It's very stable.  3.0 is pretty good too.
4. stackexchange and these lists have been able to resolve every non-bug problem we've encountered.
5. Yes, migration in general sucks.
6. Yes it should. That shouldn't be the ONLY reason, but it should be considered. If you can build the same software for $50,000 in effort with the same reliability, scalability and performance, as software that costs $200,000 to build, it's a no-brainer.  We were able to develop software at about 5 times our expected pace because of Mongo being our choice. Your mileage may vary.

[Asya Kamsky]

You know, I'm going to disagree with you on one item - if they don't
know MongoDB (i.e. no one has expertise in it) then it will be more
challenging for them to maintain/support it.

Without knowing much about this team, I can't say if they have much
RDBMS expertise either - certainly people frequently over-estimate
their expertise, but certainly they have a lot more experience with
it.

I find it's important to acknowledge the cost of moving to a new
technology as that allows you to properly weigh it against all the
benefits. Denying that these costs exist may land one in a dead end
conversation time and time again.

To OP - I would point out resources like university.mongodb.com as
well as various large companies that are using MongoDB in production
(you can find lots of that on mongodb.com)

Asya

> --
> You received this message because you are subscribed to the Google Groups
> "mongodb-user"
> group.
>
> For other MongoDB technical support options, see:
> http://www.mongodb.org/about/support/.
> ---
> You received this message because you are subscribed to the Google Groups
> "mongodb-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mongodb-user...@googlegroups.com.
> To post to this group, send email to mongod...@googlegroups.com.
> Visit this group at http://groups.google.com/group/mongodb-user.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/mongodb-user/6931a1d3-ed88-4f2f-b85c-fdcccbd95f9f%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.



--
Asya Kamsky
Lead Product Manager
MongoDB
Download MongoDB - mongodb.org/downloads
Free MongoDB Monitoring - cloud.mongodb.com
Free Online Education - university.mongodb.com
Get Involved - mongodb.org/community
We're Hiring! - https://www.mongodb.com/careers

[Stephen Steneker]

On Thursday, 8 October 2015 21:08:59 UTC+11, Asya Kamsky wrote:

To OP - I would point out resources like university.mongodb.com as
well as various large companies that are using MongoDB in production
(you can find lots of that on mongodb.com)

Hi,

To add to Asya's comment, the starting point on mongodb.com is:
 https://www.mongodb.com/who-uses-mongodb

There is also a community directory on mongodb.org which you can filter by innovation award winners, use cases, and industry:

 https://www.mongodb.org/community/deployments

Please submit your own app if you'd like to see it featured:
 https://www.mongodb.com/contact/production-deployment-application

Regards,

Stephen