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

The genius and folly of MongoDB

nyeggen.com

Post reply on HN
Print view View original

241–250 of 280 posts

Re: The genius and folly of MongoDB

#241

Post by swah »

nostrademons wrote: post #219
byroot wrote: post #176

Earlier quoted context omitted.

Sure you have full permalink support, but why do you have to rely on closure to do pagination ? My guess: because by relying on in-memory data-structures you can't do what any half assed php forum do, ad hoc queries.

I suspect he doesn't have to rely on closures to do pagination: they're a programming convenience that means you don't have to do things like think about what state persists between pages. Anything you can do with SQL you can do with in-memory data structures. If you're interested, I'll be happy to take any SQL query and convert it to some Python list comprehensions on arrays of dicts.

Some statements like self-joins become relatively compact in SQL though...

BTW, do you miss Java's more advanced structures (say MultiSet) when programming in Python/Go?

Re: The genius and folly of MongoDB

#242

Post by chris_wot »

nostrademons wrote: post #211
rsynnott wrote: post #128

Earlier quoted context omitted.

> Mongo's really great for rapid prototyping. Has any phrase ever struck more fear into the heart of a programmer? Rapid prototypes have a nasty tendency of accidentally becoming products... > You can always switch databases later shudder

That's why you use a language or technology that's politically unfeasible for your rapid prototypes, like Clojure or Haskell, or...for that matter...MongoDB. ;-)

In certain companies, MongoDB is the new hotness. This could very much backfire on you!

Re: The genius and folly of MongoDB

#243

Post by functional_test »

revetkn wrote: post #199
functional_test wrote: post #191

Earlier quoted context omitted.

Literally 1 month ago, I bought a car and did exactly this. What's impractical about spending a little time to read?

> What's impractical about spending a little time to read? It's impractical because people live a finite amount of time and this is a terrible use of it

If understanding your production database is a bad use of your time, then I really don't understand your priorities, but I'm glad you're not on my team.

You don't need to read every word of everything, but some things are worth it. Do you sign contracts without reading them too since it's a "terrible use of" your time?

Re: The genius and folly of MongoDB

#244

Post by Nodex »

All the haters LOL. You're constantly comparing mongodb to an RDBMS. It doesn't claim to be one and if you're ignorant or arrogant enough to think they do then more fool you. As always developers should use THE RIGHT TOOL FOR THE JOB. Mongodb fits this sometimes, RDBMS fits this sometimes, Stand alone search servers ala Solr or ElasticSearch fit this sometimes.... I mean you don't get people constantly trolling the internet because MySQL full text searching is not as good as a Lucene based search do you? - NO you don't because they're different tools.

All you MongoDB haters need to get off the bandwagon because a year ago you were praising them and making money off them when it was trendy to employ someone for having "MongoDB skills".

/Nodex

Re: The genius and folly of MongoDB

#245

Post by byroot »

nostrademons wrote: post #219
byroot wrote: post #176

Earlier quoted context omitted.

Sure you have full permalink support, but why do you have to rely on closure to do pagination ? My guess: because by relying on in-memory data-structures you can't do what any half assed php forum do, ad hoc queries.

I suspect he doesn't have to rely on closures to do pagination: they're a programming convenience that means you don't have to do things like think about what state persists between pages. Anything you can do with SQL you can do with in-memory data structures. If you're interested, I'll be happy to take any SQL query and convert it to some Python list comprehensions on arrays of dicts.

> Anything you can do with SQL you can do with in-memory data structures.

Sure, but unless you also do some indexing manually, you can't really query your whole dataset when it start to become too big.

Re: The genius and folly of MongoDB

#246

Post by functional_test »

vanadium wrote: post #195
functional_test wrote: post #191

Earlier quoted context omitted.

Literally 1 month ago, I bought a car and did exactly this. What's impractical about spending a little time to read?

Your approach is wholly impractical on its face, actually. So, let me get this straight: You laid down tens of thousands of dollars on a vehicle that you only post-purchase read the manual of, and you're raising this as some sort of standard people should follow? Honestly, asking the right questions (and test-driving) upfront should be what lands the purchase, and not discovering the folly of purchasing a car with su…

