A new company named Kickfire launched at the MySQL 2008 Conference. Their product is a rackmounted server intended to be used as a high-end database (and server, if need be). Their innovation is a cpu specific to sql commands: the “SQL chip”. It works in similar fashion to a graphics specific cpu or router cpu. Instead of taking in the normal assembly commands, the sql chip understands 10 or so sql type of commands: insert, update, join, etc. This change drops the number of commands being run on the chip by leaps and bounds. There are a few other changes they make, but you can learn those in their video. They claim there is a 10x decrease in query time.
Kickfire is currently in beta. If you would like to join the beta program, I can put you in touch with the right people. Unfortunately, all beta boxes will be returned to Kickfire. Fortunately, OpenMRS implementers may have an opportunity at that point for a discounted machine. If you’re looking into buying a high end server, you definitely want to add the Kickfire box to your list of options.
I attended a session today at the MySQLConf2008 by Mark Matthews on adding extensions to the mysql jdbc connector. There are some exciting implications as an alternative to the BIRT ODA Plugin project. The idea of that project is to create a series of REST calls to only require the end user of the BIRT reporting application to have a high level knowledge of OpenMRS objects (instead of low level knowledge of the OpenMRS data model).
Sometime last year Burke laid out his dream BIRT (or other reporting frameworks) connection. It entailed writing a custom jdbc connector that didn’t act on the database, but instead acted on our API. The “available tables” as the user would see it in BIRT would actually be a subset of our higher level Java objects.
In the session Mark discussed the new intercept-ability of the MySQL Connector/J (new in version 5.1ga of the connector). The relevant/interesting addition to the connector is the “statement interceptor”. We could use this to intercept the select calls from BIRT that look like “SELECT AGE, GENDER, WEIGHT, HEIGHT, LATEST CD4 FROM PATIENT WHERE DATE > 1/1/2008”. These calls could be turned into some LogicService calls on AGE, WEIGHT, LATEST CD4, etc to get the ResultSet instead of passing that (unusable) query to mysql. The LogicService’s resultSet could then be returned to BIRT for display as a data set. There isn’t any documentation on MySQL Forge on how this would work yet. Mark’s slides should show up as an option on the mysqlconf’s wiki soon though.
Side note: The jdbc driver’s version number does not match with the mysql version numbers. Version 5.1 of the driver can be used with the current 5.0 of MySQL.
Patrick Galbraith presented gave an interesting presention titled “Replication for Dummies” at the MySQL Conference today. Previously, I had the notion that replicating servers and creating a master/slave MySQL setup was difficult. However, Patrick had a master/slave, then dual master, then dual master with a slave attached running in under 20 mins. He stepped through the my.cnf properties required for both the master server and the slave server — less than 10 for each!
The gist of how replication works is this:
- The master server writes all insert/update statements to a log file while applying them to itself.
- The slave server knows about this log file and simply applies each insert/update to itself.
- The slave server keeps track of where in the binlog file it last read from, so if the slave goes offline, it can start again from its exact position to get up-to-date.
It doesn’t seem like Patrick has his notes on the MySQLConf2008 wiki yet, but Brian found a nice easy replication howto we can follow instead. I look forward to setting this up for AMPATH and pointing all of our data managers’ read requests to the slave database instead of wasting cycles on the main master database. (that is royal “I” and will actually be either Brian or Simiyu :-P)