More on Informix
We seem to have struck a chord...
Analysis My recent article on Informix seems to have generated some heat. For example, I have had a comment from one user, who says "hurrah, hurrah, you are the first who say it openly. Pasting of DB2 is a very bad marketing feature." By this I take it that he concurs with my original article in which I spelled out the problem of how to promote Informix side-by-side with DB2, particularly as all of IBM's databases fall under the umbrella of "DB2 Information Management".
More encouraging still is the fact IBM has also taken notice and I understand that the article has created some significant internal debate. For those of you that want some detailed information on IBM's current position vis a vis Informix, there is a webcast at www.watchit.com/informix which discusses this, though it does not answer all of the questions I raised in my previous article.
Returning to more mundane matters, I also mentioned in that article that IBM has released a new Datablade for Informix, in conjunction with CopperEye. I have now received benchmark figures for this development, and it is worth discussing these in some detail.
I generally distrust benchmarks (certainly, all the TPC tests that vendors blather on about in their marketing literature). The only useful benchmarks are those that are very specific, such as comparative tests that might be set up for a particular customer. In the case of the CopperEye Datablade the benchmarks are, arguably, specific enough to be noteworthy.
The actual tests were conducted at IBM Hursley and were based on the weekly processing of 350m rows of data with 4m additional inserts per week. The table containing this data had 3 B-tree indexes defined against it and the processing time for these inserts was 12 hours. In practice, the customer whose data this was, found that 12 hours was totally unacceptable and it therefore used a different approach: dropping its indexes before insertion and then re-creating them again afterwards (together with statistics updating). In a live environment this meant an improvement to around six hours for the whole process, depending on other work.
In the laboratory, of course, there was no other work, so the workaround described in fact ran in a little under 1¾ hours. Using the CopperEye Datablade, on the other hand, without dropping any indexes, the elapsed time for the same operation was just over 40 minutes, an improvement of more than 250 per cent. A second test was run comparing the Datablade's performance with the original without taking the indexes off-line: in this case the performance improvement was an order of magnitude greater again (in fact, 2,440 per cent).
A number of further points should be noted. First, query performance was tested after loading was completed and CopperEye's performance was comparable to that of the Btrees and in some cases, especially with larger datasets, was superior. Secondly, note that the more indexes you have on the data being loaded, the worse the performance will be when using a Btree. However, the additional processing in the case of CopperEye would only be incremental. With 10 indexes, for example, the Datablade would take about 50 per cent longer for the load process, while B-Trees (assuming you were going to drop them) would take around 3 times as long. In other words, it is much more practical to proliferate the implementation of indexes using CopperEye.
To conclude: there is good news and there is good news - on the one hand there is new technology emerging to support Informix users, while on the other IBM is listening.
Copyright © 2004, IT-Analysis.com
Sponsored: The Nuts and Bolts of Ransomware in 2016