Subscribe to Grim's Projects        RSS Feed

A Helpful Fix for an FFDB?

Icon Leave Comment
No one responded to my previous blog entry which I surmise is because I have very few readers. After all, without some sort of knowledge of Mimesis who would bother to write anything about it? Nevertheless, going on my original assumption I noted that my HITS table (the one leaving behind defunct locks) was 250 kb worth of data. The actual data itself is just NULL values so the file itself only ever increases by 3 bytes with each new ip address logged. In this table's case it happens to be the structural file is greater than the data file, and the structural file is always being rewritten.

My hypothesis is that given the large amount of data (almost 7000 rows worth of it) the writing procedure may time out. Currently I helped to shrink the data by converting how the ips are stored. As opposed to storing them as strings of the following type:
I used the pack function to store each individual integer as a character and use that as the row's label. This took the structural file from 250 kb to 200 kb worth of data. I grant you such small amounts of bytes of data aren't necessarily impressive, but looking at it percentage-wise it amounts to a 20% reduction.

This isn't a code change to the Mimesis class though, just a change to how I came up with row labels. A more "outside the box" procedure if you will. However, its becoming clear I'll need to do comparative things to increase the speed of write operations.

0 Comments On This Entry