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

Don't use MongoDB

pastebin.com

Post reply on HN
Print view View original

91–100 of 331 posts

Re: Don't use MongoDB

#91

Post by einhverfr »

jacques_chester wrote: post #71
christkv wrote: post #55

Earlier quoted context omitted.

I think the discussion here also misses an important aspect of the conversation which is about application data modeling. Mongo will sooner or later reach a "stable" level as it matures just as mysql, postgres and all other datastores have done. I picked mongo due to the good fit it had to the problems I needed solved not only from the server perspective but from the modeling perspective. The ease of ad-hoc queries a…

These are not new approaches to data modelling. Document databases, network databases and hierarchical databases (IMS, CODASYL etc) predate relational databases by decades. Relational is the universal default for a simple reason. When first introduced it proved to be far better, in every conceivable way, than the technologies it replaced. It's as simple as that. Relational is a slam-dunk, no-brainer for 99.99% of use…

First, the more I have looked, the more I have found that non-relational database systems are remarkably common and have been for a long time.

The relational model is ideal in many circumstances. However, it breaks down in semi-structured content, content where---parentheses for grouping---(hierarchical structure is important, data is seldom written and frequently read, and where read performance navigating the hierarchy is most important) and so forth.

So I'd generally agree, but not every problem is in fact a nail.

Re: Don't use MongoDB

#92

Post by [deleted] »

mushishi wrote: post #81
itaborai83 wrote: post #59

Earlier quoted context omitted.

I'm curious and I might be missing more than half of my brain. Would you be willing to show some examples of bad coding on their source tree?

I haven't ever used MongoDB but got interested, and first non-trivial source file I picked is this: https://github.com/mongodb/mongo/blob/master/db/btree.cpp Take a look at for example: bool BtreeBucket ::find Without even thinking about what it is doing, it's quite clear that it is not readable code, and it's not immediately obvious what the high level structure of the logic is. The function does not even fit into t…

[deleted]

Re: Don't use MongoDB

#93

Post by einhverfr »

latch wrote: post #88
einhverfr wrote: post #86

Earlier quoted context omitted.

"This is a good verifiable point? I remember using MySQL cluster when it first shipped. That was a disaster. I also remember using MySQL from a .NET project and opened up a good 3-4 separate bugs about concurrency issues where you could easily deadlock a thread trying to pull a connection from the connection pool." You can STILL deadlock a transaction against itself in MySQL w/Innodb. How do they let this happen? I d…

I've also seen a lot of SQL Server developers write large stored procedures that manage to easily deadlock. It's been years since I dealt with it...had something to do with lock escalation, from a read lock to an update lock to an insert lock. You could say "don't use SQL Server"..or you could say "it's important that you understand SQL Server's locking behavior"

It's one thing for two transactions to deadlock against eachother. It takes special talent to allow a transaction to deadlock against itself, which InnoDB apparently allows.

I have NEVER had issues with PostgreSQL transactions deadlocking against themselves, even with monstrous stored procedures.

Re: Don't use MongoDB

#94

Post by bborud »

libria wrote: post #42
donpark wrote: post #24

Burden of proof is on 10gen, not frustrated customers. This post is believable enough for me to avoid using MongoDB for write-heavy apps.

What if it's not a frustrated customer but a libelous, frustrated competitor instead?

Does it matter?

As a user of MongoDB and Cassandra I am very interested in the sort of discussion that comes out of such postings.

Re: Don't use MongoDB

#95

Post by rapind »

bborud wrote: post #90
CarlHoerberg wrote: post #46

Earlier quoted context omitted.

Schema-less is imho a overrated feature. ORMs like DataMapper (Ruby) and NHibernate (.NET) can generate the schema on the fly for RMDBS, so no need for migrations pre-production. But when your application is in production you need migrations even with a "schema-less" db! See, rename a field and "all your data" is lost, unless you migrate the data from the old field to the new one..

ORMs are a pain to use. In addition to know the domain you need to map from and the domain you map to, you now also have to understand the mapping process.

The same should be said for ODMs as well. A document might be a little more straightforward to map to an object but there is still plenty of miss-match.

Re: Don't use MongoDB

#96

Post by Goldcap »

electic wrote: post #32
jdagostino wrote: post #25

