Hack MySQL

Taxonomy of database tools

with 5 comments

Taxonomy of Database Tools

In the MySQL ecosphere there is an ecosystem of tools.  Like real-world ecosystems, the “creatures” in the MySQL tools ecosystem can be classified and organized by a taxonomy.  There are already multiple taxonomies of software bugs (e.g. A Taxonomy of Bugs), but as far as I know this is the first Taxonomy of Database Tools.  A taxonomy of database tools serves useful purposes, as discussed in the previously linked page.  For me, the most useful purpose is the high-level ecosystem view which I use to compare MySQL tools to Drizzle tools.  In so doing, one sees clearly how the MySQL tools ecosystem is thriving whereas the Drizzle tools ecosystem is just budding, so to speak.  For other people, I imagine two overarching interests in a taxonomy of database tools.

First, by laying out the ecosphere in a simple, organized, and comprehensible fashion, a taxonomy of database tools can permit a user (DBA, sysadmin, etc.) to see how well they are “tooled”.  For example, when I gave a presentation on pt-table-checksum at PLMCE 2012, I was surprised to learn how many people never used a tool to verify replication data integrity.  I did not bother to ask why, but I suspect it is because they were not aware that such tools existed.  By looking at this taxonomy of database tools, some users might discover a new type of tool of which there are already many examples.

Second, a taxonomy of database tools is interesting for developers because it reveals where a database server has missing capabilities that users compensate for with tools.  Point in case: pt-table-checksum is used to verifying replication data integrity because until MySQL 5.6 this capability did not exist in the database server.  It is debatable whether all types of tools could be implemented natively in a database server; in theory, they probably could.  This debate becomes a practical concern for modularly-designed database servers like Drizzle because in my humble opinion it is far easier to write plugins and thus tools-as-plugins for Drizzle than for MySQL.

This Taxonomy of Database Tools is still a work in progress.  A lot of the descriptions need to be expanded, traits refined, and more examples added.  If you do not agree with its organization, you can suggest a change, or develop your own taxonomy.  In any case, I will continue to refine this Taxonomy of Database Tools to see where it leads and what it reveals.

Written by Daniel Nichter

May 11th, 2012 at 4:30 pm

5 Responses to 'Taxonomy of database tools'

Subscribe to comments with RSS or TrackBack to 'Taxonomy of database tools'.

  1. It would be great to see this expanded in to more than just a collection of command line scripts – there’s many other classes of tools (the likes of Workbench, SQLYog et al) that bring in new categories like “Modeling”, “Schema Management” (for want of a better category name), “Security” (firewalls, auditing, privilege management), et al.

    Speaking for my own (sadly not represented) team who develops a “Monitor Tool”, “Analyzer Tool” and “Detector Tool” in one bundle, I wonder a little about the hierarchy that you have as well – surely an “Advisor” tool needs to sit under a “Monitor”, with “Detector” and “Advisor” being the same class of thing (a Detector tool still has “a certain amount of human knowledge which they pair with the target condition” – because a human writes the detector, that’s not a good distinction between the two, they do the same thing, they are both written by humans).

    Wikipedia has something like an attempt at this, but I think your approach servers that overview much better:


    It would be great to see your approach translated in to something on Wikipedia, that could be added to by all..

    Mark Leith

    21 May 12 at 3:06 AM

  2. Actually, in MySQL 5.6 the functionality of pt-table-checksum still isn’t implemented. The blog posts talk about “ensuring replication integrity” but what they mean is that binary log events have checksums that ensure they aren’t corrupted while being copied from the master’s binary logs to the replica’s relay logs. This does not ensure that the master and replica have the same data, however.

    Baron Schwartz

    21 May 12 at 7:22 PM

  3. Mark, thanks for the feedback. The current examples are mostly command line tools only because they are what came to my mind first, but yes, graphical tools like Workbench and SQLYog are appropriate examples, too.

    As you noted, there’s a problem categorizing things like Workbench: is it a tool or a suite of tools? It doesn’t seem to be a tool, but if it’s the latter, then how does that fit the hierarchy? Such issues probably arises only rarely in the natural world. A griffin comes to mind: part lion, part eagle. Workbench is decidedly less mythical, though. :-)

    As for Wikipedia, that’s a good idea, although I’ve never created a Wikipedia page before. Perhaps I’ll try.

    Daniel Nichter

    26 May 12 at 10:15 AM

  4. Baron, in that case, 5.6 checksums are certainly no replacement for pt-table-checksum. I’ve not thought at length how one would implement tools directly in a database server. Truly implementing what pt-table-checksum does directly into a database server would seem to bloat the server way beyond its intended purpose. Maybe that’s why there are very few (any?) database servers with full-fledge built-in tools. Interesting to think about.

    Daniel Nichter

    26 May 12 at 10:41 AM

  5. Why isn’t mysqltuner 1.0 in the advisors category, and mysqltuner 2.0 in the detectors category? I can’t seem to find either of those tools.

    Also, there are plenty of Palomino tools around: https://github.com/palominodb/PalominoDB-Public-Code-Repository/ these are in use many places, much wider than the spread of just PalominoDB (For example the nagios plugin is distributed by the Nagios corporate folks). Is there a way to “Submit” a tool? I like the idea of having one place where you can see them, but this seems to be mostly hackmysql tools + openark + percona tools.

Leave a Reply