Database Reference
In-Depth Information
| 16.0 |
| 16.0 |
| 32.0 |
| 0.5 |
+------------+
This coerces the field to a simple floating-point value at query time.
Although the service can handle the representation of general NoSQL
entities, you should be wary of relying on this feature. If the types of fields
vary substantially across entities, you will end up with unwieldy schemas
that are not convenient to work with in queries. If you are in a position to
design your storage scheme, it is good to strike a balance between leveraging
the flexibility of NoSQL and having uniform entities that are convenient to
query.
Final Thoughts
It may be a little surprising that we have devoted so much space to Datastore
in a section on managing data in BigQuery. We have devoted a fair amount
of space to this topic because Datastore and BigQuery complement each
other. They are good examples of platform components that can be
combined so that the overall solution is more than just the sum of its parts.
In fact, in this chapter we have even used GCS as a conduit between the
services. Over time we expect this integration to become more seamless, but
it is already possible to do a lot by putting them together.
Metatables and Table Sharding
When compared to traditional databases, there is a proliferation of tables in
BigQuery. There are a few reasons for this difference:
• Every query result generates a new table.
• The unit of deletion is a table.
• Query costs are proportional to table sizes, so partitioning can help
manage costs.
Tables in BigQuery feel a bit like files in a filesystem. A database with
thousands of tables would be regarded with suspicion, but filesystems
containing thousands of files are the norm. This section covers the features
