Timestamped data would certainly indicate that your schema would include said timestamp as a key.
That's all.
By storing the data in an SQL database you allow other applications to get at it in a reasonable fashion.
The MIB is a hierarchical object database. A network database model may perhaps make some sense but is there a readily available implementation of anything but relational, with/without object "overlay"?
PostgreSQL (http://www.postgresql.org ) would seem to map well onto the project.
While you can see their comparison to other software, I think some key points lend themselves here:
* Free software runs on most any UNIX system; RPM version available
* Reasonably popular
* fully relational
* interface to tcl and Perl included in the distribution
Its not the ultimate certainly. I have seen fault management systems using a Sybase engine with an entirely RAM-resident SQL database (Micromuse NetCool). That costs money. In the "traditional" mass storage-based system certainly PgSQL is not completely comparable to the highest-end Oracle platform.
OTOH, I think you'll spend less money building out a 128-node Beowulf cluster of dual-processor SMP machines to run a parallelized PgSQL application than a 256 processor Sun Enterprise system.
OK, so maybe a 128 processor Sun is equal to a 128 node Beowulf. who cares, at $2000 per node you should be able to get a dual processor PIII-600 with RAM. I haven't looked but I suspect that you'll pay more per processor on a Sun. AT some point the Sun is a better solution if you have a million bucks -- a small development machine with 4 processors and your huge monster. Might get more processing power total.
Certainly a consideration in a database server is raw I/o performance on the Sun might be better.
Back to your and my level of reality, I'm sure a single computer can handle your database service.
Data recording could be fairly quick so a machine with a good disk subsystem.
----- Original Message -----
From: "Eddie Corns" <E.Corns@ed.ac.uk>
To: <zvr@aueb.gr>
Cc: <E.Corns@ed.ac.uk>; <tkined@ibr.cs.tu-bs.de>; <zvr@aueb.gr>
Sent: Monday, February 21, 2000 10:08 AM
Subject: Re: [tkined] SNMP to SQL
> Date: Mon, 21 Feb 2000 13:53:53 +0200
> From: Alexios Zavras <zvr@aueb.gr>
> Precedence: bulk
>
> Back in the discussion of putting SNMP data in databases,
> I'd like to ask a more fundamental question.
> Do people use SQL features ? I mean "SQL" (structured queries)
> instead of just "Database" (store/get).
>
> To be honest I'm not sure yet. The main point is that you never know what
> way people are going to use the data. Far too often I have been frustrated
> using a system because the designer didn't consider that other people might
> have different needs and didn't bother putting a little bit of effort into
> making something more generic (HPOV springs to mind for some reason). So I
> wanted to see if it was possible. However I do anticipate some usage of
> structured queries to help detect behavioral patterns and trends (OK I'm doing
> a bit of hand-waving here but it's my time :).
> A full SQL implementation is perhaps over the top but it's the only thing I
> know of for doing ad-hoc queries (in reasonable time).
> Actually, I think I will put some thought into exactly how I might use the
> data and how easy/hard it is to extract. Glad you brought that up.
>
> I was working on the same path as people already mentioned here
> (collect with scotty, store in MySQL), when I realized that
> *for my needs* there was no gain in using an SQL database.
> I've since changed DBMS, and currently use berkeley db
> straight from Tcl. This database just gives you a generic
> (key,data) structure, which of course can accommodate
> whatever you want to store.
>
> The major advantage, I think would come from a temporal database,
> since almost all of my data are associated with a timestamp.
> However, I haven't found one I can readily use (and I doubt
> there exists one).
>
> How about a self-optimising declarative logic database, but look how long it
> took SQL to reach the availability it now enjoys.
> --
> !! This message is brought to you via the `tkined & scotty' mailing list.
> !! Please do not reply to this message to unsubscribe. To subscribe or
> !! unsubscribe, send a mail message to <tkined-request@ibr.cs.tu-bs.de>.
> !! See http://wwwsnmp.cs.utwente.nl/~schoenw/scotty/ for more information.
-- !! This message is brought to you via the `tkined & scotty' mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to <tkined-request@ibr.cs.tu-bs.de>. !! See http://wwwsnmp.cs.utwente.nl/~schoenw/scotty/ for more information.
This archive was generated by hypermail 2b29 : Mon Jan 08 2001 - 15:27:37 MET