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

211–220 of 280 posts

Re: The genius and folly of MongoDB

#211

Post by nostrademons »

rsynnott wrote: post #128
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…

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

Re: The genius and folly of MongoDB

#212

Post by nostrademons »

dboat wrote: post #157
bkanber wrote: post #96

Earlier quoted context omitted.

I feel the opposite way. If your application's data layer is sensibly designed, it shouldn't be too bad to switch to postgres when you need to. It may be tedious if you have a large codebase, but it won't be difficult . I think the up-front benefits of using mongo (especially as a sole developer/devops/sysadmin person) outweigh the difficulty of the changes you'll need to make later on, which will only happen as you…

This prototyping story sounds to me like admittedly shooting yourself in the foot if your prototype turns out to be worth a damn. Basically, you're saying mongo is an excellent choice only when your storage backend is a moot point. I can't think of any codebases I've seen where intentionally choosing the storage backend you know you don't want to use (if the project is successful) would be a reasonable thing to do. U…

The advantage of shooting yourself in the foot if your prototype turns out to be worth a damn is that it forces you to rewrite it with more rigorous development practices ASAP. Usually, choice of a storage engine isn't the only problem with a throwaway MVP - you've probably written it in a language that won't scale, and skimped on error handling, and are using really inefficient algorithms, and didn't bother documenting anything.

That said, I would use PostGres for my MVPs, using it as a key-value store initially until its more clear what the schema should be. That is, if I still bothered using code for prototypes; of late I've been more fond of napkins and Adobe Fireworks.

Re: The genius and folly of MongoDB

#213

Post by dsaber »

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…

Note that even with the changed default to 'acknowledged', data is not guaranteed to have been written to the journal. So, there is still no full durability in writes (by default) and there is a chance data might be lost (e.g. a mongod instance crashes).

Re: The genius and folly of MongoDB

#214

Post by tracker1 »

chaffneue wrote: post #139
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…

And it's not even good or recommended as a cache at any kind of profile. So I guess their most valuable niche is low traffic/prototype sites with poor architecture discipline or genuinely unrelated data sets. There are so much better tools for caching (memcached/redis), durable persistent storage (postgres), session storage (memcached/redis/browser hybrids) and document storage (postgres). Mongo is just one of those…

I think being able to have flexible data storage with indexing is where they are better than most other options. There's something to be said for some of what they do offer. I was able to replace the search system for a site that used SQL to MongoDB, which often includes geolocation, it works fairly well, I had considered using a ElasticSearch, or something similar, Mongo was a better fit.

Today, I would be inclined to use PostgreSQL with JSON support, and some triggers to update an aggregate search table, or look more seriously towards RethinkDB.

With any NoSQL system you give up something.. you just need to be aware of what you are giving up, why and for what gains.

Re: The genius and folly of MongoDB

#215

Post by berntb »

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…

As functional_test said. Also note that this e.g. depends on how long lived your data is.

(An update routine can be run at any point with low use like Xmas, etc. This is potentially neat, depending on use statistics.)

I'm not saying this is a common thing, but the lack of joins makes the data a bit more flexible -- this can't be too much, if nothing else because then the Javascript will begin to break.

(I do think there are much more use cases for nosql than as a Memcached with more features. Where an old job used MongoDB wasn't one.)

Re: The genius and folly of MongoDB

#216

Post by nostrademons »

philwelch wrote: post #78
nostrademons wrote: post #46

Earlier quoted context omitted.

What's wrong with the Viaweb/Arc/HackerNews/Mailinator approach of just using in-memory datastructures (hashtables, linked lists) and then journaling out changes to the filesystem as records that are read in on startup? It's incredibly simple and blindingly fast as long as you stay on one server, and you can get several thousand QPS of capacity on that one server (vs. like 10 with a Django/Rails + SQL database soluti…

> It's incredibly simple and blindingly fast as long as you stay on one server and you can get several thousand QPS of capacity on that one server (vs. like 10 with a Django/Rails + SQL database solution). Wait, what? Even if vertical scaling was a good idea, scaling is far from the only reason you should have more than one server for anything serious.

Isn't this thread about non-serious use? Pretty much everything I see here is about how MongoDB is only suitable for prototypes, how it doesn't even guarantee writes, how they just want something quick & dirty to build a MVP with. The parent poster asked for something to replace MongoDB with - if the use-case is prototypes and "web scale" startups that don't have users or a product yet, I think a single server with in-memory data structures is a perfectly adequate starting point.

If you do get to the point where you need some redundancy (and don't yet need to scale horizontally), you can proxy all writes to a second server running the same codebase, have it update its in-memory data structures in the background, and hot-swap it over if the master dies.

Re: The genius and folly of MongoDB

#217

Post by icelancer »

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…

>When people assume MongoDB was similarly designed with their best interests in mind, that's when things go wrong.

No, I just assume that a database has a similar set of features as other databases have had for decades. Mongo does not; it is clearly the exception - and for possibly nefarious reasons, as well.

Re: The genius and folly of MongoDB

#218

Post by nostrademons »

rsynnott wrote: post #140
nostrademons wrote: post #64

Earlier quoted context omitted.

Well, that's of course true. All engineering systems face trade-offs. The nice thing about doing the dead simple solutions first is that they give you time to focus on the things all startups have to do (getting users, building product) and then fall down at the the things that very few startups have the luxury of needing to deal with (scaling, fault tolerance, reporting, alternative views of data). Throughout the li…

Leaving aside the issue of scalability (generally, by the time you find out that you need to scale up, it's already almost too late if you haven't had being able to scale up in the back of your mind all along), there are other reasons that you don't necessarily want to commit to a solution that makes it difficult to use more than one machine; availability is the obvious one.

I think most people who have never worked for a very fast-growing company grossly underestimate the number of rewrites that it will require anyway. You are not committing to a solution that makes it difficult to use more than one machine; you are trying to get to the point where you need to replace that architecture. Pretty much all your other architectural choices will be bad ones at that point anyways.

Re: The genius and folly of MongoDB

#219

Post by nostrademons »

byroot wrote: post #176
pg wrote: post #101

Earlier quoted context omitted.

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.

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.

Re: The genius and folly of MongoDB

#220

Post by ahoge »

JulianMorrison wrote: post #118
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…

Have you considered RethinkDB? For most of the advantages of MongoDB that don't specifically come from mmap and overwrite-in-place, it's an equal or better.

RethinkDB still doesn't support Windows. [1]

Most developers who use Windows will just go with something which doesn't require a virtual machine. For example, MongoDB, CouchDB, OrientDB, Cassandra, and ArrangoDB work fine everywhere.

[1] https://github.com/rethinkdb/rethinkdb/issues/1100

Post reply on HN