“The PerconaFT storage engine has been deprecated and will not be available in future releases.”
Any specific reasons behind that decision?
From [url]https://www.percona.com/blog/2016/01/27/mongodb-revs-you-up-what-storage-engine-is-right-for-you-part-4/[/url] I understand that: “An ideal fit for the PerconaFT storage engine is a system with varied workloads, where predictable vertical scaling is required in addition to the horizontal scaling provide MongoDB. Furthermore, the ability of PerconaFT to maintain performance while compressing – along with support for multiple compression algorithms (snappy, quicklz, zlib and lzma) – make it one of the best options for users looking to optimize their data footprint.”
What is the recommendation for PerconaFT users now that this engine got deprecated?
My name is David Murphy, and I am the Practice Manager for MongoDB here at Percona. I apologize for the delay in not responding yesterday but based on your comments I felt it would be best to post a blog on this matter to make it clear on the reasons why optimistic and pessimistic locking do not play well together. Additionally, it explains how this will free up resources to focus on more instrumentation, tooling, and various other improvements we feel Mongo could use at this time. We were spending a significant amount of time just battling between these lock types which was a major driver in addition to the points Peter Z. made in the post you mentioned.