Earlier quoted context omitted.
Yes, MongoDB really is that bad. Never use it.
Use rethinkdb instead. Its not perfect but it mainly hits the same niche but does it right.
RethinkDB looks promising, but it's a bit early.
Scaling MongoDB at Mailbox
61–70 of 78 posts
Re: Scaling MongoDB at Mailbox
#62two writes don't make it wrong?
Re: Scaling MongoDB at Mailbox
#63Earlier quoted context omitted.
Simple. There are some use cases for which MongoDB will be 5x faster than any other system. It is relatively unique among databases in that it is a document store as opposed to a relational system. It is also very easy to use and manage.
> It is also very easy to use and manage. This is something that SQL database fans don't get. A small start-up can't afford to have a team of guys fiddling with incredibly obscure performance tuning settings. A developer might not know how to optimize a slow-running Postgre query, but he knows how to cache data and denormalize in a manner that makes the query he wants to run fast. And a document-store plays nice with…
One thing you don't know or faced yet is that mongo fails, and sometimes it fails so hard that you would rather kick some rocks.
For example, if you start a background index generation on an eventually consistent replica set, indexing on secondary nodes are done foreground. Which means you only accept reads from slaves but slaves are unresponsive because of the index generation. In this state, if you try to do anything fancy your data will go corrupt. Only way out is to wait through the outage (which I find it pretty hard to do so). This is still not solved in 2.4, waiting for 2.6.
Replica sets with all secondaries which can't elect a primary because it lost a node, or the mostly random primary-secondary switches that drops all connections, seldomly primary reelecting itself meanwhile dropping connections for no apparent reasons. Mongo offers tin foil hats for integrity, consistency and reliability. So yeah, I'd rather examine and understand why an SQL query is slow. Because it is at least deterministic, which in mongo nothing really is.
Postgres supports free form json, XML or hstore document formats by the way, couchDb has its own specific features as a document db too. I still don't see why people want to go on with mongo this bad.
Re: Scaling MongoDB at Mailbox
#64I dont understand how MongoDB can stay as a shiny tool given its long list of shortcomings. It is so elastic that I think it really has no true form (object cache, mq, relational??, key-value bucket). Lately I haven't read any news about a company migrating to Mongo, but rather most were either departing from mongo because of some catastrophic outage or some mission impossible operation to handle the shortcomings, li…
Simple. There are some use cases for which MongoDB will be 5x faster than any other system. It is relatively unique among databases in that it is a document store as opposed to a relational system. It is also very easy to use and manage.
> There are some use cases for which MongoDB will be 5x faster than any other system.
This is a really bold claim that I very much doubt is true. For one, there are numerous other document stores that target the same sort of use cases as MongoDB. Second, there are benchmarks floating around that PostgreSQL used as a key value store is faster than MongoDB as is. I wouldn't be surprised if you saw similar things with other SQL databases.
Re: Scaling MongoDB at Mailbox
#65I'm aware of MongoDB issues with scaling, and I'm trying to avoid it as much as I can, but I still can't find any other alternative that offers geolocated queries.
Someone below mentions PostGIS, which from my understanding is among the best tools in the field (if you heard of OpenStreetMap, the whole DB for all their geo data runs on that, and people use dumps like others do with Wikipedia to build their own customized GIS apps on tops of it).
That said, other people mention Cloudant deployments here, and that is CouchDB. If you want a Mongo-ish (they are still very different) NoSQL document store (notice I did not say database), there is extra layer of functionality on top of CouchDB known as GeoCouch. I have never personally used it but I have been looking for a reason to.
Re: Scaling MongoDB at Mailbox
#66>one performance issue that impacted us was MongoDB’s database-level write lock. People give MSSQL shit for having row-level locks (if you don't use their MVCC option), yet how is it that Mongo runs with a database-wide option and people don't immediately laugh and walk away? Is the hype so powerful that people just shrug about a huge mutex?
I think that's how it was in previous versions of Mongo but it was fixed in later versions. I'm probably wrong though.
It used to be a mongod-level lock, it's now a logical database-level lock. It used totally laughable, now it's merely amusing.
Re: Scaling MongoDB at Mailbox
#67I dont understand how MongoDB can stay as a shiny tool given its long list of shortcomings. It is so elastic that I think it really has no true form (object cache, mq, relational??, key-value bucket). Lately I haven't read any news about a company migrating to Mongo, but rather most were either departing from mongo because of some catastrophic outage or some mission impossible operation to handle the shortcomings, li…
Simple. There are some use cases for which MongoDB will be 5x faster than any other system. It is relatively unique among databases in that it is a document store as opposed to a relational system. It is also very easy to use and manage.
Only with unacknowledged writes. If you ask for acks, it gets ridiculously slow. Much, much slower in every single way than Postgres with a fully indexed HSTORE. That's also fully ACID.
Re: Scaling MongoDB at Mailbox
#68Earlier quoted context omitted.
Simple. There are some use cases for which MongoDB will be 5x faster than any other system. It is relatively unique among databases in that it is a document store as opposed to a relational system. It is also very easy to use and manage.
> It is also very easy to use and manage. This is something that SQL database fans don't get. A small start-up can't afford to have a team of guys fiddling with incredibly obscure performance tuning settings. A developer might not know how to optimize a slow-running Postgre query, but he knows how to cache data and denormalize in a manner that makes the query he wants to run fast. And a document-store plays nice with…
No, with Mongo you get a bunch hacks you need to do to maybe get indexed reads. I had to write a query optimiser that does lots of crazy things and simply rejects some entirely reasonably-looking queries because Mongo can't do them efficiently.
Not to mention the complete lack of durability. Even Redis is more durable.
Postgres is trivial to use. Is something slow (which will happen much later than with Mongo)? Add an index, done. I'm not a DBA, you don't need one.
Re: Scaling MongoDB at Mailbox
#69You need consistency (distributed mvcc), row-level locking and scale-out architecture. Clustrix might be a better fit for the workload. Clustrix customer Twoo.com has 336 core deployment (168 master, 168 slave, 21 nodes each), they have millions of users and billions of transactions per day. Their application still thinks it's talking to a single MySQL database and they don't have a DBA and they have never thought ab…
Wish someone would do that for Postgres.
There's Postgres-XC [1], but it's a fork and I don't know how actively developed.
1. http://sourceforge.net/apps/mediawiki/postgres-xc/index.php?...
Re: Scaling MongoDB at Mailbox
#70Earlier quoted context omitted.
Simple. There are some use cases for which MongoDB will be 5x faster than any other system. It is relatively unique among databases in that it is a document store as opposed to a relational system. It is also very easy to use and manage.
Only with unacknowledged writes. If you ask for acks, it gets ridiculously slow. Much, much slower in every single way than Postgres with a fully indexed HSTORE. That's also fully ACID.
Of course Postgres is also relational. Have you tried using a document oriented store like MongoDB? I have. For some problems it just plain rocks.
That doesn't mean I would want to store financial transactions for a bank in a MongoDB, but it has its place and that place is clearly huge (judging by the number of people using it).
I love it because it is: - simple to use - fast enough (with safe writes, thank you!) - simple to use - simple to use
Did I mention it was simple to use, which allows me to focus on app instead of wrestling with DB?