As we consider to use TokuMX for a mission-critical business case in our company I’d be interested in the future of TokuMX. Unfortunately I was not able to find something like a roadmap or future plans!
We use TokuMX in a huge setup and there is no way to dump all data and reimport it, which seems the only way to migrate to “Percona Server for MongoDB”.
Also we need to keep running TokuMX for other missing features of “Percona Server for MongoDB”, which only TokuMX has.
Alexander & Michael,
Thanks for dropping us a note! Our apologies for the lack of clarity. Here’s the short story, TokuMX is not going away in the near future. However, with the introduction of the Storage Engine API in MongoDB 3.0, we now have the ability to more easily maintain feature parity with MongoDB, Inc’s latest releases, which is what our customers, and the greater community, were requesting the most. Now, we can follow a model more close to Tokutek’s original product, TokuDB for MySQL. We’re always happy to jump on a call and explain in greater detail if it would be helpful. If that’s of interest, just drop a note in the Contact Me form and we’ll set something up ASAP.
That being said, we’re soliciting feedback from existing TokuMX customers about which features are the most impactful/frequently used. This information will directly drive the roadmap for feature development in Percona Server for MongoDB. So, if you have a few free minutes, reply to this post and let us know which features you can’t live without.
The most important thing for us is to keep existing tokumx data files, since we talk about 12 terrabyte of compressed tokumx data (146,523,198,105 documents on 72 shards). No way to dump and import all that data again, while keeping the system up and running - we add about 150,000,000 additional documents a day.
Due to limited diskspace there would also be a problem to just recreate the datafiles somehow in any new format, if there would be any migration tool - but there is none, as far as I know.
Since TokuMX was build for big data I think it would help everybody a lot if there would be a way of keeping existing data files, instead of dumping/importing big data.
For us, partitioned collections and user-definable primary keys are super important.
We found both are critical for performance when scaling up.
Partitioned collections are critical for time-series data with a pre-defined retention period.
User-definable primary keys are critical for performance when, for example, read queries are always “give me all documents for a specific user”, and those documents are created in random order.
Michael,
I’m not sure that I understand what you’re asking. We announced GA of PSMDB 3.0.7 on 12/14/15 and just recently put out PSMDB 3.0.8. We’re working hard to implement the features that everyone on this thread has graciously provided feedback on, but they will take some time to design and implement. We are very aware of the fact that these features will need to be easily maintainable so that our users can expect PSMDB to be very close to the upstream MongoDB feature set. If you’d like to follow the progress, there’s a link to the PSMDB Jira below.
I, and the entire PSMDB team are aware that migrations are “top of mind” for existing TokuMX customers. Our PSMDB engineering team is working extremely hard to develop a solution that meets the needs of our loyal users. We will be making an announcement in the near future regarding upgrade options. As I said in my previous post, we are always happy to have a conversation at your convenience. Just fill out the contact me form and we’ll setup a call to discuss your concerns.
Still TokuMX is the only MongoDB replacement that allows for multi-document transactions. This is the main reason why we are using TokuMX. Unfortunately, MongoDB in not yet offering multi-document transactions in their storage engines. Are there any plans to provide TokuMX as a storage engine for MongoDB up-to-date versions?
The Percona purchase of TokuMX/TokuDB and the aftermath with the discontinuation of TokuMX and later the FT storage engine itself - all without migration paths was a really ugly move. Not impressed at all.