So what is the new solution? Back to relational? Or another type of document store?
Both, I am waiting for a JSON data type in a relational database where you can index, filter, order, etc on keys.
Goodbye, MongoDB
91–100 of 123 posts
Re: Goodbye, MongoDB
#92How 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
Here's one I noticed: I have a small app running on 2.0.1 and there are _two_ prealloc.X files in the journal directory, each one is 256mb. Not quite 3GB unless my math is wrong. (There's a third file in the directory named `j._0` which is also 256mb)
Re: Goodbye, MongoDB
#93Earlier quoted context omitted.
That's the common pattern. MongoDB is easy and convenient when you first start using it, but you hit the limitations pretty quickly. I had the same experience.
I really think if they had document-level locking, it would be a much more successful DB. 10gen's answer to this is "just shard!!1" except that sharding in Mongo really isn't as easy as they make it out to be...not to mention what database makes you shard just so you can support more than a few hundred writes per second? Maybe this has improved a bunch since I got burned by it on v1.6, but I believe it's very mislead…
Locking in particular has improved substantially since 1.6. For example, 2.0 introduced yielding in some cases where MongoDB would go to disk rather than page-faulting with the lock held[1]. This has been extended and improved for 2.2, along with increasing the granularity of the lock from process-wide to per-db. There are plans to increase the granularity further in future releases.
[1] To see an example of the difference this makes see http://blog.pythonisito.com/2011/12/mongodbs-write-lock.html
Re: Goodbye, MongoDB
#94Earlier quoted context omitted.
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.
What's the hot shit right now then, if not Node?
Re: Goodbye, MongoDB
#95Earlier quoted context omitted.
>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.
What's the hot shit right now then, if not Node?
HTML5 a panacea.
Re: Goodbye, MongoDB
#96Earlier 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.
All developers need to understand the Gartner hype cycle.
Both that and the TAL, they complement each other:
Re: Goodbye, MongoDB
#97Actually, using mmap-ed files is a great idea. It's precisely what Varnish does too.
That was exactly what my thoughts were too: letting the OS do all the memory management, caching, is a strategy many great projects use, among which PostgreSQL and Varnish. However, I do feel there is something "wrong" about the approach MongoDB is taking. They need to allocate new files in huge buffers, which completely take up all I/O while being filled with zeroes. There is no logical hierarchy in the files, and i…
It is a widespread myth that postgresql lets the OS do all the memory management and caching. I don't understand why it is so prevalent though considering it is so trivial to look and see that it is nonsense. Postgresql reads all data into a shared buffer cache. The data is stored in files, so of course the filesystem buffer cache is also used, but the idea that postgresql leaves it entirely up to the OS is totally false. It has its own cache as well on top of the filesystem cache.
Re: Goodbye, MongoDB
#98This is completely unrelated to the subject, and I have not used mongodb, have no idea if it's good or bad, and I don't even know how to spell it, but isn't it ironic that this post shows up on the day when the top HN post's title is "Please learn to write"?
As I said, no idea how good or bad mongo is, but I'm guessing, if you are as sloppy in your code as you are in your English, I'll be happy to give mongo the benefit of the doubt...
Re: Goodbye, MongoDB
#99Earlier 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.
I fully agree here. A couple of years ago, when I went on interviews at startups, they were all using nosql db's and were proud of it. More recently, I've been interviewing at startups that are now bigger, need to mine the data that they've collected over the last few years, and now are migrating off of nosql db's to rdbms' (or creating strange amalgams of the 2). I did see this coming, but it was very hard to make t…
The reality is that developers are maturing in their understanding of different technologies and they are learning how to apply them in correct use cases.
There continues to remain a "golden hammer" syndrome where white horses and unicorns run free, but it doesn't exist.
Instead, the vision of "NoSQL" was to tell developers that they did not have to use relational data for everything, but could, instead, use the right tool at the right time. Why is this such a hard concept?
If you are a developer and you don't understand the tool you are wielding (it's pretty clear the author of this blog didn't), then you will incorrectly use the tool and experience pain.
That is the fault of the developer, not the tool.
Re: Goodbye, MongoDB
#100How 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…
This is what I don't understand.
For me MongoDB and PostgreSQL aren't really playing in the same field. Yes they are both databases. But I wouldn't use PostgreSQL for document storage (the recent JSON addition is pretty weak). Likewise I wouldn't use MongoDB when I need my data to be more structured. I would have no issue using both at the same time.
I guess everyone is looking for that mythical single stack of technologies they can use for every use case.