An Overview of the NoSQL World - Large Scale and Big Data: Processing and Management - page 299

SELECT [ * |_ _key_ _ ] FROM <kind>
[ WHERE <condition> [ AND <condition> . . . ] ]
[ ORDERBY <property> [ ASC | DESC ] [ , <property> [ ASC | DESC ] . . .] ]
[ LIMIT [ <offset> ,] <count> ]
[ OFFSET <offset> ]
<condition> : = <property> { < | <= | > | >= | = | != } <value>
<condition> : = <property> IN <list>
<condition> : = ANCESTOR IS <entity or key>

FIGURE 9.5 Basic GQL syntax.

for the same properties. Each entity also has a key that uniquely identifies the entity.
The simplest key has a kind and a unique numeric ID provided by the datastore. An
application can fetch an entity from the datastore using its key or by performing a
query that matches the entity's properties. A query can return zero or more entities and
can return the results sorted by property values. A query does not allow the number
of results returned by the datastore to be very large to conserve memory and run time.
With the AppEngine datastore, every attempt to create, update, or delete an entity
happens in a transaction. A transaction ensures that every change made to the entity
is saved to the datastore. However, in the case of failure, none of the changes are
made. This ensures consistency of data within an entity. The datastore uses optimis-
tic concurrency to manage transactions. The datastore replicates all data to multiple
storage locations, so if one storage location fails, the datastore can switch to another
and still access the data. To ensure that the view of the data stays consistent as it is
being updated, an application uses one location as its primary location and changes
to the data on the primary are replicated to the other locations in parallel. An appli-
cation switches to an alternate location only for large failures. For small failures in
primary storage, such as a single machine becoming unavailable temporarily, the
datastore waits for primary storage to become available again to complete an inter-
rupted operation. This is necessary to give the application a reasonably consistent
view of the data, since alternate locations may not yet have all of the changes made
to the primary. In general, an application can choose between two read policies: (1) a
read policy of strong consistency , which always reads from the primary storage loca-
tion, and (2) a policy of eventual consistency [63], which will read from an alternate
location when the primary location is unavailable.
The AppEngine datastore provides a Python* interface, which includes a rich data
modeling API and a SQL-like query language called GQL. † Figure 9.5 depicts the
basic syntax of GQL. A GQL query returns zero or more entities or keys of the
requested kind. In principle, a GQL query cannot perform a SQL-like “join” query.
Every GQL query always begins with either SELECT* FROM or SELECT (key)
FROM followed by the name of the kind. The optional WHERE clause filters the
result set to those entities that meet one or more conditions. Each condition com-
pares a property of the entity with a value using a comparison operator. GQL does

* http://www.python.org/.
† http://code.google.com/appengine/docs/python/datastore/gqlreference.html.