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

181–190 of 280 posts

Re: The genius and folly of MongoDB

#181

Post by Goopplesoft »

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'd be an unqueryable string field in most sql databases. Not at all the same thing.

Re: The genius and folly of MongoDB

#182

Post by functional_test »

integraton wrote: post #171
berntb wrote: post #156

Earlier quoted context omitted.

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

Generally I'd only have at most 2 formats at once while you converted the older records to the new format. You're right that there's no sense in keeping around a dozen versions but there are a lot of business cases for having two versions of a schema active at once. For example, if you can't bring down your application to convert everything mid-day and instead want to do an incremental conversion.

Re: The genius and folly of MongoDB

#183

Post by bkanber »

rapind wrote: post #178
swanson wrote: post #86

Earlier quoted context omitted.

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

I've been using sqlite more and more as well. Super lightweight, but since it's SQL most ORMs can handle switching to MySQL/postgres really easily if you ever need to make the switch.

Re: The genius and folly of MongoDB

#184

Post by functional_test »

justinsb wrote: post #148
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?

Other databases are forgiving; they are configured "safe", even at the expense of speed. The intention is that you can deploy a small system immediately; if/as you grow you will see that the database is going too slowly. You can _then_ look at the performance/safety dials you can tune and choose appropriate trade-offs. These are systems designed for the real world, where people don't read the manual until they have t…

I'm not sure how anyone else could know what my best interests are. There are a lot of real world applications where small amounts of data loss don't matter but latency matters a lot.

Any time I deploy something as critical as a database, I carefully read about what it does and how it works. Not doing so is like signing a contract without reading it.

Re: The genius and folly of MongoDB

#185

Post by functional_test »

barrkel wrote: post #141
functional_test wrote: post #130

Earlier quoted context omitted.

The file system is great for some things, but, for example, how would you handle the same data to having multiple indices?

Links - both soft and hard.

Wouldn't that become quite a bit of book keeping though?

Re: The genius and folly of MongoDB

#186

Post by justinsb »

functional_test wrote: post #184
justinsb wrote: post #148

Earlier quoted context omitted.

Other databases are forgiving; they are configured "safe", even at the expense of speed. The intention is that you can deploy a small system immediately; if/as you grow you will see that the database is going too slowly. You can _then_ look at the performance/safety dials you can tune and choose appropriate trade-offs. These are systems designed for the real world, where people don't read the manual until they have t…

I'm not sure how anyone else could know what my best interests are. There are a lot of real world applications where small amounts of data loss don't matter but latency matters a lot. Any time I deploy something as critical as a database, I carefully read about what it does and how it works. Not doing so is like signing a contract without reading it.

MongoDB is optimized for Mongo Inc, not for you, not for me.

Re: The genius and folly of MongoDB

#187

Post by clwk »

functional_test wrote: post #179
rdtsc wrote: post #169

Earlier quoted context omitted.

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

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.

Re: The genius and folly of MongoDB

#188

Post by tzury »

joevandyk wrote: post #103
yummyfajitas wrote: post #56

Earlier quoted context omitted.

One viable option: CREATE TABLE mongodb ( key VARCHAR(256) PRIMARY KEY, value JSON );

I'd use a uuid for the key. Also, see https://github.com/umitanuki/mongres Postgresql speaking the mongodb protocol.

from the github page mentioned above:

    This is currently a prototype. The following operations are supported.

    db.collection.find()
    db.collection.insert()
Two methods only, well, that's too little.

Re: The genius and folly of MongoDB

#189

Post by edraferi »

aaronem wrote: post #173
continuations wrote: post #158

Earlier quoted context omitted.

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

That is awesome.

Re: The genius and folly of MongoDB

#190

Post by lowboy »

mdellabitta wrote: post #172
lowboy wrote: post #152

Earlier quoted context omitted.

> 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

Mmhmm. Like I said, that's not good enough for you and for your needs. For other people it's fine. That's important to note.
Post reply on HN