Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Was MongoDB Ever the Right Choice?

simplethread.com

Post reply on HN
Print view View original

131–140 of 224 posts

Re: Was MongoDB Ever the Right Choice?

#131

Post by netok »

scarface74 wrote: post #63
dijit wrote: post #17

Since everyone is sharing their opinion and experience with mongodb I think I’ll share mine. As an appeal to authority I would like to mention that I have relevant vocational qualifications on the subject (more geared towards scalability and operations). Although I don’t believe it really matters - it will to those who assume I don’t understand best practice. MongoDB itself is not /really/ a valid choice in many scen…

I’m a big fan of Mongo for the use case you described - searching by ID and all information in one document. But people don’t seem to understand that there are plenty of scenarios where you really either don’t know the schemes in advance and/or the “schema” is defined by an external source. I worked for a company that sold software that allowed users to create forms that could be filled out either on the web or via a…

EAV.

Re: Was MongoDB Ever the Right Choice?

#132

Post by squeaky-clean »

fooker wrote: post #100
scarface74 wrote: post #63

Earlier quoted context omitted.

I’m a big fan of Mongo for the use case you described - searching by ID and all information in one document. But people don’t seem to understand that there are plenty of scenarios where you really either don’t know the schemes in advance and/or the “schema” is defined by an external source. I worked for a company that sold software that allowed users to create forms that could be filled out either on the web or via a…

What happens when you need to do something like "Select browser user agent from all users who filled forms for a particular set of clients after a given date." ? This would fit in a single SQL query which is expected to perform reasonably well, with an unstructured database optimizing this query will take months of work.

    db.formEvent.aggregate([
        { $match: { createdAt: {$gte: ISODate("whenever")}}},
        { $group: { _id: "$custId", userAgents: { $addToSet: "$metadata.userAgent" } } },
        { $sort: { createdAt: -1 } }
    ])
Something like this? I'm not sure why this couldn't be an optimized query in mongo, but I'm also not sure why a query like this one needs to be optimized? This would run fast enough without needing indexes, and really fast with an index on a couple fields, but is a query like this run so frequently you need to have it be extremely optimized?

Re: Was MongoDB Ever the Right Choice?

#133

Post by giulianob »

fooker wrote: post #108
scarface74 wrote: post #104

Earlier quoted context omitted.

How so? In our case, meta data like the userid, browser agent, date entered, etc was always added to the object before it was stored and those fields were indexed. They are just name value pairs.

The point is that the query I mentioned requires joins. You can of course get the same information from key value pairs, it will just require a number of scans over all your data, which doesn't scale if you need the queries to be fast. On the RDBMS side, there has been more than three decades of research on optimizing patterns like this. You don't want to try and reinvent that. If you can know for sure from the start…

MongoDB has supported some types of joins for years now, you can do quite a bit with MongoDB aggregation pipelines. https://docs.mongodb.com/manual/reference/operator/aggregati...

As requirements change, you do need to migrate your data into a schema that makes sense and that's regardless of whether you're using SQL or MongoDB.

Re: Was MongoDB Ever the Right Choice?

#134

Post by ineedasername »

> Feature-positive effect – We tend to see what is present, and overlook what isn’t there.

This is such a problem. Just yesterday someone came to me and said, "We're now using x to do y. It makes z a lot easier. Just wanted to let you know so you can make the appropriate changes to your analysis & reporting applications."

Say what now? I'm embedded within the operational unit. I know a lot about day to day operations in & out of the systems in use, and how they ultimately translate through in data. I asked half a dozen questions, and 4 of them were met with "oh, we hadn't thought about that." These are deal-break questions, things the current method handled without issue, so much so they became invisible to the users, until they decide to make a change and realize the new method doesn't make any provision for them.

Re: Was MongoDB Ever the Right Choice?

#135

Post by djhaskin987 »

I'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.

Re: Was MongoDB Ever the Right Choice?

#136

Post by joduplessis »

I hate these kinds of articles, however, I do recognise that people are allowed their opinions, which is good. But these sorts of articles take a very polarised view of the world.

> Does this tool solve a real problem for us > Do we thoroughly understand the tradeoffs

Well, no. But neither did running JS on the server (along with numerous other similar examples). I've used MongoDB plenty of times before (in production with 1 issue to date) and I absolutely will again.

Re: Was MongoDB Ever the Right Choice?

#137

Post by AznHisoka »

james-mcelwain wrote: post #123
skywhopper wrote: post #106

As 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…

The query language can be a bit quirky if you're coming from a SQL background, but you're absolutely right. It is nowhere close to a nightmare.

Re: Was MongoDB Ever the Right Choice?

#139

Post by TimFogarty »

djhaskin987 wrote: post #135

I'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.

Plenty of people are successfully using MongoDB for real, customer supporting data at a large scale. There's a selection of users on the website for a start: https://www.mongodb.com/who-uses-mongodb

(Disclaimer: I work for MongoDB)

Post reply on HN