Open Stack

On 28/08/15 01:54 PM, Dan Smith wrote:
>> we store everything as primitives: floats, time, integer, etc... since
>> we need to query on attributes. it seems like versionedobjects might not
>> be useful to our db configuration currently.
> I don't think the former determines the latter -- we have lots of things
> stored as rows of column primitives and query them out as objects, but
> then you're not storing the object and version (unless you do it
> separately) So, if it doesn't buy you anything, then there's no reason
> to use it.
sorry, i misunderstood this. i thought you were saying ovo may not fit 
into Ceilometer.

i guess to give it more of a real context for us to understand, 
regarding the database layer, if we have an events model which consists of:

- id: uuid
- event_type: string
- generated: timestamp
- raw: dictionary value (not meant for querying, just for auditing purposes)
- traits: [list of tuples (key, value, type)]

given this model, each of our backend drivers take this data and using 
it's connection to db, stores data accordingly:
- in mongodb, the attributes are all stored in documents similar to 
json, raw attr is stored as json
- in elasticsearch, they're stored in documents as well but traits are 
mapped different from mongo
- in hbase, the attributes and traits are all mapped to columns
- in sql, the data is mapped to an Event table, traits are mapped to 
different traits tables depending on type, raw attribute stored as a string.

considering everything is stored differently depending on db, how does 
ovo work? is it normalising it into a specific format pre-storage? how 
does different data will different schemas co-exists on the same db?
- is there a some version tag applied to each item and a version schema 
table created somewhere?
- do we need to migrate the db to some handle different set of 
attributes and what happens for nosql dbs?

also, from api querying pov, if i want to query a db, how do you 
query/filter across different versions?
- does ovo tell the api what versions exists in db and then you can 
filter across any attribute from any schema version?
- are certain attributes effectively unqueryable because it may not 
exists across all versions?

apologies on not understanding how it all works or if the above has 
nothing to do with ovo (i wasn't joking about the 'explain it to me like 
i'm 5' request :-) ) ... i think part of the wariness is that the code 
seemingly does nothing now (or the logic is extremely hidden) but if we 
merge these x hundred/thousand lines of code, it will do something later 
if something changes.

cheers,

-- 
gord