[Snort-devel] Composite keys in Snort DB schema

Frank Knobbe 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
slaves) configurations.

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...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20040831/f9226d30/attachment.sig>

More information about the Snort-devel mailing list