For any team that ever avoided a six or seven figure SQL Server or Oracle license and managed to scale to more than 50 transactions per second with horizontal scaling, yes, MongoDB was absolutely worth it.
Was MongoDB Ever the Right Choice?
151–160 of 224 posts
Re: Was MongoDB Ever the Right Choice?
#152As with anything, it depends on the project. I’m working on an internal service that uses Mongo as a single merged cache for a lot of mostly unchanging data from various data stores with different credentials for each, which are distributed around the world, that we otherwise have to fetch through multiple comparatively slow API calls. For this, Mongo is perfect: no messing with schemas as they change, unannounced, f…
Elasticsearch can index documents dynamically, and doesn't require a schema to create an index. Dynamic data types for fields may not always produce what you want, but it's possible to define a partial schema for the fields that are important and let Elasticsearch handle the rest. The query language is verbose but I would hesitate to call it a nightmare. You can always search using the Lucene query language, and SQL…
My last project required fulltext search and I was going to go with Elasticsearch but being dependency-averse (also complicates the deployment story), I ended up using Postgres' built-in fulltext search capabilities and it actually works really nice, especially after I added a little DSL to take advantage of the full power of `to_tsquery` (so I could avoid the oversimplified `plainto_tsquery`)
Re: Was MongoDB Ever the Right Choice?
#153I found developing with MongoDB a pleasure, until its lack of transactions became problematic. Fortunately, the project I was working on didn't go very far. At the time, I concluded that MongoDB was the "Visual Basic of Databases." It was very easy get something simple running, much like Visual Basic classic was. Quite honestly, something ACID-compliant with a MongoDB-like API is really needed for small-scale project…
It's called MongoDB. ACID multi-document transactions, here, now, introduced in version 4.0. https://www.mongodb.com/transactions
Plus the feature, minus the reputation.
Re: Was MongoDB Ever the Right Choice?
#154I would argue that MongoDB is not—and has never been—the best choice for solving any particular technical problem. But it had some other "advantages" over other, better solutions – in that it was easier to set up, didn't require schema definition, had a passable clustering story etc. I have worked with at least one company that had been built using MongoDB as a primary data store from day one. This caused untold pain…
It was often the best choice for getting a product up and running fast and rapid iteration for exactly the reasons you mention. Once the schema solidified, it stopped being the right choice.
We (ZeroTier) experienced the same thing but with RethinkDB, a similar schema-less database. We outgrew it when we needed something more solid and more reliable and we had a pretty settled schema.
Re: Was MongoDB Ever the Right Choice?
#155Could this article title be rephrased "Has Postgres essentially killed the MongoDB market?"? ;)
Re: Was MongoDB Ever the Right Choice?
#156Earlier quoted context omitted.
> And then what happens when they add a field to the form and the table already had a million rows? Maybe I don’t follow. You would insert a row into the fields table. Millions of rows should be fine. > I asked “what would have bought us”. I don’t know. None of this matters really, as long as the service works.
You said doing a “create table on the fly”. So if they needed to add or modify a field, you would have to do an alter table.
Alter table is generally no big deal for any of the use cases that MongoDB is also able to handle.
On any good RDBMS, adding a nullable column to an existing table is an O(1) operation. This is the only option that's comparable to what's available in MongoDB, and it has the same performance characteristics.
On the great ones, adding a non-nullable column with a default value to an existing table is also an O(1) operation. The good-but-not-great ones, it's also O(N). (As always, you get what you pay for.) For MongoDB, wanting to do this would be unusual, but you would have the option of back-filling every record. It would be an O(N) operation, too. So, for this case, the characteristics of the RDBMS are no worse, and possibly better.
Adding a non-nullable column with no default is always O(N), but the fact that you're suggesting a document store as an alternative implies even more strongly that this is not the use case you're trying to cover. That said, if you did do it, it would also be O(N).
Converting a numeric column to a string column is always going to be O(N), yes. Whether or not that's the better option is something that's got to be decided in context. Basically, do you want to pay the cost of datatype conversion in one lump sum and then be done with it forevermore, or do you want to pay a small fee for datatype coalescing every time you access that field? There are good reasons to choose both options. However, all too often, the 2nd option is chosen for a very bad reason: Simply assuming that it's zero cost.
Re: Was MongoDB Ever the Right Choice?
#157I would argue that MongoDB is not—and has never been—the best choice for solving any particular technical problem. But it had some other "advantages" over other, better solutions – in that it was easier to set up, didn't require schema definition, had a passable clustering story etc. I have worked with at least one company that had been built using MongoDB as a primary data store from day one. This caused untold pain…
As a n00b when it comes to web development I've sort of given up on fretting more than "too much" about "Is this the best way?" and focused on "let's try some stuff and it doesn't work I'll learn from it and make a better choice when I come to it".
There seems to be a cost associated with evaluating optimal paths. Personally I get SQL (well enough to use it) and I can work with so I don't bother with MongoDB much, but if there's someone who doesn't and needs to get a project going and the alternative is lots of delay or no project, yeah why not.
I feel like when it comes to development people really gripe about the best choices ... when the non best choices might just as well be looked at as a path to the best choices, and there's a lot of value in that.
Now that's all within the context of weighing the costs to ... everyone. Hobby project few if anyone will see, hey who cares. Work project, a lot more diligence and consultation with others ;)
Re: Was MongoDB Ever the Right Choice?
#158I would argue that MongoDB is not—and has never been—the best choice for solving any particular technical problem. But it had some other "advantages" over other, better solutions – in that it was easier to set up, didn't require schema definition, had a passable clustering story etc. I have worked with at least one company that had been built using MongoDB as a primary data store from day one. This caused untold pain…
Postgres is not an alternative to Mongo, though. Provide a noSQL alternative if you want an alternative. RDBs and non-RDBs seek to address different sets of problems, and sometimes you do not want or need a relational database.
Re: Was MongoDB Ever the Right Choice?
#159As with anything, it depends on the project. I’m working on an internal service that uses Mongo as a single merged cache for a lot of mostly unchanging data from various data stores with different credentials for each, which are distributed around the world, that we otherwise have to fetch through multiple comparatively slow API calls. For this, Mongo is perfect: no messing with schemas as they change, unannounced, f…
One benefit to ES is scale. Elasticsearch can scale to at least a couple trillion records (on the order of 1.5 PB) if you spread your data out across enough hardware. You can then search those records in seconds (for simple queries). I'm not sure Mongo can scale quite that far, it was given up on before I started this work. Not saying it can't, just saying others had more success scaling ES and haven't really hit its limits. Bear in mind datasets span multiple clusters and are searches are merged using cross cluster search in these larger cases. Not likely to be an apples to apples comparison.
Re: Was MongoDB Ever the Right Choice?
#160I've only ever heard of mongo successfully used for two use cases: 1. As a cache, like redis 2. As a log store, like Elasticsearch In both cases, the data is somewhat ephemeral, and not the "source of truth" for the app. The minute it is used for holding real, customer supporting data, things start to get dire real fast.
I have used Mongo to store medical data that had to be stored for 7 years. We set it to make sure that all three servers in the cluster did a write acknowledgement.
Thank you! As an aside, is there a reason you're not using a write concern of "majority"? If you have w:3 in a three node cluster then if one node goes down, writes are going to start throwing wtimeout errors (assuming you have wtimeout set) even though the data may safely be written to a majority of nodes. We generally recommend setting w:"majority" for this reason.