The genius and folly of MongoDB • Hacker News Board

Re: The genius and folly of MongoDB

#171

Post by integraton » Mon, Oct 21, 2013, 1:32 AM UTC

berntb wrote: post #156

integraton wrote: post #144

Earlier quoted context omitted.

> Do you always start with the perfect data structure? I find myself adding, removing, and restructuring schema often. Which is why it doesn't make any sense to claim that using MongoDB somehow eliminates needing to migrate your data as it evolves.

That is easiest [cough, imho] solved with adding a version number to stored records. Since data is not in much of a normal form and there won't be that many joins, it generally is easy to handle in code. Sometimes you have to do update of records with a certain version number. My opinions, for the record: MongoDB is a tool with some use cases. I'm more of an SQL+Memcache guy, if possible, but not religiously if a goo…

If you make 12 schema changes in month 1 and then no schema changes for the next year, does it really make sense to keep a month's worth of data in 12 different formats and maintain code to support all of the different versions? Why not just do a simple schema change and/or data migration each time and be done with it?

And since this is supposed to aid in rapid prototyping, how does it do so? It seems to me that it does just the opposite by introducing a significant and totally unnecessary burden.

Re: The genius and folly of MongoDB

#172

Post by mdellabitta » Mon, Oct 21, 2013, 1:35 AM UTC

lowboy wrote: post #152

mdellabitta wrote: post #124

Earlier quoted context omitted.

> database level lock But that's not anywhere close to good enough.

> But that's not anywhere close to good enough for me FTFY

> But that's not anywhere close to good enough for concurrent, multiuser systems with reasonable traffic.

FTFY

Re: The genius and folly of MongoDB

#173

Post by aaronem » Mon, Oct 21, 2013, 1:35 AM UTC

continuations wrote: post #158

rgo wrote: post #77

Previous versions of my startup's enterprise product used to be based on relational DBs (mostly Oracle, MySQL also). This year we switched to Mongo and dropped RDBMS support. RDBMS performance was fine most of the time as we're not doing big data really. Our problem was developing and maintaining a schema that holds lots of metadata many levels deep. Our app allows for unlimited user defined forms and fields, some of…

> Having a schemaless, easy to manage database is a step forward for sooo many use cases Can you explain why can't you do schemaless with an RDBMS? From what I understand MongoDB is schemaless by storing all fields as one single JSON document. So what stops you from doing the same in an RDBMS - have a catch-all field "JSON" and store all your data there?

That gets you halfway there, but you still don't have the ability to query your datastore by structure, unless you've installed PostgreSQL 9.3 and are using its JSON field type, which does have that capability, thus entirely demolishing the NoSQL USP as far as I can determine.

Re: The genius and folly of MongoDB

#174

Post by taspeotis » Mon, Oct 21, 2013, 1:35 AM UTC

functional_test wrote: post #126

rdtsc wrote: post #106

The problem with MongoDB is their shadiness. The shipped with unacknowledged writes up until not too long ago. In other words you would write to it and there wouldn't be an ok or fail response, you'd just sort of hoped it would go in. They fixed that problem but it was too late. In my eyes they proved they are not to be trusted with data. Had they called themselves MangoCache or MongoProbabilisticStorage, fine, can s…

I understand some of the reasons people didn't like Mongo, but this always vexed me. The default write level was very clearly documented and you could always change it as necessary. Surely it would be necessary to read the documentation of a database before rolling it out to production?

> I understand some of the reasons people didn't like Mongo, but this always vexed me. The default write level ... Surely it would be necessary to read the documentation

I don't have much sympathy for people who can't RTFM but storing data is kind of a thing for databases.

Re: The genius and folly of MongoDB

#175

Post by Stealth- » Mon, Oct 21, 2013, 1:45 AM UTC

rdtsc wrote: post #169

functional_test wrote: post #126

Earlier quoted context omitted.

I understand some of the reasons people didn't like Mongo, but this always vexed me. The default write level was very clearly documented and you could always change it as necessary. Surely it would be necessary to read the documentation of a database before rolling it out to production?

