Database Reference
In-Depth Information
•
Reliability and predictability
: BigQuery should be just as reliable as
your local database instance. It also should be predictable—if a query
runs in 2 seconds today, it shouldn't take 5 seconds tomorrow.
•
Reducing limitations
: There are cases now in which BigQuery gives
out-of-resources errors or runs into size limitations. We'd like to get rid
of these; when you run a query, it should just work, no matter how big
the data is or what you've requested.
•
Getting closer to standard SQL
: There are a couple of nonstandard
SQLisms that can be frustrating for new users. We'd like to make
BigQuerySQL look more like SQL-92 or standard SQL that you're
familiar with. This also means we'd like to stop requiring the usage of
size hints like
EACH
.
•
Interaction with code that isn't SQL
: Right now, if you want to run
an algorithm that is difficult to express in SQL, you've got to export your
data out of BigQuery, transform it, and import it back. We'd like to
remove steps from this process.
•
Features requested by users
: The BigQuery team monitors the
in there if you have feature requests. There is also an external bug
tracker that can be used to report bugs and feature requests at
Cloud Support; you can let your support representative know your pain
points. Customer feedback helps decide priorities for new features and
the direction of the product.
BigQuery Sensors Application
To illustrate the different ways that BigQuery can be used in a web
application, we have built a BigQuery Sensors sample app that accompanies
this topic. The application is described in detail in Chapter 8, but examples
are used throughout the topic, so we'll describe it briefly here. This
application shows BigQuery in use to solve real problems; hopefully this
can inspire you to come up with ways that it can be used in your own
applications.
