Live data from Hacker News

Why I Migrated Away From MongoDB

svs.io

81–90 of 213 posts

Re: Why I Migrated Away From MongoDB

#81
post #41
post #39

Earlier quoted context omitted.

The biggest lure of Mongo is that it gives you a nice SQL-like query API. So it's fairly easy to get started with, compared to other NoSQL alternatives. I primarly use it for small-medium size apps - when I know upfront that I will never need to scale it beyond certain number of users in the short-medium term. It's not as bad as it's made out to be. It's only if you really are looking to scale out, you should probabl…

Can you explain your reasoning? Isn't high scalability one of MongoDB's key features?

When you go to the supermarket, you may see products calling themselves "quality" or "luxury" or similar. Words like "powerful" and "scalable" are like that.

Re: Why I Migrated Away From MongoDB

#82
post #75
post #70

Earlier quoted context omitted.

So do you believe there is a use case for a document-oriented database? I feel like your comment writes off a huge swath of useful technology. I said this below, but I'll say it again. Data is malleable, and writing apps to fit around any datastore seems wrong. I write applications to fulfill their use case. When the needs of the application change, so could it's database (or other dependencies). http://gigaom.com/cl…

I don't know if there's a use case. I have never had one come up in my own projects. I do sometimes need to manage a large number of documents (unstructured data) but I have found the Unix file system sufficient for those, maybe augmented by metadata in the database. I've worked on big applications with big databases where DB operations and aggregations started to get too slow but so far I or someone smarter on the t…

Respectfully, I believe your comment is not very open minded. I believe the obvious answer is "Of course there's a use case!", just like there's obviously a use case for RDBMS, NoSQL (Mongo, Cassandra, BigTable, Redis, etc) serves a purpose.

I'll give you a couple examples. Google stores a huge amount of data in BigTable [1] which is fundamental for the operation of Gmail at scale. Another, Facebook initially used Cassandra [2] for it's Inbox search, then migrated to HBase when their needs changed for their new messaging feature.

Do we know if the the underlying data is stored in RDBMS? I'm guessing not at Google, but yes for Facebook/Inbox search. But my point is I'm not ruling it out, I'm open to different options.

[1] http://en.wikipedia.org/wiki/BigTable [2] http://en.wikipedia.org/wiki/Apache_Cassandra#History

Re: Why I Migrated Away From MongoDB

#83
Taking all these comments into account, if startups have to prototype quickly while trying to find market fit, does it makes sense to start off using something like mongodb but with the plan ti migrate to another database when you business starts growing? The database space is so confusing right now.

Re: Why I Migrated Away From MongoDB

#84
Taking all these comments into account, if startups have to prototype quickly while trying to find market fit, does it makes sense to start off using something like mongodb but with the plan ti migrate to another database when you business starts growing? The database space is so confusing right now.

Re: Why I Migrated Away From MongoDB

#85
post #66
post #56

Earlier quoted context omitted.

Not wrong. As a DBA with 15+ year experience, I can tell at a glance what an application was first developed against (Oracle, SQL Server, etc) or even where a dev started their career. You might as well say any OS is interchangeable as they're all just a kernel running processes.

I didn't claim RDBMSs are interchangeable or that there are no differences. I disputed the statement that "databases are only trivially interchangeable for trivial cases." That has not been my experience: changing out one RDBMS for another is not trivial, but it's easier and more controllable and predictable than changing out application code. I also disputed the notion that reading a book first would enable someone…

. . ."databases are only trivially interchangeable for trivial cases." That has not been my experience: changing out one RDBMS for another is not trivial, but it's easier and more controllable and predictable than changing out application code.

Keeping the punctuation but replacing the words with symbols:

   "X." Not X: X, but tangential comparison. 
Sounds like you actually agree with me, but don't see that as a reason not to make much hay about disagreeing with me. :)

Re: Why I Migrated Away From MongoDB

#86
Look, there are some places where document DB's solve problems easier/better than SQL, other places kind of suck. For example, plain old object mapping is easier with a document DB. Relational DB's tend to make your code look/feel/act more relational and less object oriented. Your object model tends to look just like your table structure. This can be good or bad depending on your viewpoint.

There are some approaches to solve some of the author's problems that end up making the Mongo system look and feel a lot more like a SQL system because sometimes data is actually related.

The author could have also taken a different approach to his data schema that would have fit more of a non-relational worldview.