> Surely it would be necessary to read the documentation of a database before rolling it out to production? You buy a car. It comes with brakes disabled because for whatever reasons that also lets it get to a higher top speed. You are expected to read you car owner manual and on page 54 you find that you have to hold "enable brakes" button under the console for 10 seconds to turn on your brakes. Would it vex you that…

I believe the write concern default is under the responsibilities of the driver -- not the Mongo Daemon.

Re: The genius and folly of MongoDB

#176

Post by byroot » Mon, Oct 21, 2013, 1:59 AM UTC

pg wrote: post #101

byroot wrote: post #100

Earlier quoted context omitted.

> What's wrong with the Viaweb/Arc/HackerNews/Mailinator approach of just using in-memory datastructures https://news.ycombinator.com/x?fnid=cjVXpi8HxVR5TTze3bqSCa Unknown or expired link. Oh I remember now...

That's caused by using closures to create dynamically generated "callbacks" on the server, not keeping data structures in RAM. If you ask for some old item not in memory, it just gets lazily loaded.

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.

Re: The genius and folly of MongoDB

#177

Post by the1 » Mon, Oct 21, 2013, 2:00 AM UTC

nawitus wrote: post #31

So, what's a good NoSQL database for e.g. node.js use? The only alternative I know of is CouchDB. (Yes, I should give more parameters about the intended use, but I really don't know any alternatives).

ejdb or solr.

Re: The genius and folly of MongoDB

#178

Post by rapind » Mon, Oct 21, 2013, 2:02 AM UTC

swanson wrote: post #86

bkanber wrote: post #84

I posted this further down the thread, but I thought I'd share my thoughts on why I like mongo. Most people don't like mongo because 10gen gives the impression that mongo is better than it actually is, many people feel that mongo is not reliable enough for at-scale applications. They're right; it's not. But that's ok, because: Mongo's really great for rapid prototyping. You don't need to worry about updating the sche…

Couldn't you argue that e.g. Postgres and ActiveRecord give you the same rapid prototyping ability but with an easier (and more established) path towards scalability? It is easy to change your schema with migrations at the beginning of a project - just go edit the original ones and nuke your database. And I don't have to worry about properly configuring write-locks, replica sets, or writing map reduce javascript.

Actually postgres can be a bit of a PITA, but so can mongo. At the risk of sounding reckless, unless the app needs to support high CUD throughput I sometimes opt for sqlite. Doesn't get much easier than that and it's read performance is impressive from what I've seen.

Even then you can sometimes get away with staying on sqlite for your admin side CRUD and redis for the heavy / concurrent writing from the public facing side (obviously situational).

Re: The genius and folly of MongoDB

#179

Post by functional_test » Mon, Oct 21, 2013, 2:15 AM UTC

rdtsc wrote: post #169

functional_test wrote: post #126

Earlier quoted context omitted.

I understand some of the reasons people didn't like Mongo, but this always vexed me. The default write level was very clearly documented and you could always change it as necessary. Surely it would be necessary to read the documentation of a database before rolling it out to production?

> Surely it would be necessary to read the documentation of a database before rolling it out to production? You buy a car. It comes with brakes disabled because for whatever reasons that also lets it get to a higher top speed. You are expected to read you car owner manual and on page 54 you find that you have to hold "enable brakes" button under the console for 10 seconds to turn on your brakes. Would it vex you that…

I would also read the manual of a car I just bought before driving it. I guess that's just my style.

Don't get me wrong, I'm not saying your assumption is unreasonable. But in the end, it's on you as a conscientious developer to read the documentation. I'm not even suggesting cover to cover - in this case though they are very up front about write concerns. There is no real excuse to find this out any other way, it's just negligence.

Re: The genius and folly of MongoDB

#180

Post by danbmil99 » Mon, Oct 21, 2013, 2:17 AM UTC

I feel like the discussion of MongoDB is a bit like the discussion around the Affordable Care Act (aka "Obamacare"). The conversation always shifts between whether the very idea of a noSQL db is a good one, to the question of Mdb's implementation faults and (I guess?) its strengths.

Whether 10gen are vapid spin-meisters or not, even whether they have developed a usable product, seems orthogonal to the question as to whether a schemaless persistent storage layer might be a better fit for some projects than a relational database.