|
|
|
|
|
|
by jsjohnst
4148 days ago
|
|
|
Agree with @Xorlev, what's "very large" to you? If it's anything less than 1TB, then your definition of "very large" has scale issues (which is fitting if you are a MongoDB advocate I guess). Further, what's your read / write pattern? Do you do replication? Do you have requirements around writes being visible to reads on slaves near immediately? What is your data integrity requirements? All of these play into whether MongoDB is the right fit for someone's needs. The point remains, MongoDB is good for some use cases, but if you buy into the marketing hype of "the new DBMS standard for any team, in any industry", then you deserve the inevitable pain you will endure (that said, I do feel bad for your likely eventual replacements who have to clean up the mess from your poor choices). |
|
|
Of course it's not good for everyone's use cases though. Nothing is. Did anyone honestly believe that? I mean, even with the hype, did anyone truly decide to not evaluate their _database_, and believe the ad copy blindly?
Ultimately, I wouldn't have chosen MongoDB if it was bad for my use case. I tried it and other things -- read the documentation, made benchmarks and test cases -- and chose it after a period of evaluation. To do anything less for your database seems irresponsible (I'm looking at you, people who were surprised about the original default write semantics because you didn't read the docs).
Tangentially, the personal attacks ("which is fitting if you are a MongoDB advocate I guess", "that said, I do feel bad for your likely eventual replacements who have to clean up the mess from your poor choices") add nothing to your argument. They make you look foolish. Also, my replacements are still using my system (quite happily), over a year after my departure.