Consultar con filtros de intervalo y de desigualdad en varias propiedades
Organízate con las colecciones
Guarda y clasifica el contenido según tus preferencias.
Firestore en el modo de Datastore admite el uso de filtros de intervalo y de desigualdad en varias propiedades en una sola consulta. Esta función te permite usar condiciones de intervalo y de desigualdad en varias propiedades, así como simplificar el desarrollo de tu aplicación delegando la implementación de la lógica de postfiltrado en Firestore en modo Datastore.
Filtros de intervalo y de desigualdad en varias propiedades
La siguiente consulta usa filtros de intervalo en la prioridad y los días para devolver todas las tareas con una prioridad superior a cuatro y con menos de tres días para completarse.
Antes de empezar a ejecutar consultas, asegúrate de haber leído información sobre las consultas.
Si no se especifica ninguna cláusula ORDER BY, Firestore en modo Datastore usa cualquier índice que pueda satisfacer la condición de filtro de la consulta para servirla. Este enfoque genera un conjunto de resultados ordenado según la definición del índice.
Para optimizar el rendimiento y el coste de las consultas de Firestore en el modo de Datastore, optimiza el orden de las propiedades en el índice. Para ello, asegúrate de que tu índice esté ordenado de izquierda a derecha para que la consulta se limite a un conjunto de datos que impida el análisis de entradas de índice extrañas.
Por ejemplo, supongamos que quieres buscar en una colección de empleados a los que residen en Estados Unidos,cuyo salario es superior a 100.000 $y que tienen más de 0 años de experiencia. Según tu conocimiento del conjunto de datos, sabes que la restricción de salario es más selectiva que la de experiencia. Un índice que reduce el número de análisis de índices es el (salary [...], experience [...])índice. Por lo tanto, las consultas rápidas y rentables ordenan salary antes de experience, como se muestra en el siguiente ejemplo:
Cuando optimices los índices, ten en cuenta las siguientes prácticas recomendadas.
Ordenar las consultas por igualdades seguidas del campo de intervalo o desigualdad más selectivo
Firestore en modo Datastore usa las propiedades situadas más a la izquierda de un índice compuesto para cumplir las restricciones de igualdad y las restricciones de intervalo y desigualdad, si las hay, del primer campo de la consulta orderBy(). Estas restricciones pueden reducir el número de entradas de índice que escanea Firestore en el modo de Datastore. Firestore en el modo de Datastore usa las propiedades restantes del índice para satisfacer otras restricciones de intervalo y desigualdad de la consulta. Estas restricciones no reducen el número de entradas de índice que escanea Firestore en el modo Datastore, pero filtran las entidades que no coinciden para que se reduzca el número de entidades que se devuelven a los clientes.
Ordena las propiedades en orden decreciente de selectividad de la restricción de consulta
Para asegurarte de que Firestore en el modo de Datastore selecciona el índice óptimo para tu consulta, especifica una cláusula orderBy() que ordene las propiedades de intervalo y de desigualdad en función de lo selectivas que sean sus restricciones en tu consulta, empezando por la más selectiva. Una selectividad más alta coincide con menos entidades, mientras que una selectividad más baja coincide con más entidades. En el orden de tu índice, coloca las propiedades de intervalo y desigualdad con mayor selectividad antes de las propiedades con menor selectividad.
Para minimizar el número de entidades que Firestore en el modo de Datastore analiza y devuelve a través de la red, siempre debes ordenar las propiedades de mayor a menor selectividad de las restricciones de consulta. Si el conjunto de resultados no está en el orden requerido y se espera que sea pequeño, puede implementar una lógica del lado del cliente para reordenarlo según sus expectativas.
Por ejemplo, si quieres buscar en una colección de empleados a los que residen en Estados Unidos y cuyo salario es superior a 100.000 USD,y ordenar los resultados por los años de experiencia de los empleados. Si crees que solo un pequeño número de empleados tendrá un salario superior a 100.000 USD, una forma eficiente de escribir la consulta es la siguiente:
Java
Query<Entity>query=Query.newEntityQueryBuilder().setKind("employees").setFilter(PropertyFilter.gt("salary",100000)).setOrderBy(OrderBy("salary")).build();QueryResults<Entity>results=datastore.run(query);// Order results by `experience`
Node.js
constquery=datastore.createQuery("employees").filter(newPropertyFilter("salary",">",100000)).order("salary");const[entities]=awaitdatastore.runQuery(query);// Order results by `experience`
Aunque añadir un orden a experience en la consulta dará como resultado el mismo conjunto de entidades y evitará que se vuelvan a ordenar los resultados en los clientes, la consulta puede leer muchas más entradas de índice extrañas que la consulta anterior. Esto se debe a que Firestore en el modo de Datastore siempre prefiere un índice cuyas propiedades de índice coincidan con el prefijo de la cláusula "order by" de la consulta. Si se añade experience a la cláusula "order by", Firestore en modo Datastore seleccionará el índice (experience [...], salary [...]) para calcular los resultados de la consulta. Como no hay otras restricciones en experience, Firestore en el modo de Datastore leerá todas las entradas de índice de la colección employees antes de aplicar el filtro salary para encontrar el conjunto de resultados final. Esto significa que las entradas de índice que no cumplen el filtro salary
se siguen leyendo, lo que aumenta la latencia y el coste de la consulta.
Precios
Las consultas con filtros de intervalo y de desigualdad en varias propiedades se facturan en función de las entidades leídas y las entradas de índice leídas.
Para obtener información detallada, consulta la página Precios.
Limitaciones
Además de las limitaciones de las consultas, ten en cuenta las siguientes limitaciones antes de usar consultas con filtros de intervalo y de desigualdad en varias propiedades:
Para evitar que las consultas sean demasiado caras, Firestore en el modo de Datastore limita el número de operadores de intervalo o de desigualdad a 10.
[[["Es fácil de entender","easyToUnderstand","thumb-up"],["Me ofreció una solución al problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Es difícil de entender","hardToUnderstand","thumb-down"],["La información o el código de muestra no son correctos","incorrectInformationOrSampleCode","thumb-down"],["Me faltan las muestras o la información que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-08-21 (UTC)."],[[["\u003cp\u003eFirestore in Datastore mode allows for range and inequality filters on multiple properties within a single query, simplifying application development.\u003c/p\u003e\n"],["\u003cp\u003eQueries with multiple range and inequality filters can be optimized by ordering properties in the index from most to least selective, to minimize index scans.\u003c/p\u003e\n"],["\u003cp\u003eWhen using the \u003ccode\u003eorderBy()\u003c/code\u003e clause, ensure that it prioritizes equality constraints and the most selective range or inequality fields, followed by other constraints.\u003c/p\u003e\n"],["\u003cp\u003eQueries are billed based on the number of entities and index entries read, and there is a limitation of up to 10 range or inequality operators per query.\u003c/p\u003e\n"],["\u003cp\u003eIt's recommended to read about query optimization, index usage, and performing simple and compound queries for a deeper understanding.\u003c/p\u003e\n"]]],[],null,["# Query with range and inequality filters on multiple properties overview\n\nFirestore in Datastore mode supports using range and inequality filters on multiple properties in a single query. This feature gives you range and inequality conditions on multiple properties and simplifies\nyour application development by delegating implementation of post-filtering\nlogic to Firestore in Datastore mode.\n\nRange and inequality filters on multiple properties\n---------------------------------------------------\n\nThe following query uses range filters on priority and days to return all tasks\nwith priority greater than four and with less than three days to complete. \n\n### Go\n\n query := datastore.NewQuery(\"Task\").\n FilterField(\"priority\", \"\u003e\", 4).\n FilterField(\"days\", \"\u003c\", 3).\n\n### GQL\n\n SELECT * FROM /tasks WHERE priority \u003e 4 AND days \u003c 3;\n\n### Java\n\n Query\u003cEntity\u003e query =\n Query.newEntityQueryBuilder()\n .setKind(\"Task\")\n .setFilter(\n CompositeFilter.and(\n PropertyFilter.gt(\"priority\", 4), PropertyFilter.lt(\"days\", 3)))\n .build();\n\n### Node.js\n\n const query = datastore\n .createQuery('Task')\n .filter(\n and([\n new PropertyFilter('priority', '\u003e', 4),\n new PropertyFilter('days', '\u003c', 3),\n ])\n );\n\n### Python\n\n from google.cloud import https://cloud.google.com/python/docs/reference/datastore/latest/\n client = https://cloud.google.com/python/docs/reference/datastore/latest/.https://cloud.google.com/python/docs/reference/datastore/latest/google.cloud.datastore.client.Client.html()\n query = client.https://cloud.google.com/python/docs/reference/datastore/latest/google.cloud.datastore.client.Client.html#google_cloud_datastore_client_Client_query(kind=\"Task\")\n query.https://cloud.google.com/python/docs/reference/datastore/latest/google.cloud.datastore.query.Query.html#google_cloud_datastore_query_Query_add_filter(filter=PropertyFilter(\"priority\", \"\u003e\", 4))\n query.https://cloud.google.com/python/docs/reference/datastore/latest/google.cloud.datastore.query.Query.html#google_cloud_datastore_query_Query_add_filter(filter=PropertyFilter(\"days\", \"\u003c\", 3))\n\n### PHP\n\n $query = $datastore-\u003equery()\n -\u003ekind('Task')\n -\u003efilter('priority', '\u003e', 4)\n -\u003efilter('days', '\u003c', 3)\n\n### C#\n\n Query query = new Query(\"Task\")\n {\n Filter = Filter.And(Filter.GreaterThan(\"priority\", 4),\n Filter.LessThan(\"days\", 3))\n };\n\n### Ruby\n\n query = datastore.query(\"Task\")\n .where(\"priority\", \"\u003e\", 4)\n .where(\"days\", \"\u003c\", 3)\n\nIndexing considerations\n-----------------------\n\nBefore you start running queries, make sure you have read\nabout [queries](/datastore/docs/concepts/queries).\n\nIf an `ORDER BY` clause isn't specified, Firestore in Datastore mode uses any index that\ncan satisfy the query's filter condition to serve the query. This approach produces a result\nset that is ordered according to the index definition.\n\nTo optimize the performance and cost of Firestore in Datastore mode queries,\noptimize the order of properties in the index. To do this, ensure that your\nindex is ordered from left to right so that the query distills to a\ndataset that prevents scanning of extraneous index entries.\n\nFor example, suppose you want to search through a collection of employees to\nfind United States employees whose salary is more than $100,000 and whose number\nof years of experience is greater than 0. Based on your understanding of the\ndataset, you know that the salary constraint is more selective than the\nexperience constraint. An index that reduces the number of index scans is the\n`(salary [...], experience [...])` index. As a result, a fast and cost-efficient\nquery orders `salary` before `experience`, as shown in the following example: \n\n### GQL\n\n SELECT *\n FROM /employees\n WHERE salary \u003e 100000 AND experience \u003e 0\n ORDER BY salary, experience\n\n### Java\n\n Query\u003cEntity\u003e query =\n Query.newEntityQueryBuilder()\n .setKind(\"employees\")\n .setFilter(\n CompositeFilter.and(\n PropertyFilter.gt(\"salary\", 100000), PropertyFilter.gt(\"experience\", 0)))\n .setOrderBy(OrderBy(\"salary\"), OrderBy(\"experience\"))\n .build();\n\n### Node.js\n\n const query = datastore\n .createQuery(\"employees\")\n .filter(\n and([\n new PropertyFilter(\"salary\", \"\u003e\", 100000),\n new PropertyFilter(\"experience\", \"\u003e\", 0),\n ])\n )\n .order(\"salary\")\n .order(\"experience\");\n\n### Python\n\n query = client.query(kind=\"employees\")\n query.add_filter(\"salary\", \"\u003e\", 100000)\n query.add_filter(\"experience\", \"\u003e\", 0)\n query.order = [\"-salary\", \"-experience\"]\n\nBest practices for optimizing indexes\n-------------------------------------\n\nWhen optimizing indexes, note the following best practices.\n\n#### Order queries by equalities followed by most selective range or inequality field\n\nFirestore in Datastore mode uses the leftmost properties of a composite index to satisfy\nthe equality constraints and the range and inequality constraint, if any, on the\nfirst field of the `orderBy()` query. These constraints can reduce the number of\nindex entries that Firestore in Datastore mode scans. Firestore in Datastore mode uses the remaining\nproperties of the index to satisfy other range and inequality constraints of the\nquery. These constraints don't reduce the number of index entries that\nFirestore in Datastore mode scans, but they filter out unmatched entities so that the number of\nentities that are returned to the clients are reduced.\n\nFor more information about creating efficient indexes, see [index structure and\ndefinition](/datastore/docs/concepts/indexes) and [optimizing indexes](/datastore/docs/concepts/optimize-indexes).\n\n#### Order properties in decreasing order of query constraint selectivity\n\nTo ensure that Firestore in Datastore mode selects the optimal index for your query,\nspecify an `orderBy()` clause that orders range and inequality properties based\non how selective their constraints are in your query, starting from the most\nselective. Higher selectivity matches fewer entities, while lower selectivity\nmatches more entities. In your index ordering, put range and inequality\nproperties with higher selectivity before properties with lower selectivity.\n\nTo minimize the number of entities that Firestore in Datastore mode scans and returns over\nthe network, you should always order properties in the decreasing order of query\nconstraint selectivity. If the result set is not in the required order and the\nresult set is expected to be small, you can implement client-side logic to\nreorder it as per your ordering expectation.\n\nFor example, if you want to search through a collection of employees to\nfind United States employees whose salary is more than $100,000 and order the results by the\nyear of experience of the employee. If you expect that only a small number of\nemployees will have salary higher than $100,000, then an efficient way to\nwrite the query is as follows: \n\n### Java\n\n Query\u003cEntity\u003e query =\n Query.newEntityQueryBuilder()\n .setKind(\"employees\")\n .setFilter(PropertyFilter.gt(\"salary\", 100000))\n .setOrderBy(OrderBy(\"salary\"))\n .build();\n QueryResults\u003cEntity\u003e results = datastore.run(query);\n // Order results by `experience`\n\n### Node.js\n\n const query = datastore\n .createQuery(\"employees\")\n .filter(new PropertyFilter(\"salary\", \"\u003e\", 100000))\n .order(\"salary\");\n const [entities] = await datastore.runQuery(query);\n // Order results by `experience`\n\n### Python\n\n query = client.query(kind=\"employees\")\n query.add_filter(\"salary\", \"\u003e\", 100000)\n query.order = [\"salary\"]\n results = query.fetch()\n // Order results by `experience`\n\nWhile adding an ordering on `experience` to the query will yield the same set\nof entities and obviate re-ordering the results on the clients, the query may\nread many more extraneous index entries than the earlier query. This is because\nFirestore in Datastore mode always prefers an index whose index properties prefix match the\norder by clause of the query. If `experience` were added to the order by clause,\nthen Firestore in Datastore mode will select the `(experience [...], salary [...])` index\nfor computing query results. Since there are no other constraints on\n`experience`, Firestore in Datastore mode will read **all** index entries of the\n`employees` collection before applying the `salary` filter to find the final\nresult set. This means that index entries which don't satisfy the `salary`\nfilter are still read, thus increasing the latency and cost of the query.\n\nPricing\n-------\n\nQueries with range and inequality filters on multiple properties are billed\nbased on entities read and index entries read.\n\nFor detailed information, see the [Pricing](/datastore/docs/pricing) page.\n\nLimitations\n-----------\n\nApart from the [query limitations](/datastore/docs/concepts/queries#limitations_2), note the following limitations before\nusing queries with range and inequality filters on multiple properties:\n\n- To prevent queries from becoming too expensive to run, Firestore in Datastore mode limits the number of range or inequality operators to 10.\n\nWhat's Next\n-----------\n\n- Learn about [optimizing your queries](/datastore/docs/multiple-range-optimize-indexes).\n- Learn more about [performing simple and compound queries](/datastore/docs/concepts/queries).\n- Understand how [Firestore in Datastore mode uses indexes](/datastore/docs/concepts/indexes)."]]