Stuff To Do in an Emergency

I’m drafting this as we fly ‘Compact First’ from Johannesburg to Cape Town. Actually it’s a one class plane, but if you want to get the status-conscious sales executive on a one-class plane you tell him it’s ‘Compact First’. But one class or not Kulula Air are pretty classy. Their emergency procedures leaflet in the seat pocket is entitled ‘Stuff to do in an Emergency’ and features a picture of a member of cabin crew with her hands thrown up in horror and a look of panic on her face. Inside, along with the standard sensible stuff about oxygen masks dropping and leaving your high heels behind, there are little sidebar comments like ‘we tried laughing gas instead, but they insisted on oxygen’ and ‘yes ladies I’m afraid you’re going to have to leave the Jimmy Choos behind.’ Also on Kulula Air flights the smoking lounge is on the port wing - they say if you can light it you can smoke it. It was an early start so i was slightly regretting the long discussion about South African wine the previous evening.

I have a long history of conventional RDBMS database design. You use indexes, partitions and other more esoteric features - whatever the database can do for you. And you look at table design ‘data tricks’ - denormalization, data duplication and so on. So as a Netezza neophyte I was keen to learn a bit about how the database features available differ and to learn some design tricks of the trade. I had to sign a non-disclosure before the tech account manager I was grilling would answer. Not because it’s secret, but because he doesn’t want a half-educated marketing director running round thinking he’s a ninja-level design consultant. Turns out that in Netezza it’s pretty straightforward to get going - you just select your distribution key and start loading data. I’m educated enough now to know there’s more to it than that, but not educated enough to explain it. And anyway 90% of it is not important for 90% of databases. The whole Netezza architecture of hardware, firmware & software is holistically designed so you really have to be down to the very short straws before you need to do anything significant for any particular database design.

I thought that was great and filed it away as interesting stuff I should learn more about as I go. But it was brought back into my mind when I was talking to the DW architect of a potential new customer about how we should set up our proof of concept project with them (more about Netezza Test Drive proof of concept - POC - projects here). And he was very concerned that the way his database is designed (the data tricks I mentioned above) wouldn’t add any value in a Netezza database and might even be sub-optimal (duplicated data always carries a load; you only do that if there’s a concomitant benefit). I said he was right that some of the hyper-tuning he had done to get the last ounce of performance out of his existing warehouse (before they threw in the towel and started talking to us) would no longer help. But the debate was around whether he should devote time in the proof-of-concept project to re-design. The Netezza view is don’t. Just load your data and compare the results. We don’t say this to shorten the timescale so we get to a sale quicker, though our sales folk might feel that is a good enough reason. The real reason is more scientific. In any experimental process you change one factor at a time, so when you see a difference you know what caused it. We like to just put the Netezza appliance in to replace an existing warehouse and throw the same queries at it. That way we and the customer know the performance improvement is just down to the appliance itself.

I don’t say there isn’t value in subsequently re-addressing the database design, just don’t do it as part of the POC, otherwise you’re making it impossible to calculate ROI on the appliance and you’re also delaying time-to-payback. At Netezza we’re pretty confident you will get sufficient improvement from a TwinFin that you’ll have all the time you need to address any historical design tweaks. But when I was discussing this with my friendly neighbourhood deepTechs, they said it almost never happens. Customers just never get around to removing these historical idiosyncrasies of a database design because it’s not worth it.

Maybe we should think of them as what first the students of gothic architecture and then the evolutionary biologists call spandrels. They don’t add value, but they are doing no discernable harm.

Next stop Cape Town.