I'm looking for some simple heuristics to estimate the size on disk of a database based on average size of messages, number of messages per day and purge frequency. The purpose is for estimation of disk space requirements.
Clearly this is a how long is a piece of string question but for example, if you have a simple HL7 routing production that does nothing but process HL7. It receives 10,000 HL7v2 messages per day (all approx 1kb on the wire) in a single service, passes them to a single router and outputs to a single operation. What factor should you multiply the size of each message on the wire to get an approximation for the size on disk?
The inbound message will generate a message header object and a message body object held in globals. Both of those will have an index global. The message content is held in a stream which would be roughly the same size in bytes plus a small overhead. There will be new header for each message shunted between business hosts within the production. There's also event logs Then there's database block size and packing to consider before thinking about filesystems!
Depending on how I do back-of-envelope maths, I come up with something between a factor of 2x and 5x on-the-wire bytes. I'm inclined to think it's closer to the 2x as I suspect it's more efficient than the 5x, but better to over-estimate than under.
(1).jpg)