Xaprb

I’ve released version 1.1.7 of the Better Cacti Templates project. This release includes a bunch of bug fixes, some new graphs for MySQL, and two new sets of graphs, for Redis graphing and for JMX graphing.

There are upgrade instructions on the project wiki for this and all releases. There is also a comprehensive tutorial on how to create your own graphs and templates with this project. Use the project issue tracker to view and report issues, and use the project mailing list to discuss the templates and scripts.

The full changelog follows.

  * Added graphs for Innodb_row_lock_waits and Innodb_row_lock_time (issue 118).
  * Added graphs for the MyISAM key buffer memory consumption (issue 127).
  * The loadavg/users graphs failed when only 1 user was logged in (issue 131).
  * The Apache and Nginx graphs couldn't use the --port2 option (issue 129).
  * The InnoDB Log graph's unflushed_log should be GAUGE not COUNTER (issue 10).
  * Added graphs for InnoDB semaphore waits (issue 124).
  * Added Redis graphs (issue 90).
  * Added --openvz_cmd configuration and command-line option (issue 130).
  * Added --mysql_ssl configuration and command-line option (issue 103).
  * Added JMX graphs (--type jmx) (issue 139).
  * Big-integer math printf spec was missing a % character (issue 137).
  * Partially accepted patches from Artur Kaszuba (more remaining in issue 120).

Key-value databases are catching fire these days. Memcached, Redis, Cassandra, Keyspace, Tokyo Tyrant, and a handful of others are surging in popularity, judging by the contents of my feed reader.

I find a number of things interesting about these tools.

• There are many more of them than open-source traditional relational databases. (edit: I mean that there are many options that all seem similar to each other, instead of 3 or 4 standing out as the giants.)
• It seems that a lot of people are simultaneously inventing solutions to their problems in private without being aware of each other, then open-sourcing the results. That points to a sudden sea change in architectures. Tipping points tend to be abrupt, which would explain isolated redundant development.
• Many of the products are feature-rich with things programmers need: diverse language bindings, APIs, embeddability, and the ability to speak familiar protocols such as memcached protocol.
• I think there are more solutions here than the ecosystem will support, and in five years a few will stand out as the most popular.
• This process of paring down the gene pool is win-win because they’re open-source, and nothing will be lost.
• Choosing which one to use is no easy task even for a highly skilled, technical, up-to-date person. Perhaps the decision-makers will choose on the availability of commercial support and consulting.
• Many of them offer built-in, dead-simple, distributed, synchronous replication. This is very difficult to achieve with traditional relational databases. What makes key-value databases different? They don’t have MVCC, for one thing; but I’m not sure of the complete answer to that question, to tell the truth.

We live in interesting times.