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

81–90 of 331 posts

Re: Don't use MongoDB

#81

Post by mushishi »

itaborai83 wrote: post #59
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'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 two screens so it's hard to reason about; your short-time memory is overused.

Re: Don't use MongoDB

#82

Post by ballard »

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…

Using the risky with ease is cool but it comes with its own expectations.

Re: Don't use MongoDB

#83

Post by einhverfr »

christkv wrote: post #56
antirez wrote: post #26

I appreciate the "public service" intend of this blog post, however: 1) It is wrong to evaluate a system for bugs now fixed (but you can evaluate a software development process this way, however it is not the same as MongoDB itself, since the latter got fixed). 2) A few of the problems claimed are hard to verify, like subsystems crashing, but users can verify or deny this just looking at the mailing list if MongoDB h…

It's good to see a voice of reason. I think we all win if NoSQL is allowed to survive. Having multiple paths to modeling and designing our applications is an enrichment of our ability to create interesting and valuable applications in our industry. The last 10 years have been about living under the modeling constraints of RDBMS's and the industry is slowly waking up to the realization that it does not need to be like…

"Allowed to survive" is the wrong approach. "Finds a niche" is better.

The fact that software engineers need to understand is that NoSQL is in no way a replacement for SQL in areas of data with inherent structure. In such areas, the relational model wins hands-down, and NoSQL is a big, heavy foot-gun. The caliber of the foot gun goes up significantly when multiple applications need to access the same data.

On the other hand, the relational model breaks down in some ways in many areas. Some things that you'd think are inherently structured (like world-wide street addresses) turn out to only be semi-structured. Document management, highly performing hierarchical directory stores, and a few other areas also are bad matches for the relational model. Other stores work well in many of these areas, from the filesystem to things like NoSQL databases.

The big problem occurs when semi-structured data (say files which contain printed invoice data in PDF format) have to be linked to inherently structured data (say, vendor invoices). In these cases, tradeoffs have to be made......

I have no doubt that NoSQL is able to find a niche. I doubt it will be one which at best involves inherently structured data.

Re: Don't use MongoDB

#84

Post by SemanticFog »

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…

You're absolutely right -- RDBMSes were designed to solve problems with the nosql-type approaches that preceded them. The nosql bandwagon is blindly rolling into the past, where it will crash into the old problems of concurrency and consistency under load.

BTW if you want nosql-style schema flexibility within an RDBMS, then a simple solution is to store XML or JSON in in a character blob. Keep the fields you need to search over in separate indexed fields. If you make incompatible version changes, then add a new json/xml field.

Re: Don't use MongoDB

#85

Post by einhverfr »

fauigerzigerk wrote: post #62
vidarh wrote: post #53

Earlier quoted context omitted.

"Schema-less" has the potential (if you use it properly) advantage of allowing gradual migration. As long as your code can handle all versions of objects in current use, you can deploy new code, then either migrate objects as they're updated/rewritten, and/or slowly migrate objects in the background. For certain types of schema changes in large enough data stores, this can be a killer feature. I remember one RDBMS se…

"Schemaless" most of the time means "code based schema". Dealing with multiple schema versions at the same time is always possible, relational or not, but it causes significant bloat and complexity. When I hear gradual migration I think code decay, but I can see why it could be useful sometimes. In my view, schemaless models are only desirable if the schema is not known until runtime, e.g. user specified fields or me…

Well, also there is the issue of highly unstructured data. In LedgerSMB, we put it in PostgreSQL along with highly structured data, and just use key-value modelling. These include things like configuration settings for the database in question and the specifics about what a menu item does. I might migrate some of this to hstore in the future (particular the menus).

There are many shortcomings of this approach but when dealing with highly unstructured data (or basically where the inherent structure is that of key/value pairs) it strikes me as the correct approach, and not different really from using NoSQL, XML, or any other non-relational store.

Re: Don't use MongoDB

#86

Post by einhverfr »

latch wrote: post #73
angelbob wrote: post #44

Earlier quoted context omitted.

And yet he makes some good points. Pretty much all of this is verifiable. I don't agree with a lot of his conclusions, but mostly his data is correct.

Look, I'm not the best person to do this..but...good points? 1 - Default writes are unsafe by default: MongoDB supports a number of "write concerns": * fire-and-forget or "unsafe" * safe mode (only written to memory, but the data is checked for "correctness", like unique constraint violations) * journal commit * data-file commit * replicate to N nodes The last 4 can be mixed and matched. Most (all?) drivers allow thi…

"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 do not know. I just know I have been bitten by deadlocks in multi-row inserts quite often there enough to get really really frustrated when I use that db. This is in fact documented in the MySQL manual.

For better or worse, projects which start out without a goal to offer highly reliable software from the start never seem to be able to offer it later.

Re: Don't use MongoDB

#87

Post by deoxxa »

goldmab wrote: post #78
vidarh wrote: post #53

Earlier quoted context omitted.

"Schema-less" has the potential (if you use it properly) advantage of allowing gradual migration. As long as your code can handle all versions of objects in current use, you can deploy new code, then either migrate objects as they're updated/rewritten, and/or slowly migrate objects in the background. For certain types of schema changes in large enough data stores, this can be a killer feature. I remember one RDBMS se…

Fair enough, but you can also have a schemaless store by using JSON fields in PostgreSQL or MySQL.

That's not an unfair comparison at all - indexing the data in a JSON blob is entirely possible and practical.

Re: Don't use MongoDB

#88

Post by latch »

einhverfr wrote: post #86
latch wrote: post #73

Earlier quoted context omitted.

Look, I'm not the best person to do this..but...good points? 1 - Default writes are unsafe by default: MongoDB supports a number of "write concerns": * fire-and-forget or "unsafe" * safe mode (only written to memory, but the data is checked for "correctness", like unique constraint violations) * journal commit * data-file commit * replicate to N nodes The last 4 can be mixed and matched. Most (all?) drivers allow thi…

"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"

Re: Don't use MongoDB

#89

Post by felix_krull »

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…

this is the implementation of a b+ tree. the underlying logic has been very well researched since the 70s.

if there is a part of mongodb that I am sure does not contain bugs, it is that very file you link to.

if you want to know what it does, go out and read the relevant papers on data base technology. or graduate in CS.

Re: Don't use MongoDB

#90

Post by bborud »

CarlHoerberg wrote: post #46
jonpaul wrote: post #30

I've used MongoDB in production since the 1.4 days. It should be noted that my apps are NOT write heavy. But, many of the author's points can be refuted by using version 2.0. Regarding the point of using getLastError(), the author is completely correct. But the problem is not so much that MongoDB isn't good, it's that developers start using it and expect it to behave like a relational DB. Start thinking in an asynchr…

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.
Post reply on HN