Coherencia de los datos de consulta de Datastore
Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Niveles de coherencia de datos
Las consultas en Datastore pueden arrojar resultados en uno de los dos niveles de coherencia:
- Coherencia sólida: Estas consultas garantizan que los resultados incluyan la información más reciente, pero pueden tomar más tiempo en completarse.
- Coherencia eventual: Estas consultas suelen ejecutarse más rápido, pero a veces pueden mostrar resultados obsoletos.
En una consulta de coherencia eventual, también se accede a los índices usados para reunir los resultados con coherencia eventual. Por lo tanto, esas consultas, a veces, pueden mostrar entidades que ya no coinciden con los criterios originales de la consulta, al tiempo que las consultas de coherencia sólida siempre son coherentes entre las transacciones.
Coherencia de los datos de consulta de Datastore
Las consultas muestran sus resultados con distintos niveles de garantía de coherencia, según la naturaleza de la consulta.
- De forma predeterminada, las consultas principales (las que están dentro de un grupo de entidades) tienen coherencia sólida. Sin embargo, se puede modificar la política de lectura de Datastore (detallada a continuación) para hacer que tengan coherencia eventual.
- Las consultas que no son principales siempre son de coherencia eventual.
La recuperación de una entidad por clave, también denominada “búsqueda por clave”, es de coherencia sólida.
Configura la política de lectura de Datastore
Para mejorar el rendimiento, puedes configurar la política de lectura de Datastore de modo que todas las lecturas y consultas tengan una coherencia eventual. (La API también te permite establecer de forma explícita una política de coherencia sólida, pero esta configuración no tendrá efectos prácticos, ya que las consultas que no son principales son siempre de coherencia eventual sin importar la política).
También puedes establecer el
plazo de llamada de Datastore, que es el tiempo máximo, en segundos, que la aplicación esperará para que Datastore muestre un resultado antes de abortar con un error. El plazo predeterminado es de 60 segundos. Actualmente no se puede establecer un plazo más largo, pero sí puedes reducirlo a fin de asegurarte de que una operación determinada falle rápido (por ejemplo, para mostrarle una respuesta más rápida al usuario).
Para establecer la política de lectura de Datastore en Java, crea una
configuración del servicio de Datastore (
DatastoreServiceConfig
) mediante la clase auxiliar anidada
DatastoreServiceConfig.Builder
y pásale una instancia de la clase
ReadPolicy
. En el ejemplo siguiente, se muestra cómo configurar la política de lectura, el plazo de llamada o ambos:
Próximos pasos
Salvo que se indique lo contrario, el contenido de esta página está sujeto a la licencia Atribución 4.0 de Creative Commons, y los ejemplos de código están sujetos a la licencia Apache 2.0. Para obtener más información, consulta las políticas del sitio de Google Developers. Java es una marca registrada de Oracle o sus afiliados.
Última actualización: 2025-09-04 (UTC)
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-09-04 (UTC)"],[[["\u003cp\u003eThis API supports first-generation runtimes and is relevant when upgrading to second-generation runtimes, while migration to Java 11/17 requires a separate migration guide.\u003c/p\u003e\n"],["\u003cp\u003eDatastore queries offer two consistency levels: strongly consistent queries, which guarantee the freshest results but may be slower, and eventually consistent queries, which are generally faster but may return stale results.\u003c/p\u003e\n"],["\u003cp\u003eAncestor queries are strongly consistent by default but can be set to eventually consistent, while non-ancestor queries are always eventually consistent.\u003c/p\u003e\n"],["\u003cp\u003eThe Datastore read policy can be set to eventually consistent to improve performance, and the call deadline can be adjusted to control the maximum wait time for a Datastore operation.\u003c/p\u003e\n"],["\u003cp\u003eDevelopers can use the \u003ccode\u003eDatastoreServiceConfig\u003c/code\u003e to set the read policy and/or the call deadline for Datastore operations, using the \u003ccode\u003eReadPolicy\u003c/code\u003e for consistency and \u003ccode\u003ewithDeadline\u003c/code\u003e for the time limit, and can use the \u003ccode\u003eDatastoreServiceFactory\u003c/code\u003e to get a \u003ccode\u003eDatastoreService\u003c/code\u003e instance with the desired configuration.\u003c/p\u003e\n"]]],[],null,["# Data Consistency in Datastore Queries\n\n| This API is supported for first-generation runtimes and can be used when [upgrading to corresponding second-generation runtimes](/appengine/docs/standard/\n| java-gen2\n|\n| /services/access). If you are updating to the App Engine Java 11/17 runtime, refer to the [migration guide](/appengine/migration-center/standard/migrate-to-second-gen/java-differences) to learn about your migration options for legacy bundled services.\n\nData consistency levels\n-----------------------\n\nDatastore queries can deliver their results at either of two consistency\nlevels:\n\n- [*Strongly consistent*](https://en.wikipedia.org/wiki/Strong_consistency) queries guarantee the freshest results, but may take longer to complete.\n- [*Eventually consistent*](https://en.wikipedia.org/wiki/Eventual_consistency) queries generally run faster, but may occasionally return stale results.\n\nIn an eventually consistent query, the indexes used to gather the results are also accessed with eventual consistency. Consequently, such queries may sometimes return entities that no longer match the original query criteria, while strongly consistent queries are always transactionally consistent.\n\nDatastore query data consistency\n--------------------------------\n\nQueries return their results with different levels of consistency guarantee, depending on the nature of the query:\n\n- [Ancestor queries](/appengine/docs/legacy/standard/java/datastore/queries#ancestor_queries) (those within an [entity group](/appengine/docs/legacy/standard/java/datastore/entities#Ancestor_paths)) are strongly consistent by default, but can instead be made eventually consistent by setting the Datastore read policy (see below).\n- Non-ancestor queries are always eventually consistent.\n\nFetching an entity by key, which is also called \"lookup by key\", is strongly\nconsistent.\n\n\u003cbr /\u003e\n\nSetting the Datastore read policy\n---------------------------------\n\nTo improve performance, you can set the Datastore *read policy* so that all reads and queries are eventually consistent. (The API also allows you to explicitly set a strong consistency policy, but this setting will have no practical effect, since non-ancestor queries are always eventually consistent regardless of policy.)\nYou can also set the Datastore *call deadline* , which is the maximum time, in seconds, that the application will wait for Datastore to return a result before aborting with an error. The default deadline is 60 seconds; it is not currently possible to set it higher, but you can adjust it downward to ensure that a particular operation fails quickly (for instance, to return a faster response to the user).\n\n\u003cbr /\u003e\n\nTo set the Datastore read policy in Java, you construct a *Datastore service configuration* ([`DatastoreServiceConfig`](/appengine/docs/legacy/standard/java/javadoc/com/google/appengine/api/datastore/DatastoreServiceConfig)), using the nested helper class [`DatastoreServiceConfig.Builder`](/appengine/docs/legacy/standard/java/javadoc/com/google/appengine/api/datastore/DatastoreServiceConfig.Builder), and pass it an instance of class [`ReadPolicy`](/appengine/docs/legacy/standard/java/javadoc/com/google/appengine/api/datastore/ReadPolicy). The following example shows how to set the read policy, the call deadline, or both:\n\n\u003cbr /\u003e\n\n double deadline = 5.0;\n\n // Construct a read policy for eventual consistency\n ReadPolicy policy = new ReadPolicy(ReadPolicy.Consistency.EVENTUAL);\n\n // Set the read policy\n DatastoreServiceConfig eventuallyConsistentConfig =\n DatastoreServiceConfig.Builder.withReadPolicy(policy);\n\n // Set the call deadline\n DatastoreServiceConfig deadlineConfig = DatastoreServiceConfig.Builder.withDeadline(deadline);\n\n // Set both the read policy and the call deadline\n DatastoreServiceConfig datastoreConfig =\n DatastoreServiceConfig.Builder.withReadPolicy(policy).deadline(deadline);\n\n // Get Datastore service with the given configuration\n DatastoreService datastore = DatastoreServiceFactory.getDatastoreService(datastoreConfig);\n\nWhat's next?\n------------\n\n- [Learn how to specify what a query returns and further control query results](/appengine/docs/legacy/standard/java/datastore/retrieving-query-results).\n- Learn the [common restrictions](/appengine/docs/legacy/standard/java/datastore/query-restrictions) for queries on Datastore.\n- Learn about [query cursors](/appengine/docs/legacy/standard/java/datastore/query-cursors), which allow an application to retrieve a query's results in convenient batches.\n- Learn the [basic syntax and structure of queries](/appengine/docs/legacy/standard/java/datastore/queries) for Datastore."]]