Google Code offered in: English - Español - 日本語 - 한국어 - Português - Pусский - 中文(简体) - 中文(繁體)
The App Engine Datastore provides robust, scalable storage for your web application, with an emphasis on read and query performance. An application creates entities, with data values stored as properties of an entity. The application can perform queries over entities. All queries are pre-indexed for fast results over very large data sets.
The App Engine Datastore holds data objects known as entities. An entity has one or more properties, named values of one of several supported data types: for instance, a property can be a string, an integer, or even a reference to another entity. App Engine offers a choice of two data storage options with different reliability and consistency guarantees:
Storage resource costs are the same for both options, but only paid applications using the HRD are covered by the App Engine Service Level Agreement (SLA). For more information, see the Choosing a Datastore page.
Unlike traditional relational databases, the App Engine Datastore uses a distributed architecture to automatically manage scaling to very large data sets. While the Datastore interface has many of the same features as traditional databases, it differs from them in the way it describes relationships between data objects. Entities of the same kind can have different properties, and different entities can have properties with the same name but different value types. These unique characteristics imply a different way of designing and managing data to take advantage of the ability to scale automatically. This documentation explains how to design your application to take the greatest advantage of the Datastore's distributed architecture.
The Datastore can execute multiple operations in a single transaction. By definition, a transaction cannot succeed unless every one of its operations succeeds; if any of the operations fails, the transaction is automatically rolled back. This is especially useful for distributed web applications, where multiple users may be accessing or manipulating the same data at the same time.
The App Engine Java SDK provides a low-level Datastore API with simple operations on entities, including get
, put
, delete
, and query
. You can just use this low-level API directly in your applications, or use it as a base on which to implement other interface adapters. The SDK also includes implementations of the
Java Data Objects
(JDO) and
Java Persistence API
(JPA) interfaces for modeling and persisting data. These standard interfaces include mechanisms for defining classes for data objects and for performing queries.
In addition to the standard frameworks and low-level Datastore API, the Java SDK supports other frameworks designed to simplify Datastore usage for Java developers. Many Java developers use these frameworks; the Google App Engine team highly recommends them and encourages you to investigate them.
Data objects in the App Engine Datastore are known as entities. An entity has one or more named properties, each of which can have one or more values. Property values can belong to a variety of data types, including integers, floating-point numbers, strings, dates, binary data, and others. A query on a property with multiple values tests whether any of the values meets the query criteria. This makes such properties useful for membership testing.
Datastore entities are schemaless: unlike traditional relational databases, the App Engine Datastore does not require that all entities of a given kind have the same properties or that all of an entity's values for a given property be of the same data type. If a formal schema is needed, the application itself is responsible for ensuring that entities conform to it.
Each entity has a key that uniquely identifies it. The key consists of the following components:
Each Datastore entity is of a particular kind, which categorizes the entity for the purpose of queries: for instance, a human resources application might represent each employee at a company with an entity of kind Employee
. In addition, each entity has its own identifier, assigned when the entity is created. Because the identifier is part of the entity's key, it is associated permanently with the entity and cannot be changed. It can be assigned in either of two ways:
Entities in the Datastore form a hierarchically structured space similar to the directory structure of a file system. When you create an entity, you can optionally designate another entity as its parent; the new entity is a child of the parent entity. This association between an entity and its parent is permanent, and cannot be changed once the entity is created. An entity without a parent is a root entity. The Datastore will never assign the same numeric ID to two entities with the same parent, or to two root entities (those without a parent).
An entity's parent, parent's parent, and so on recursively, are its ancestors; its children, children's children, and so on, are its descendants. The sequence of entities beginning with a root entity and proceeding from parent to child, leading to a given entity, constitute that entity's ancestor path. The complete key identifying the entity consists of a sequence of kind-identifier pairs specifying its ancestor path and terminating with those of the entity itself:
Person:GreatGrandpa / Person:Grandpa / Person:Dad / Person:Me
For a root entity, the ancestor path is empty and the key consists solely of the entity's own kind and identifier:
Person:GreatGrandpa
In addition to retrieving entities from the Datastore directly by their keys, an application can perform a query to retrieve them by the values of their properties. A query operates on entities of a given kind; it can specify filters on the entities' property values and keys, and can return zero or more entities as results. (To conserve memory and improve performance, the query should, whenever possible, specify a limit on the number of results returned.) A query can also specify sort orders to order the results by their property values. The results include all entities that have at least one (possibly null) value for every property named in the filters and sort orders, and whose property values meet all the specified filter criteria. The query can return either the entire entities or just their keys.
Every query uses an index, a table containing the query's results in the desired order. Indexes for some types of query are provided automatically; an App Engine application can define additional indexes for itself in a configuration file named datastore-indexes.xml
. The Datastore updates the indexes incrementally to reflect any changes the application makes to its entities. Thus the correct results of all queries are immediately available directly from the indexes, with no further computation needed.
The development web server automatically adds suggestions to the configuration file when it encounters queries that do not yet have indexes configured. You can tune indexes manually by editing the file before uploading the application; see the article Index Selection and Advanced Search for more information.
Note: This mechanism supports a wide range of queries and is suitable for most applications. However, it does not support some kinds of query common in other database technologies: in particular, joins and aggregate queries aren't supported within the query engine.
Every attempt to create, update, or delete an entity takes place in the context of a transaction. A single transaction can include any number of such operations. To maintain the consistency of the data, the transaction ensures that all of the operations it contains are applied to the Datastore as a unit or, if any of the operations fails, that none of them are applied.
You can perform multiple actions on an entity within a single transaction. For example, suppose you want to increment a counter field in an object. To do so, you need to read the value of the counter, calculate the new value, and then store it back. Without a transaction, it is possible for another process to increment the counter between the time you read the value and the time you update it, causing your application to overwrite the updated value. Doing the read, calculation, and write in a single transaction ensures that no other process can interfere with the increment.
A single transaction can apply to multiple entities, so long as the entities are descended from a common ancestor. Such entities are said to belong to the same entity group. For applications using the Master/Slave Datastore, all entities retrieved, created, updated, or deleted in a transaction must be in the same entity group; in the High Replication Datastore (HRD), the entities in a transaction can belong either to a single entity group or to different entity groups (see Cross-Group Transactions). In designing your data model, you should determine which entities you need to be able to process in the same transaction. Then, when you create those entities, place them in the same entity group by declaring them with a common ancestor. This tells App Engine that the entities will be updated together, so it can store them in a way that supports transactions.
The Datastore uses optimistic concurrency to manage transactions. When two or more application instances try to change the same entity group at the same time (either by updating existing entities or by creating new ones), the first application to commit its changes will succeed and all others will fail on commit. These other applications can then try their transactions again to apply them to the updated data. Note that because the Datastore works this way, using entity groups limits the number of concurrent writes you can do to any entity in a given group.
Applications using the HRD can perform transactions on entities belonging to different entity groups. Transactions of this type, called cross-group (XG) transactions, extend the behavior users experience with single-group transactions: an XG transaction will succeed as long as no concurrent transaction touches any of the entity groups to which it applies. This gives you more flexibility in organizing your data, because you aren't forced to put disparate pieces of data under the same ancestor just to perform atomic writes on them.
Note: The first read of an entity group in an XG transaction may throw
a
ConcurrentModificationException
if there is a conflict with other transactions accessing that same entity group. This means that an XG transaction that performs only reads can fail with a concurrency exception.
XG transactions can be used across a maximum of five entity groups. A transaction that touches only a single entity group behaves like a single-group transaction. Operations within such an XG transaction have the same performance and cost as the equivalent single-group transactions with regard to billing and resource usage, but will experience higher latency.
Similarly to single-group transactions, you cannot perform a non-ancestor query in an XG transaction. You can, however, perform ancestor queries on separate entity groups. Nontransactional (non-ancestor) queries may see all, some, or none of the results of a previously committed transaction. (For background on this issue, see Understanding Datastore Writes: Commit, Apply, and Data Visibility.) However, such nontransactional queries are more likely to see the results of a partially committed XG transaction than those of a partially commited single-group transaction.
The App Engine Datastore differs from a traditional relational database in several important ways:
For more in-depth information about the design of the Datastore, read our series of articles on Mastering the Datastore.
For a full discussion of this topic, see the articles Life of a Datastore Write and Transaction Isolation in App Engine.
For App Engine applications, data is written to the Datastore in two phases:
In the High Replication Datastore (HRD), the write operation returns immediately after the Commit phase and the Apply phase then takes place asynchronously; the Master/Slave Datastore usually doesn't return until the Apply phase is complete (both the data and the indexes have been written).
If a failure occurs during the Commit phase, there are automatic retries; but if failures continue, the Datastore returns an error message that your application receives as an exception. If the Commit phase succeeds but the Apply fails, the Apply is rolled forward to completion when one of the following occurs:
Note: In the Master/Slave Datastore, ancestor queries trigger an Apply only when they are included within a transaction.
This Datastore write behavior can have several implications for how and when data is visible to your application at different parts of the Commit and Apply phases:
The Datastore maintains statistics about the data stored for an application, such as how many entities there are of a given kind, or how much space is used by property values of a given type. You can view these statistics in the Administration Console under Datastore > Statistics.
You can also use the Datastore API to access these values programmatically from within the application by querying for specially named entities; see Datastore Statistics in Java for more information.
Data sent to the datastore by the app counts toward the Data Sent to (Datastore) API limit. Data received by the app from the datastore counts toward the Data Received from (Datastore) API limit.
The total amount of data currently stored in the datastore for the app cannot exceed the Stored Data (billable) limit. This includes all entity properties and keys and the indexes necessary to support querying these entities. See How Entities and Indexes are Stored for a complete breakdown of the metadata required to store entities and indexes at the Bigtable level.
For more information on system-wide safety limits, see Limits, and the "Quota Details" section of the Admin Console.
In addition to system-wide safety limits, the following limits apply specifically to the use of the datastore:
Limit | Amount |
---|---|
maximum entity size | 1 megabyte |
maximum number of values in all indexes for an entity |
5,000 values |
|