[Bro-Dev] Broker data store API

[Hosom, Stephen M]

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 [matthias at vallentin.net] on behalf of Matthias Vallentin [vallentin at icir.org]
Sent: Monday, July 25, 2016 11:25 AM
To: Hosom, Stephen M
Cc: Siwek, Jon; bro-dev at bro.org
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