The number of key/values would depend on the scale of the environment in the
case of the authentication framework. In my last implementation... it was one
record per user/host pair... which could scale into the tens of thousands of
key/value pairs pretty quickly. I haven't looked at that stuff in a while since
I'm eagerly awaiting your rewrite of the Broker APIs :)
________________________________________
From: Matthias Vallentin [[email protected]] on behalf of Matthias
Vallentin [[email protected]]
Sent: Monday, July 25, 2016 11:25 AM
To: Hosom, Stephen M
Cc: Siwek, Jon; [email protected]
Subject: Re: [Bro-Dev] Broker data store API
> I can't speak to whether or not it is 'needed', but I have had desire
> to use it in the past... The only thing preventing me from doing it
> was the fact that Broker is currently a fast moving target.
Good to know. Scott Campbell also uses the current version of Broker in
his projects and mentioned the need for a scalable and performing
storage backend.
> Generally speaking, I was wanting to do it so that I could save state
> between cluster restarts (specifically for authentication data).
How many keys to you anticipate in your data store? And what's the rate
of updates? Any ballpark estimate would be useful here.
Given the interest in a scalable backend, I will bring back support for
a RocksDB backend.
Matthias
_______________________________________________
bro-dev mailing list
[email protected]
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