Software development and architecture is about making choices and working with and around the limitations of your tools. It doesn't matter if PostgreSQL or MongoDB are "better". It's about solving a problem using a set of tools you are comfortable with.

Re: Why I Migrated Away From MongoDB

#87
post #82
post #75

Earlier quoted context omitted.

I don't know if there's a use case. I have never had one come up in my own projects. I do sometimes need to manage a large number of documents (unstructured data) but I have found the Unix file system sufficient for those, maybe augmented by metadata in the database. I've worked on big applications with big databases where DB operations and aggregations started to get too slow but so far I or someone smarter on the t…

Respectfully, I believe your comment is not very open minded. I believe the obvious answer is "Of course there's a use case!", just like there's obviously a use case for RDBMS, NoSQL (Mongo, Cassandra, BigTable, Redis, etc) serves a purpose. I'll give you a couple examples. Google stores a huge amount of data in BigTable [1] which is fundamental for the operation of Gmail at scale. Another, Facebook initially used Ca…

I wrote "I don't know if there's a use case. I have never had one come up in my own projects." I don't work for Facebook or Google, perhaps they have a use case. I guess I could assume there's a use case because the tools exist and people use them, but in my experience I have not had a need for Mongo or any NoSQL database.

I'm not dismissing the tools out of hand -- I haven't used them except to play around with tutorials. I am pretty sure a lot of people start out with Mongo or whatever without having a use case defined and without having good reasons to eliminate the tried-and-true RDBMS solutions. "Use something cool and new" is not a use case. "I've read on slashdot that SQL databases don't scale" is not a use case.

Re: Why I Migrated Away From MongoDB

#88
It's not necessarily all or nothing - I have worked on several projects now each using multiple database-type options: mongodb for read-intensive, loose-schema type stuff where the growth is generally predictable (e.g. products, suppliers, logs), postgres for relational-type stuff (orders) and solr for searching (I know solr isn't a database but people seem hung up on whether mongodb supports case-insensitive searching - hint: don't use any database for search).

I doubt that, unless it's extremely simple, any set of requirements are an exact match to only one of these technologies... mix and match is the future :P

Re: Why I Migrated Away From MongoDB

#89
There are 3 reasons I have gone running and screaming from and RDBMS. 1. Software gets large / complex to get meaning full work done. I am all about data consistency but at some point it is time to break things up into services and not have a single database. 2. If the software is popular enough everyone is running to use NoSQL (cache is NoSQL). 3. Clearly it is not a good storage solution either because for example in an address book nested list greatly simplifies everything. (right tool for the job)

I spent many years hammering away with RDBMS and by and large it was great until it wasn't. I try to look at data storage more holistically now based on best guess of the problem. I have tried to convert an application from Postgresql to MongoDB and it failed but that wasn't MongoDB's falt it was because I didn't change the data model to fit a document storage system. I have also tried to use PostgreSQL for a realtime reporting system and failed horrifically and that was not Postgesql fault it was mine. Amazing what happens when you stop pushing a chain and start pull it!

Re: Why I Migrated Away From MongoDB

#90
post #82
post #75

Earlier quoted context omitted.

I don't know if there's a use case. I have never had one come up in my own projects. I do sometimes need to manage a large number of documents (unstructured data) but I have found the Unix file system sufficient for those, maybe augmented by metadata in the database. I've worked on big applications with big databases where DB operations and aggregations started to get too slow but so far I or someone smarter on the t…

Respectfully, I believe your comment is not very open minded. I believe the obvious answer is "Of course there's a use case!", just like there's obviously a use case for RDBMS, NoSQL (Mongo, Cassandra, BigTable, Redis, etc) serves a purpose. I'll give you a couple examples. Google stores a huge amount of data in BigTable [1] which is fundamental for the operation of Gmail at scale. Another, Facebook initially used Ca…

I'll add that email and Facebook postings and Instagram photos don't require the same kind of data consistency and durability that medical records, bank transactions, or rail car movements require. If Google loses some old emails or Facebook loses the last thousand "likes" on a Jersey Shore fan page that's not much of a catastrophe, and they don't guarantee their data anyway. For those use cases Mongo or Cassandra et al. may be the right fit.

I work on a app that stores documents (PDFs) in Amazon S3 containers, and sometimes those documents get lost or inaccessible for some reason. We have backups for those. The only consistency requirement there is that the PDF opens and the name matches the name in the RDBMS. That's a much lower bar for consistency and durability than our credit card transaction data, for example.

Post reply on HN