[deleted]
Scaling MongoDB at Mailbox
21–30 of 78 posts
Re: Scaling MongoDB at Mailbox
#22[deleted]
Re: Scaling MongoDB at Mailbox
#23I 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, like this one.
In its current state it looks more like a prototyping tool that allows you to delay some tech decisions until your product matures, rather than a production tool. Or it is just me that wants at least 5 major versions on his production database.
Re: Scaling MongoDB at Mailbox
#24[deleted]
Re: Scaling MongoDB at Mailbox
#25Earlier quoted context omitted.
We moved to TokuMX ( http://www.tokutek.com/products/tokumx-for-mongodb/ ) recently and saw a 2x improvement in response times. They've swapped out mongo's backend with their fractal tree storage engine which is MVCC. Definitely worth checking out.
This is something I've considered pushing for at my company. Any pitfalls you encountered? Did it reduce db size on disk as much as their marketing claims?
My tests with it showed a drop in disk size of about 20-30%.
Unfortunately the read/write improvements weren't high enough to justify the massive engineering feat it would take to replace MongoDB with TokuMX, mostly due to the lack of commercial support for Toku.
Re: Scaling MongoDB at Mailbox
#26Earlier quoted context omitted.
This is something I've considered pushing for at my company. Any pitfalls you encountered? Did it reduce db size on disk as much as their marketing claims?
My tests with it showed a drop in disk size of about 20-30%. Unfortunately the read/write improvements weren't high enough to justify the massive engineering feat it would take to replace MongoDB with TokuMX, mostly due to the lack of commercial support for Toku.
Our disk size shrank to 10% of stock mongodb size.
The migration is easy now that they've released a tool to replicate from a stock mongo to TokuMX. They also do have commercial support that we've paid for and their team has been incredibly helpful and responsive.
Re: Scaling MongoDB at Mailbox
#27>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?
Yes, MongoDB really is that bad. Never use it.
Re: Scaling MongoDB at Mailbox
#28Earlier quoted context omitted.
This is something I've considered pushing for at my company. Any pitfalls you encountered? Did it reduce db size on disk as much as their marketing claims?
My tests with it showed a drop in disk size of about 20-30%. Unfortunately the read/write improvements weren't high enough to justify the massive engineering feat it would take to replace MongoDB with TokuMX, mostly due to the lack of commercial support for Toku.
we migrated recently (last week) using the new mongo2toku bridge. it was relatively painless.
Re: Scaling MongoDB at Mailbox
#29>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?
MySQL has a few engines that still have a database level lock ( MyISAM, MEMORY ) and those generally preform better for unbalanced loads ( i.e very read heavy or very write heavy )
Do you have any source for this? While logic suggests that they should (but perhaps only very slightly) I think InnoDD has got a lot of more optimization work than any other engine.
A benchmark from Oracle shows InnoDB as being much faster on a read-only workload.
http://www.oracle.com/partners/en/knowledge-zone/mysql-5-5-i...
EDIT: By the way the locks are table level in MyISAM and Memory.
Re: Scaling MongoDB at Mailbox
#30I'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.