Mike Bayer wrote:
Precisely. Why is the RDBMS the thing that is used for archival/audit logging?
Why not a NoSQL store or a centralized log facility? All that would be needed
would be for us to standardize on the format of the archival record,
standardize on the things to provide with the archival record (for instance
system metadata, etc), and then write a simple module that would write an
archival record to some backend data store.
Then we could rid ourselves of the awfulness of the shadow tables and all of
the read_deleted=yes crap.
+1000 - if we’re really looking to “do this right”, as the original message
suggested, this would be “right”. If you don’t need these rows in the app (and
it would be very nice if you didn’t), dump it out to an archive file /
non-relational datastore. As mentioned elsewhere, this is entirely acceptable
for organizations that are “obliged” to store records for auditing purposes.
Nova even already has a dictionary format for everything set up with nova
objects, so dumping these dictionaries out as JSON would be the way to go.
+ 1001; dump it out to some data warehouse, put it to HDFS, do something
else with long term storage IMHO; just let's avoid continuing to turn a
database into a data warehouse, they are really not the same thing and
don't have the same requirements, constraints ...
I've always been confused why some of the openstack tables tried to do
both roles with a deleted=1|0 field. The part that has also been
confusing to me is has anyone actually tried switching a deleted=1 field
back to deleted=0 without application logic to do this; if so how did u
manage to pull that off correctly without knowing the inner details of
the application itself (how did u do this atomically so that the users
*actively* running against the api would not start to receive weird
responses and failures...)?
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
