Personally, I'd be in favor of something like Maria DB as an open source repo. Or any other ansi sql store. On the positive side, it should mesh seamlessly with ORM tools. And the schema for this should be pretty vanilla, I'd imagine. I might even consider skipping ORM for straight JDBC and simple command scripts in Java for something this small. I'm not worried so much about migrations of this sort. Large scale DBs can get involved with major schema changes, but thats usually when the datastore is a massive set of tables with complex relationships, at least in my experience.
We could also use hbase, which probably wouldn't be that hard either, but there may be more boilerplate to write for the client as compared to standard SQL. But I'm assuming we could reuse a fair amount of existing code from our enrichments. One additional reason in favor of hbase might be data replication. For a SQL instance we'd probably recommend a RAID store or backup procedure, but we get that pretty easy with hbase too. On Feb 1, 2018 2:45 PM, "Casey Stella" <ceste...@gmail.com> wrote: > So, I'll answer your question with some questions: > > - No matter the data store we use upgrading will take some care, right? > - Do we currently depend on a RDBMS anywhere? I want to say that we do > in the REST layer already, right? > - If we don't use a RDBMs, what's the other option? What are the pros > and cons? > - Have we considered non-server offline persistent solutions (e.g. > https://www.html5rocks.com/en/features/storage)? > > > > On Thu, Feb 1, 2018 at 9:11 AM, Ryan Merriman <merrim...@gmail.com> wrote: > > > There is currently a PR up for review that allows a user to configure and > > save the list of facet fields that appear in the left column of the > Alerts > > UI: https://github.com/apache/metron/pull/853. The REST layer has ORM > > support which means we can store those in a relational database. > > > > However I'm not 100% sure this is the best place to keep this. As we add > > more use cases like this the backing tables in the RDBMS will need to be > > managed. This could make upgrading more tedious and error-prone. Is > there > > are a better way to store this, assuming we can leverage a component > that's > > already included in our stack? > > > > Ryan > > >
