Snort with ACID

From Notes

A significant problem with using MySQL for storing Snort alert data is the performance tuning required. The following tables contain alert data and will become fragmented and require optimization after a significant number of insertions, deletions, or updates:

acid_event
data
event
icmphdr
iphdr
opt
tcphdr
udphdr

One method to maintain a MySQL database that holds a significant amount of data and is purged frequently would be to maintain partitions that would be written to and deleted by month or week. This would significantly reduce the amount of fragmentation and table tuning by dropping the partitions after each time period's data was no longer useful and/or archived off to a data store. I have not yet tested this method but I would like to soon.