October 22, 2008
Introduction to Kickfire
I’ve spent a few hours visiting or otherwise talking with my new clients at Kickfire recently, so I think I have a better feel for their story. A few details are still missing, however, either because I didn’t get around to asking about them, or because an unexplained accident corrupted my notes (and I wasn’t even using Office 2007). Highlights include:
- As previously noted, Kickfire offers an appliance consisting of a columnar data warehouse DBMS in the form of a MySQL storage engine (plus MySQL’s front end, of course), packaged onto an appliance.
- In essence, Kickfire is trying to offer no-apologies data warehouse DBMS functionality, inexpensively and in a simple package. This includes ACID compliance, good SQL functionality coverage, and so on.
- Specifically, a Kickfire box consists of standard server components – the details of which died with my notes 🙁 — plus a custom board. A box comes in two configurations, either 2U or 3U in size.
- Kickfire now claims two paying customers. Kickfire is being secretive about customer details.
- Kickfire’s target database size is as low as 50 gigabytes (because Kickfire believes MySQL can run into problems that low) up to 3 terabytes. Although Kickfire claims to support up to 10 terabytes of user data per node, I’m not aware of any current Kickfire customer databases over a terabyte or so.
- Kickfire says its system operates on compressed data all the way through (thus, it is restricted to forms of compression for which that makes sense).
- Like any data warehouse database specialist, Kickfire has run customer queries at better than 100X the performance achieved on general-purpose DBMS (in this case MySQL). In a few cases it’s pushing 1000X.
The heart of Kickfire’s story is its SQL chip, and the computer architectural choices the chip instantiates. In particular, the architecture boasts:
- Hardwired SQL functionality – not just selects and projects are hardwired in silicon, but also (if memory serves) sorts, joins, and the like.
- Massive multiparallelism on a single chip – because the SQL functionality is specialized, many copies of it fit on one chip.
- Extreme pipelining – Kickfire avoids reading from or writing to RAM whenever possible, decrying those steps as a “von Neumann bottleneck” to be designed around.
Categories: Columnar database management, Data warehouse appliances, Data warehousing, Kickfire, MySQL, Theory and architecture
Subscribe to our complete feed!
Comments
Leave a Reply