Wow there's a lot of Mongo hate in this thread all from one article. Yesterday MongoDB was the darling of HN and today it has to be defended from ridiculous claims. Why the mob attitude? Have you all had these issues?
Failing with MongoDB
111–120 of 128 posts
Re: Failing with MongoDB
#112Earlier quoted context omitted.
Good question -- as far as new, mature NoSQL solutions on the scene, I just became aware of OrientDB which sort of baffles me with it's functionality. It looks like this amazingly functional blend of MySQL and NoSQL: http://www.orientechnologies.com/orient-db.htm Other than that, I actually think these solutions have been stabilizing exactly because of what you say: innovation is slowing down/stalling. 1-3 years ago…
The problem with Cassandra is you never believe the responses to your queries..... until it is too late.....
Uhh, I didn't realize that was a "thing" with Cassandra, is there a bug # to track for any issues specifically or are you saying that it has a history of reporting "Okey Dokey!" to a PUT when in reality it just exploded and died?
I've not messed with Cassandra in production so I haven't seen such a thing yet.
Re: Failing with MongoDB
#113Earlier quoted context omitted.
So what's the preferred alternative noSQL wise? MongoDB is flaky. CouchDB is a maintainability nightmare, so I hear. Riak? Cassandra? Or does everything else have some other equally huge down-side?
Many are moving to Neo4j, including some of the major social networks.
Ahh good catch, I forgot about Neo4j. I'd like to see some non-graph deployments on it and see how it performs. From what I've seen with social/networked data models it looks very compelling.
Excited to see that DB get more and more traction.
Re: Failing with MongoDB
#114Earlier quoted context omitted.
Good question -- as far as new, mature NoSQL solutions on the scene, I just became aware of OrientDB which sort of baffles me with it's functionality. It looks like this amazingly functional blend of MySQL and NoSQL: http://www.orientechnologies.com/orient-db.htm Other than that, I actually think these solutions have been stabilizing exactly because of what you say: innovation is slowing down/stalling. 1-3 years ago…
The problem with Cassandra is you never believe the responses to your queries..... until it is too late.....
Nobody reads Homer anymore.... Or even Virgil.....
Re: Failing with MongoDB
#115Earlier quoted context omitted.
Good question -- as far as new, mature NoSQL solutions on the scene, I just became aware of OrientDB which sort of baffles me with it's functionality. It looks like this amazingly functional blend of MySQL and NoSQL: http://www.orientechnologies.com/orient-db.htm Other than that, I actually think these solutions have been stabilizing exactly because of what you say: innovation is slowing down/stalling. 1-3 years ago…
The problem with Cassandra is you never believe the responses to your queries..... until it is too late.....
I should have said "until it is too late.... and you have gone down in flames due to a trojan horse...."
Alternatively "I understand Cassandra is a Trojan. Can anyone confirm this?"
Re: Failing with MongoDB
#116Earlier quoted context omitted.
Have there been any new entrants in the last few years? Seems like innovation has stalled a bit and stabilization / improvement hasn't caught up yet.
Good question -- as far as new, mature NoSQL solutions on the scene, I just became aware of OrientDB which sort of baffles me with it's functionality. It looks like this amazingly functional blend of MySQL and NoSQL: http://www.orientechnologies.com/orient-db.htm Other than that, I actually think these solutions have been stabilizing exactly because of what you say: innovation is slowing down/stalling. 1-3 years ago…
DBMS can't lose data. This is supposed to be the first commandment of any storage system leaving performance, CAP, and all other considerations out of this.
Re: Failing with MongoDB
#117Earlier quoted context omitted.
The the data model contributes to it's popularity. A document store with indexes on document fields is very convenient for several types of applications.
You can do exactly the same document store with indexes on any RDBMS.
Yup. See http://bret.appspot.com/entry/how-friendfeed-uses-mysql for an example. MongoDB is more convenient to program because it's all built-in.
Re: Failing with MongoDB
#118Earlier quoted context omitted.
Well here's a fuck you back from a dev: my time is finite and everyone wants a piece of it; If I can save an hour a day by never having to think about my database? If I can shave a week or two of labor off a project? It's really easy to work with. This is why people keep using it.
Back at you boy. I'm a dev. I hate dealing with other dev that wasted my time just because he ain't lover with RDBMS and decided to write more code and add more infrastructure components (that includes message queue unless you absolutely have no choice). My time is finite. Ops time is finite. Obviously you decided to dick around with mine and Ops. How bout I send you to the QA department to write automation and softw…
Let me guess, you're the guy who makes sure there's a "Senior" in his title and you use django because the docs are so great.
I'm sorry you work with incompetent people. Sounds like you're in a cubicle farm somewhere. While you're in a meeting swinging your seniority around, I'll be over here shipping products faster than your team.
Re: Failing with MongoDB
#119Why is a database that fails so easily and most of the time even loses data so popular? Is it really all just a huge marketing budget?
Why is a database that fails so easily and most of the time even loses data so popular?
Perhaps because both of your premises are wrong? I've used Mongo for over a year now with ~1000 writes/sec and haven't seen any of these problems. I'm not saying they don't exist (some are confirmed bugs that have been fixed), but they're not nearly as prevalent as your 'Do you still beat your wife?'-style question implies.
Re: Failing with MongoDB
#120Disclosure: I wrote a product called Citrusleaf, which also plays in the NoSQL space.
My focus in starting Citruseaf wasn't features, it was operational dependability. I had worked at companies who had to take their system offline when they had the greatest exposure - like getting massive load from the Yahoo front page (back in the day). Citrusleaf focuses on monitoring, integration with monitoring software, operations. We call ourselves a real-time database because we've focused on predictable performance (and very high performance).
We don't have as many features as mongo. You can't do a javascript/json long running batch job. We'll get to features.
The global R/W lock does limit mongo. Absolutely. Our testing shows a nearly 10x difference in performance between Mongo and Citrusleaf on writes. Frankly, if you're still doing 1,000 tps, you should probably stick with a decent MySQL implementation.
Here's a performance analysis we did: http://bit.ly/rRlq9V
This theory that "mongo is designed to run on in-memory data sets" is, frankly, terrible --- simply because mongo doesn't give you the control to keep you in memory. You don't know when you're going to spill out of memory. There's no way to "timeout" a page cache IO. There's no asynchronous interface for page IO. For all of these reasons - and our internal testing showing page IO is 5x slower than aio; the reason all professional databases use aio and raw devices - we coded Citrusleaf using normal multithreaded io strategies.
With Citrusleaf, we do it differently, and that difference is huge. We keep our indexes in memory. Our indexes are the most efficient anywhere - more objects, fea. You configure Citrusleaf with the amount of memory you want to use, and apply policies when you start flowing out of memory. Like not taking writes. Like expiring the least-recently-used data.
That's an example of our focus on operations. If your application use pattern changes, you can't have your database go down, or go so slowly as to be nearly unusable.
Again, take my comments with a grain of salt, but with Citrusleaf you'll have better uptime, fewer servers, a far less complex installation. Sure, it's not free, but talk to us and we'll find a way to make it work for your project.