[Snort-devel] Composite keys in Snort DB schema
chris.reid at ...583...
Mon Aug 23 11:11:19 EDT 2004
This has been asked several times in the past too. The primary reason for
this key structure is ACID -- ACID uses this composite key, and this is an
implementation of the ACID schema.
Other people have suggested creating an alternate schema which uses single
IDENTITY (SQL Server, Sybase) or SEQUENCE (Oracle) keys. The biggest reason
this isn't being pursued from within the Snort development team right now is
related to performance.
With Snort moving into the Gigabit range, it can't be slowed down waiting
for slow database inserts. This is the main justification for removing any
non-core logging from Snort, and moving it into external utilities such as
Barnyard. This way Snort can quickly write to, for example, the Unified
alert/log files which are then processed by Barnyard et al for subsequent
logging to whatever (slower) final data sink is required by the
company/person implementing the Snort sensor(s).
So, if you want to create your own schema for Snort there's nothing stopping
you. You'll probably even find others in the community that can share
valuable insights into this, and they'll likely even help contribute to its
development. Barnyard and similar tools would be the best place to develop
this plugin. And it would be great if such a plugin were donated back to
the Snort/Barnyard/etc community!
Things to consider:
* Multiple sensors logging to the same database
* Multiple simultaneous instances of Barnyard/etc logging to the same
* Not all supported databases support IDENTITY / SEQUENCE auto-generated
Can it be developed? Absolutely. Will it be incorporated into Snort? No,
it belongs in an external tool such as Barnyard/etc.
----- Original Message -----
From: "Christian Robottom Reis" <kiko at ...2474...>
To: <snort-devel at lists.sourceforge.net>
Cc: <venere at ...2613...>; "Erlison" <erlison at ...2614...>
Sent: Thursday, August 19, 2004 9:01 AM
Subject: [Snort-devel] Composite keys in Snort DB schema
> Hello there,
> I've been taking a look at Snort's DB schema (using the recently
> updated diagram Chris provided) and a question has popped up. Is there a
> reason why we use a composite key (cid and sid) for the tables beyond
> wanting to have sequential cids for each sensor? It seems it complicates
> things somewhat since we need to spread out these keys over all the
> tables in the event-specific snort tables.
> Wouldn't it be simpler -- white still fully functional -- to have a
> single globally unique sequential event ID?
> Take care,
> Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331
More information about the Snort-devel