At Percona, we focus on providing the best solution for our customers, rather than falling into “big ego,” “not invented here” or “sunk cost fallacy” messages. We have limited engineering resources and want to concentrate on the things that matter the most for our community and our customers – the things that make a positive difference.
When we acquired Tokutek, TokuMX was a product that truly made a difference for a lot of MongoDB users. It allowed them to do what they could not do with MongoDB. However, things in the technology world change rapidly, as they have in the year since the acquisition.
During the last year, the WiredTiger storage engine became generally available and demonstrated great performance for many read-focused and in-memory workloads. In addition, the RocksDB-based MongoRocks storage engine is well-optimized for handling large data write-intensive workloads.
(You can see some of the benchmarking we’ve done to verify the performance of these engines here.)
With these developments, Tokutek’s Fractal Tree storage engine (now named PerconaFT) lost major performance advantages for the most common workloads. Additionally, the fact that MongoDB internally uses an optimistic locking pattern, while PerconaFT was designed with a pessimistic locking pattern, means that it would take a lot of work to make PerconaFT the best solution in a MongoDB environment.
As result, we have decided to deprecate PerconaFT in Percona Server for MongoDB 3.2, with plans of removing it in Percona Server for MongoDB 3.4. At the same time, we will move our focus towards working together with Facebook on making MongoRocks the leading write-optimized storage engine for the MongoDB ecosystem.
We will focus on fixing any remaining feature and performance gaps to ensure moving from PerconaFT to MongoRocks with Percona Server for MongoDB is as simple as possible – and results in even better performance.
With the release of Percona Server for MongoDB 3.2, we’re fully embracing MongoRocks and lifting its experimental status to be fully supported for all production environments.
You may ask, what does this mean for TokuDB? This means our Fractal Tree Indexing engineering team can focus on MySQL workloads rather than supporting two different database servers that have very different expectations from the underlying storage engine, and will allow us to improve TokuDB faster than before.