Turns out you can read the manual of a vehicle ahead of time. Turns out you can also test drive and do everything else you said, and we don't need to pretend that it's all mutually exclusive. Stop being a pedant -- me listing every bit of due diligence about my car isn't relevant, so let's stay on topic.

Honestly, how can people on HN actually be this against reading? Especially things that are really important? Sure, don't read the contest rules for your McDonald's monopoly. But if the data for your livelihood depends on something, there's no excuse for not reading the documentation.

Re: The genius and folly of MongoDB

#247

Post by chris_wot »

aaronem wrote: post #207
edraferi wrote: post #189

Earlier quoted context omitted.

That is awesome.

Also of note is that stored procedures are supported in a variety of languages, including Javascript, so it's quite easy to handle cases where the surprisingly broad range of core JSON functions and operators [1] doesn't include what you need. PostgreSQL has also recently added a key-value store type [2] with semantics reminiscent of Redis. The impression I get is that they're gunning for the NoSQL kids in general, a…

That is extremely interesting. So it looks like you can store a JSON type as well as a KV datatype in Postgres! And it looks like it is relatively easy to convert between the two.

This leaves only performance. I think I'm still confused around this area - why do people say that non-relational technologies like MongoDB are faster than relational databases?

Re: The genius and folly of MongoDB

#248

Post by chris_wot »

leif wrote: post #232
jpgvm wrote: post #165

Earlier quoted context omitted.

This is going to come off as abit negative but I kinda feel it has to be said. I would first like to say I do love the Fractal tree indexing, very cool and could have alot more intesting usecases outside of databases (I'm thinking logical volume/block storage etc.. I'm always thinking in kernel land..) The problem is that Mongo advertised itself as a database and wasn't one. Once you do that reputation of the product…

I've seen a lot of the rest of their code, and most if it is getting better over time, as they grow they're forced to adopt better habits in order to scale their engineering team. I think you're misunderstanding the type of programmers they are. They didn't use mmap because they are sloppy everywhere, they used mmap because their critical innovation was not in storage. What they really thought was valuable, what they…

This post does not inspire confidence. Sorry, has to be said.

Re: The genius and folly of MongoDB

#249

Post by Zak »

functional_test wrote: post #191
clwk wrote: post #187

Earlier quoted context omitted.

Out of curiosity, have you ever bought a car, and did you actually read the whole manual before driving it? It's a nice hypothetical, and that might be your style. Most real-world car purchase scenarios I'm familiar with would make that style impractical.

Literally 1 month ago, I bought a car and did exactly this. What's impractical about spending a little time to read?

That's fairly unusual; modern cars have a fairly standardized user experience such that there aren't many ways for a car to do something surprising and dangerous that's covered in the manual.

I did experience one once though: I discovered that a vehicle had traction control when the system activated during a skid. The computer and I disagreed about the best way to respond, and the surprise did make the situation more dangerous than it could have been.

In both vehicles and databases, the situations in which the product might do something unexpected and dangerous should be clearly documented in their own section of the manual. Databases should say "here are the things that could lead to data corruption or loss". Vehicles should say "here are the situations where the vehicle might disregard or override the driver's control inputs".

Re: The genius and folly of MongoDB

#250

Post by Sanddancer »

jbooth wrote: post #50
yummyfajitas wrote: post #47

Earlier quoted context omitted.

What does mongodb offer above and beyond using postgres or redis for this use case?

I've barely used it, but the json document thing with a lot of random convenience functions in the query language seem to lend themselves well to rapid development. For postgres you'd be mapping to a relational schema, and for redis you'd be storing the json yourself as a blob, without any server-side manipulation capabilities (or using redis maps/sets/etc, which are awesome, but aren't as general as json). I haven't…

Postgres has had a native json type and the latest version improves upon the functions given to manipulate json data. So data that may not map well to a relational schema can just be put in the json object type and handled accordingly. Also, because it's attached to an SQL engine, you can use things like views on your json data if it makes sense for the type of data you're querying.

There has been a considerable amount of work put into postgres over the past few years for getting it to handle your data regardless of what it looks like. The developers seem to have a very good grasp on the fact that not all data is alike, and giving tools that will work well, and together with, all your data leads to a lot fewer headaches in the long run.

Post reply on HN