[cacti-announce] Cacti 0.8.6j Released (fwd)
jml at packetpimp.org
Thu Jan 25 12:51:15 UTC 2007
This is where dbms' designed for data warehouses might come into play,
something like SybaseIQ. It is adapted for long term storage and retrieval.
michael.dillon at bt.com wrote:
>> how do you define your schema?
>> how long does it take to insert/index/whatnot the data?
> This is a much bigger deal than most people realize.
> Poor schema design will cause your system to choke
> bade when you try to scale it. In fact, relational
> databases are not the ideal way to store this kind
> of data so when you design your schema, you are really
> fighting against the database to wrestle it into something
> that will work.
>> this is a huge burden to figure it all out, implement
>> and then monitor/operate 24x7. miss enough samples or data
>> and you end up billing too little. this is why most folks
>> have either cooked their own, or use some expensive suite of
>> tools, leaving just a little bit of other stuff out there.
> Personally, I doubt that it is possible to build a
> workable system, even with plugins, that will do the
> job for a significant percentage of service providers.
> Different companies have different needs, different
> hot button items, etc. This is an area where breaking
> the problem down into well-defined separate problems
> with a well-defined linkage, will go a long way.
> But to start with, just solving the data storage problem
> is a good place to start. If someone can create a specialized
> network monitoring database that scales, then the rest of
> the toolkit will be much easier to deal with. Note that
> people have done a lot of research on this sort of
> time-series database. People working in high-energy physics
> also have to deal with massive sets of time-series data.
> There is plenty of literature out there to help guide
> a design effort. But Open-Source developers don't usually
> do this kind of up-front research before starting coding.
> Money and manpower won't solve that kind of problem.
> --Michael Dillon
More information about the NANOG