Cohérence des données dans les requêtes Datastore
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Niveaux de cohérence des données
Les requêtes Datastore peuvent produire des résultats à l'un des deux niveaux de cohérence suivants :
- Les requêtes fortement cohérentes garantissent l'obtention des résultats les plus récents, mais leur exécution peut prendre plus de temps.
- Les requêtes cohérentes à terme s'exécutent en règle générale plus rapidement, mais elles peuvent parfois renvoyer des résultats obsolètes.
Dans les requêtes cohérentes à terme, les index servant à la collecte des résultats sont également accessibles avec une cohérence à terme. Par conséquent, ces requêtes peuvent parfois afficher des entités qui ne correspondent plus aux critères de requête d'origine, alors que les requêtes fortement cohérentes sont toujours cohérentes de manière transactionnelle.
Cohérence des données de requête Datastore
En fonction de leur nature, les requêtes renvoient leurs résultats avec différents niveaux de garantie de cohérence :
- Les requêtes ascendantes (celles exécutées dans un groupe d'entités) sont fortement cohérentes par défaut, mais vous pouvez les rendre cohérentes à terme en définissant les règles de lecture Datastore (voir ci-dessous).
- Les requêtes non ascendantes sont toujours cohérentes à terme.
La récupération d'une entité par clé, également appelée "recherche par clé", offre une cohérence forte.
Définir les règles de lecture Datastore
Pour améliorer les performances, vous pouvez définir les règles de lecture Datastore afin que toutes les lectures et requêtes soient cohérentes à terme. L'API vous permet également de définir explicitement des règles de cohérence forte, mais ce paramètre n'aura aucun effet pratique, car les requêtes non ascendantes sont toujours cohérentes, quelles que soient les règles.
Vous pouvez également définir la
durée maximale de l'appel à Datastore, qui correspond au délai maximal, en secondes, pendant lequel l'application attend que Datastore affiche un résultat avant d'abandonner en générant une erreur. La durée par défaut est de 60 secondes. Pour le moment, il n'est pas possible d'augmenter cette valeur, mais vous pouvez définir une durée plus courte pour garantir qu'une opération particulière échoue rapidement (par exemple, pour afficher une réponse plus rapide à l'utilisateur).
Pour définir les règles de lecture Datastore en Java, vous construisez une
configuration de service Datastore (
DatastoreServiceConfig
) à l'aide de la classe d'assistance imbriquée
DatastoreServiceConfig.Builder
et lui transmettez une instance de classe
ReadPolicy
. L'exemple suivant montre comment définir les règles de lecture, la durée maximale de l'appel, ou les deux :
Étape suivante
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/04 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 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."]]