5 ms·

Having used MongoDB in a number of projects, I had been holding out to try out TokuMX with production loads, however I've since settled on PostgreSQL for new pr

Having used MongoDB in a number of projects, I had been holding out to try out TokuMX with production loads, however I've since settled on PostgreSQL for new projects.

cheald 12y ago
TokuMX was really "MongoDB done right", at least up until MongoDB's integration of the WiredTiger engine. They also did some stuff with things like election protocols and stuff to improve on vanilla MongoDB, as well. It was really quite nice to work with. I've been a vocal advocate for it over the last couple of years. All that said, I am rather concerned about a lack of ongoing support for it, though. TokuMX 2.0.0 was released 7 months ago, with the promise of MongoDB 2.6 support "shortly" (MongoDB 2.6 was released just over a year ago). That's yet to materialize, and I've reported a number of bugs which haven't received prompt fixes (inlcuding a segfault which was closed as "working as intended"). These are edge cases, and certainly not the norm, but I was really impressed with Tokutek's support of the product a couple of years ago, and it sadly feels like it's dwindled to life support. Unless Percona makes a strong showing with it shortly, I'm not going to be able to justify building on it any longer.
- nemo44x 12y ago
  Yeah, there's no way they will be able to easily merge into all the changes that have happened since MongoB 2.6 and now 3.0. They're pretty far behind. 2.6 introduced a lot of refactoring (and therefore broke a lot of things) and 3.0 broke even more I can only assume. However, I believe they could sell their storage engine as MongoDB exposes a storage engine API now. Then again, I don't know why anyone would buy it now. MongoDB has done a decent job of patching things up and I guess TokuMK just isn't as interesting as it was before.
  - cheald 12y ago
    TokuMX still provides a lot of features that TokuMXse (vanilla with the tokumx storage engine) doesn't, like multi-document ACID and clustering keys. I would happily use it over vanilla if I was confident it was going to be well supported.

Having used MongoDB in a number of projects, I had been holding out to try out TokuMX with production loads, however I've since settled on PostgreSQL for new projects.

cheald 12y ago

TokuMX was really "MongoDB done right", at least up until MongoDB's integration of the WiredTiger engine. They also did some stuff with things like election protocols and stuff to improve on vanilla MongoDB, as well. It was really quite nice to work with. I've been a vocal advocate for it over the last couple of years. All that said, I am rather concerned about a lack of ongoing support for it, though. TokuMX 2.0.0 was released 7 months ago, with the promise of MongoDB 2.6 support "shortly" (MongoDB 2.6 was released just over a year ago). That's yet to materialize, and I've reported a number of bugs which haven't received prompt fixes (inlcuding a segfault which was closed as "working as intended"). These are edge cases, and certainly not the norm, but I was really impressed with Tokutek's support of the product a couple of years ago, and it sadly feels like it's dwindled to life support. Unless Percona makes a strong showing with it shortly, I'm not going to be able to justify building on it any longer.

nemo44x 12y ago
Yeah, there's no way they will be able to easily merge into all the changes that have happened since MongoB 2.6 and now 3.0. They're pretty far behind. 2.6 introduced a lot of refactoring (and therefore broke a lot of things) and 3.0 broke even more I can only assume. However, I believe they could sell their storage engine as MongoDB exposes a storage engine API now. Then again, I don't know why anyone would buy it now. MongoDB has done a decent job of patching things up and I guess TokuMK just isn't as interesting as it was before.
- cheald 12y ago
  TokuMX still provides a lot of features that TokuMXse (vanilla with the tokumx storage engine) doesn't, like multi-document ACID and clustering keys. I would happily use it over vanilla if I was confident it was going to be well supported.