Database Reference
In-Depth Information
data. Note that the verification suite can easily be set up to combine the new
and old data to simulate the table contents that appears after the update is
completed, if this is required for determining validity. After the suite passes,
the table copy operation can be used to append the staged data into the table
that needs to be updated. The reason this works is that the copy job accepts
a write disposition just like the load job, and with disposition set to append,
it adds the data rather than truncating existing contents.
jobData = {
'configuration': {
'copy': {
'sourceTable': source,
'destinationTable': destination,
'writeDisposition': 'WRITE_APPEND'
}
}
}
The advantage of this scheme over simply performing a backup before
modifying the table and then rolling back on corruption is that queries can
continue to operate on the table, and they will never encounter corrupt data.
With a rollback-based scheme, there is a window between corruption and
rollback when queries will potentially be returning incorrect results.
One final scenario is covered in which table copy is useful; although it is
not quite related to data backup. When a query is run without a destination
table specified, the default mode, the results are stored in a service-assigned
anonymous table. This anonymous table cannot be shared because it lives in
a dataset that cannot have its ACL modified, and further, it is automatically
garbage collected. If the results do need to be shared or saved, there is no
need to rerun the query with a new destination. Instead, the anonymous
table can simply be copied to the new destination, which can be shared or
retained indefinitely. It is worth mentioning that this is how the BigQuery
UI implements the Save as Table feature.
AppEngine Datastore Integration
Chapter 6, “Loading Data,” briefly described how AppEngine Datastore
backups can be imported into BigQuery to allow analytics over the contents.
Search WWH ::




Custom Search