First off, thanks for the detailed response and the link to the previous discussion (which I missed when searching the forum before posting, for some reason). I appreciate it.
Now on to the part where I disagree with you ??
1. In terms of performance, the picture between MyISAM and InnoDB is more complex than just “MyISAM equals fast, InnoDB equals slow.” (This discussion on StackOverflow has some interesting benchmarks in the comments, for instance.) MyISAM can be faster than InnoDB, but generally speaking that’s only consistently true on workloads that are mostly reads. The more your application writes to the database the less of an advantage MyISAM will have, and Cerber writes a lot of things (logging failed login attempts, for instance).
2. Beyond performance considerations, there are benefits to using InnoDB other than just transactions. MyISAM only supports table-level locking while InnoDB supports row-level locking, for instance, which means less possibility of running into a deadlock.
3. Beyond the merits of the individual storage engines themselves, the MySQL ecosystem has been moving away from MyISAM and toward InnoDB for a long time. The standard advice from Oracle and Percona for years now has been that you should use InnoDB for everything except for those increasingly-rare cases where MyISAM does something specific that InnoDB doesn’t (like full-text indexing, though that’s been added to InnoDB in MySQL 5.6).
4. InnoDB has been the default storage engine for new tables in MySQL as of version 5.5.5, which came out nearly 7 years ago. This means that MyISAM tables are less and less common on your average MySQL server these days, which in turn leads to those servers being more and more tuned for InnoDB performance and less and less for MyISAM as time goes on. Mixing storage engines within a database can also cause difficulty with things like backups, since backup strategies and tools that work for one engine frequently don’t work nicely with others. All of which means that forcing MyISAM usage risks putting Cerber in a box as “that plugin that gives our host’s database administrator a migraine,” which is not a good look.
I am encouraged that you’re open to making this a user-configurable setting. However, I don’t think the plugin itself is the right place to expose that setting. Most users with access to the plugin configuration panel won’t know enough about MySQL internals to make an informed choice on the subject, and those that do know enough are likely to have access to their MySQL instance directly, where they can express this preference by setting a default storage engine or moving existing tables to whatever engine they prefer. So I would argue that, if you want to make this configurable, the best way for most users to do that would be to follow whatever storage engine preference their MySQL instance has set.
Again, thanks for taking the time to respond, and for all your hard work on Cerber. I appreciate it!
