1 of 1 people found this helpful
1. This seems to be a non-relational database. As network engineer, this is fine with me, but I'm not sure how our SQL DBAs will feel about this.
I'd like to throw some practical thought into this discussion. I've heard from a couple different places about perceived "complications" because SQL Server is not being used. A simple fact, however, is that ALL applications have some form of data storage, and quite a few of them do not use relational databases for data storage. Even applications that do use SQL Server, also have forms of data storage that do not include SQL Server.
IMHO, SQL Server DBAs should only be concerned with applications that require a SQL Server for data storage,
and any who are truly aware of the impact NTA has on their database servers will be ecstatic that NTA data storage is going away
An interesting exercise is to enumerate all of the applications in use in the organization, and the data storage being used by them.
For those that don't use SQL Server, ask the DBAs if they care about those applications. :-)
let me try to answer your questions:
1. You are right, Flow Storage DB is lightweight single purpose database, maintained mostly automatically, so its management is mostly about giving it enough resources (especially well sized fast disk drive). There are multiple performance counters that could be used for FSDB monitoring either directly or using template for SAM server. It is SolarWinds who provides support for FSDB.
2. No. Using SQL for storing flows in being considered as obsolete technology, and in long-term NTA won't support 32 bit deployments at all (Orion NetFlow Traffic Analyzer v4.0.2 Release Notes)
3. Most probably not. Most of SolarWinds products relies on SQL operations which FSDB doesn't provide (or at least not effectively), so while FSDB is just great for fast storing tons of flows in line, SQL is kept for relations, often updated/deleted data, programability, etc.