[Snort-devel] Composite keys in Snort DB schema
frank at ...2134...
Tue Aug 31 14:04:20 EDT 2004
On Mon, 2004-08-23 at 15:42, Kreimendahl, Chad J wrote:
> [...] I've also found that taking it down to one
> single event_id and using that to link everything prevents massive I/O
> in oracle [...]
Here is something to consider. When you deal with replicating database
systems, you basically have two options -- synchronous and asynchronous
replication. That splits in multi-master and single-master-multi-slave
(meaning, you only write to the master, and read -- like ACID -- from
The biggest problem in multi-master setups are obviously collisions. If
you have only one event ID, you have a hard time preventing collisions
caused by multiple sensors writing to the DB. The split in SID/CID
actually comes in handy at this point. Sensors can be balanced between
different masters, and using SID/CID each sensor writes only his own
data. The replication backend doesn't have to deal with collisions since
they don't occur.
If all sensors would share a single event ID in a multi-master DB model,
you wouldn't be able to spread the sensors between the masters.
My head is kinda fuzzy at the moment as I was fighting with Slony all
morning, so I may not explain this well. But I'm sure you understand
what I'm getting at, though.
In a nutshell, when thinking about the Snort database schema, please
keep database replication or H/A in mind. While a redesign may improve
performance for your single DB backend, it may be a huge PITA for
replicating and load-balanced DB backends.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 187 bytes
Desc: This is a digitally signed message part
More information about the Snort-devel