Earlier quoted context omitted.

what did you end up going with?

Our company is a big data company. So our amazing engineers are responsible for storing hundreds of millions of pieces of data per week AND also crunching and analyzing that data. So basically we need a system where we can have incredible write and read performance but also a system that is elastic in nature. Most importantly, it has to be available. Before I go into more details, MongoDB is great for most people who…

Just reading about your transactional volume, it seems like at it's face MongoDB wouldn't be a good fit for this project. 30k per second is not anywhere MongoDB pretends to live, I think by their own admission. And Sharding in MongoDB, while being called a core feature, was bolted on after core development, probably intended to give Mongo some credibility with those who want it to be more scalable. IMHO if you need that kind of scalability, you're already straying from the Mongo Niche, 2.0.0 notwithstanding.

So agreeing with a point earlier, if you don't like a write lock implementation, and have concerns about scaling, and have a huge transactional volume, just really not something that fits well with MongoDB.

I've been using Mongo now (currently using 1.8) for three (is it almost three now?) years, 2 million hits/day, with a replicated set, and while I've needed maintenance, reindexing, and (gasp) restarts on occasion, never had any of the problems identified by the author of this post.

Bottom line, sounds to me like someone was in over someone's head from an architectural standpoint, made a bad choice of MongoDB, and then blamed 10gen for his own lack of foresight. So while I empathize with the struggle, I fault him for not knowing his options in advance, TESTING first, then betting the farm on a fairly new opensource codebase.

LOTS of other database solutions that would scale better. Analyzing lots and lots of transactional stateless data with MongoDB map-reduce? Well, just kinda like killing yourself by trying to sprint up from the bottom of the Grand Canyon. "You really tried to do that?"

Re: Don't use MongoDB

#97

Post by zobzu »

I've had similar performance in my use case (big joins and very large tables) using PostgreSQL (in my case) and disabling sync() to disk, and tuning the buffers, as with the various NoSQL I tried.

It seems to me that NoSQL does not really bring speed. Just scalability and a different model. Hopefully most of them don't lose data at random. PG certainly doesn't, even with sync() off.

I have not tested the scalability of PG.

Re: Don't use MongoDB

#98

Post by einhverfr »

mechanical_fish wrote: post #75
enneff wrote: post #19

Earlier quoted context omitted.

> Should I write a post "don't use MySQL?" There have been plenty.

I assure you that, back when MySQL was the same age as Mongo is today, "don't use MySQL" was conventional wisdom... among those who could find and afford Oracle DBAs. ;) (Though there weren't a lot of blog posts about it, because the word blog had not been invented yet; blogs developed along with... MySQL.) It will be interesting to watch Mongo as it matures over the next ten years. Unlike MySQL, it is competing agai…

"Don't Use MySQL" still should be conventional wisdom.

Indeed it's the only database system I have ever used where a system with a single transaction running only multi-row inserts into a table can (and frequently does) deadlock against itself. Don't get me wrong, time was when it was easier to use than PostgreSQL but that time is long since passed.

One area I have continued to recommend MySQL has been in areas of content management but to be honest in many of these areas, NoSQL is actually a better fit.

Re: Don't use MongoDB

#99

Post by latch »

rapind wrote: post #95
bborud wrote: post #90

Earlier quoted context omitted.

ORMs are a pain to use. In addition to know the domain you need to map from and the domain you map to, you now also have to understand the mapping process.

The same should be said for ODMs as well. A document might be a little more straightforward to map to an object but there is still plenty of miss-match.

I'll agree with this. Document stores don't solve the object-relational impedance mismatch, but they do help (and personally, I find they help more than "a little").

Re: Don't use MongoDB

#100

Post by drdaeman »

foobarbazetc wrote: post #47

No shit, nmongo. Anyone with half a brain can go look at the MongoDB codebase and deduce that it's amateur hour. It's start up quality code but it's supposed to keep your data safe . That's pretty much the issue here -- "cultural problems" is just another way of saying the same thing. Compare the code base of something like PostgreSQL to Mongo, and you'll see how a real database should be coded. Even MySQL looks like…

I've opened the source code (at Github), but didn't really understood it. The code seems readable, though.

Do you care to provide some examples for those not familar with proper C++/Boost development practices, please?

Post reply on HN