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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
