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

Goodbye, MongoDB

zopyx.de

Post reply on HN
Print view View original

81–90 of 123 posts

Re: Goodbye, MongoDB

#81

Post by moe »

rbrcurtis wrote: post #45
jasonmccay wrote: post #36

Earlier quoted context omitted.

There are fairly straight-forward ways to control memory usage in MongoDB, especially if this is a concern for you. All you need is a bit of OS know-how and it works just fine. We run both large (multi-shard clusters) and small memory (500MB - 2GB) use instances of MongoDB and have no problems. It would be good to have developers acknowledge that, perhaps, they may not have all the information instead of declaring th…

Care to explain how, say in linux?

Either jason has something really interesting up his sleeve or he simply doesn't know what he's talking about.

Last I checked linux had no interfaces to partition the pagecache in a meaningful way, short of rather extreme gymnastics involving kernel-patches or tmpfs abuse.

If that has changed then I'd certainly also be curious to hear about it.

Re: Goodbye, MongoDB

#83

Post by jshen »

dlokshin wrote: post #51

I feel like 1 - 2 years ago I was reading a slew of blog posts with the title "Why We Chose MongoDB." Now it seems like all of the blog posts are some sort of "We Just Finished Migrating off of MongoDB, Here's Why." I know nothing about MongoDB and have never tried it. But the message seems pretty clear.

I wouldn't draw any conclusions based on the hive mind of social media story up-voting.

Re: Goodbye, MongoDB

#84

Post by macspoofing »

nchuhoai wrote: post #68
ax wrote: post #53

Earlier quoted context omitted.

The message is, just like every technology, there's an initial period where a vocal minority loves it and tries to use it for everything. Then, there's a backlash where a vocal minority hates it and thinks anyone who uses it is clearly an idiot. All the while, the silent majority go on getting work done. It's been this way for as long as I can remember.

Love it. I think Node is the hot shit right now, and Rails is starting to get into the hate-period. It's really just hipsters and music. We are all really just hipsters.

>I think Node is the hot shit right now, and Rails is starting to get into the hate-period.

I think you're about two years behind. Node is starting its hate-period. Rails got it a year or two ago.

Re: Goodbye, MongoDB

#86

Post by flippyhead »

mitchitized wrote: post #58

How tiring. We can litter the internet with posts like this, but it would be a lot more useful to post reasoned, factual and detailed posts when discussing the merits or pitfalls of a given technology. I've launched very high traffic websites using MongoDB, where it was the least of my worries. I've also launched very high traffic websites using MySQL, where it was my primary source of pain. Shall I now run around sc…

would love to hear specifically what was factually incorrect

Re: Goodbye, MongoDB

#87

Post by bunderbunder »

gfodor wrote: post #65
bunderbunder wrote: post #61

Earlier quoted context omitted.

It's just the standard Internet hype cycle. I'm guessing within the next year we're going to see a similar backlash against Hadoop as people who rush to it begin to discover that map/reduce isn't necessarily the best distributed processing model for their needs. This despite Hadoop continuing to be the effective (non-silver) bullet it's always been.

Meh, Hadoop is much older than MongoDB, is an offline system, and doesn't destroy your data. There is also not much in the way of alternatives. I'm skeptical we will see many "we're switching off of Hadoop" posts anytime soon. That said, there is an growing undercurrent in the Clojure community to roll your own map reduce system instead of using Hadoop.

There's quite a bit in the way of alternatives. Sector/Sphere, Xgrid, and PVM come to mind. Sector/Sphere is perhaps the most direct alternative since it comes with its own distributed filesystem, but if you don't need a full-fledged DFS then the others are worth looking at too.

The main thing that really distinguishes Hadoop is that it's built to only do one kind of distributed processing. In exchange for asking you to don that straitjacket it offers ease of use. However, if your problem isn't naturally a map/reduce problem, or if your main performance bottleneck isn't disk I/O, then the alternatives become a lot more attractive.

Re: Goodbye, MongoDB

#88

Post by macspoofing »

petercooper wrote: post #74

using JSON as a query language was a bad decision. The current JSON query language works for standard queries but the functionality of the operators is limited. These two things don't go hand in hand. JSON could be used to elegantly represent complex queries. A problem with the query system isn't necessarily a problem with JSON.

>JSON could be used to elegantly represent complex queries

I think it could be used to represent complex queries, I don't think elegantly would be it. I'm thinking it would be a small step up from an XML representation.

Re: Goodbye, MongoDB

#89

Post by dinedal »

mark_l_watson wrote: post #66

It seems like ranters against MongoDB often don't really understand how it works and thus what it is good for. My simple mental model for MongoDB is: indices (should!) fit in memory and documents are stored contiguously on disk. That is it in a nutshell. A query involves in-memory lookups and maybe only one disk seek. Writes in place are usually possible. I have been happiest with MongoDB in two different scenarios:…

You mention two different scenarios that use MongoDB effectively, and both are not what MongoDB purports it's supposed to be used for.

The first is a small setup. MongoDB is called that because it's supposed to be for "humongous" data sets. Also, in what case is 3GB of data preallocated for journalling, which is one of the points in the article, good for a small installation?

The second is "modestly" sized stream of social media data. Having myself worked with a much larger stream of social media data in Mongo, I can attest that the second you leave the land of a single Mongo server, you have a much bigger problem, sharding. Sharding is terrible in Mongo, writes are shard locked, not collection, your shard keys are immutable (imagine having an indexed field you can only set ONCE), and fraught with data loss. Did you have a drop in network connectivity between your mongos and you config server? You just silently lost data. Safe being on doesn't matter, if the config server doesn't get the write it isn't able to report where the data is for a read, even if it is confirmed it was written to disk.

To your point about mongo ranters not understanding what it's good for, MongoDB tells everyone it's good for "big" and "fast" data. However, it fails at both of these, because it doesn't easily scale up from one node, and it doesn't write quickly when you actually want to make sure that your data is there. What's the point with writing data quickly to something that looses it quietly? Might as well pipe it to /dev/null/

Re: Goodbye, MongoDB

#90

Post by dazoot »

We started out with just MySQL. Then added MongoDB + replicasets. Then added Cassandra. And now we just finished adding Elastic Search. All of this for the same Web Application. Use the right tool for the job. The pattern i've noticed is that indeed we started migrating DATA out of MongoDB, mostly to Cassandra.
Post reply on HN