Consulte com filtros de intervalo e desigualdade na vista geral de várias propriedades
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
O Firestore no modo Datastore suporta a utilização de filtros de intervalo e de desigualdade em várias propriedades numa única consulta. Esta funcionalidade oferece-lhe condições de intervalo e desigualdade em várias propriedades e simplifica o desenvolvimento da sua aplicação delegando a implementação da lógica de pós-filtragem no Firestore no modo Datastore.
Filtros de intervalo e desigualdade em várias propriedades
A seguinte consulta usa filtros de intervalo na prioridade e nos dias para devolver todas as tarefas com uma prioridade superior a quatro e com menos de três dias para concluir.
Antes de começar a executar consultas, certifique-se de que leu informações sobre as consultas.
Se não for especificada uma cláusula ORDER BY, o Firestore no modo Datastore usa qualquer índice que
possa satisfazer a condição de filtro da consulta para publicar a consulta. Esta abordagem produz um conjunto de resultados ordenado de acordo com a definição do índice.
Para otimizar o desempenho e o custo das consultas do Firestore no modo Datastore,
otimize a ordem das propriedades no índice. Para isso, certifique-se de que o índice está ordenado da esquerda para a direita, de modo que a consulta seja reduzida a um conjunto de dados que impeça a análise de entradas de índice estranhas.
Por exemplo, suponhamos que quer pesquisar numa coleção de funcionários para
encontrar funcionários dos Estados Unidos cujo salário seja superior a 100 000 $e cujo número
de anos de experiência seja superior a 0. Com base na sua compreensão do conjunto de dados, sabe que a restrição de salário é mais seletiva do que a restrição de experiência. Um índice que reduz o número de análises de índice é o índice (salary [...], experience [...]). Como resultado, uma consulta rápida e rentável
de encomendas salary antes de experience, conforme mostrado no exemplo seguinte:
Quando otimizar os índices, tenha em atenção as seguintes práticas recomendadas.
Ordene as consultas por igualdades, seguidas do campo de intervalo ou desigualdade mais seletivo
O Firestore no modo Datastore usa as propriedades mais à esquerda de um índice composto para satisfazer as restrições de igualdade e a restrição de intervalo e desigualdade, se existir, no primeiro campo da consulta orderBy(). Estas restrições podem reduzir o número de entradas de índice que o Firestore no modo Datastore analisa. O Firestore no modo Datastore usa as propriedades restantes do índice para satisfazer outras restrições de intervalo e desigualdade da consulta. Estas restrições não reduzem o número de entradas de índice que o Firestore no modo Datastore analisa, mas filtram as entidades não correspondentes para que o número de entidades devolvidas aos clientes seja reduzido.
Ordene as propriedades por ordem decrescente de seletividade da restrição de consulta
Para garantir que o Firestore no modo Datastore seleciona o índice ideal para a sua consulta, especifique uma cláusula orderBy() que ordene as propriedades de intervalo e de desigualdade com base na seletividade das respetivas restrições na sua consulta, começando pela mais seletiva. Uma seletividade mais elevada corresponde a menos entidades, enquanto uma seletividade mais baixa corresponde a mais entidades. Na ordenação de índices, coloque propriedades de intervalo e desigualdade com maior seletividade antes de propriedades com menor seletividade.
Para minimizar o número de entidades que o Firestore no modo Datastore analisa e devolve através da rede, deve ordenar sempre as propriedades por ordem decrescente da seletividade da restrição da consulta. Se o conjunto de resultados não estiver na ordem necessária e o conjunto de resultados for pequeno, pode implementar uma lógica do lado do cliente para reordená-lo de acordo com a sua expetativa de ordenação.
Por exemplo, se quiser pesquisar numa coleção de funcionários para encontrar funcionários dos Estados Unidos cujo salário seja superior a 100 000 $e ordenar os resultados pelo ano de experiência do funcionário. Se esperar que apenas um pequeno número de funcionários tenha um salário superior a 100 000 €, uma forma eficiente de escrever a consulta é a seguinte:
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`
Embora a adição de uma ordenação em experience à consulta produza o mesmo conjunto de entidades e evite a reordenação dos resultados nos clientes, a consulta pode ler muito mais entradas de índice estranhas do que a consulta anterior. Isto acontece porque o Firestore no modo Datastore prefere sempre um índice cujas propriedades de índice correspondam ao prefixo da cláusula order by da consulta. Se experience fosse adicionado à cláusula ORDER BY, o Firestore no modo Datastore selecionaria o índice (experience [...], salary [...]) para calcular os resultados da consulta. Uma vez que não existem outras restrições em
experience, o Firestore no modo Datastore lê todas as entradas de índice da coleção employees antes de aplicar o filtro salary para encontrar o conjunto de resultados final. Isto significa que as entradas de índice que não satisfazem o filtro salary
são lidas na mesma, o que aumenta a latência e o custo da consulta.
Preços
As consultas com filtros de intervalo e desigualdade em várias propriedades são faturadas
com base nas entidades lidas e nas entradas de índice lidas.
Para obter informações detalhadas, consulte a página Preços.
Limitações
Além das limitações de consultas, tenha em atenção as seguintes limitações antes de usar consultas com filtros de intervalo e desigualdade em várias propriedades:
Para evitar que as consultas se tornem demasiado caras para executar, o Firestore no modo Datastore limita o número de operadores de intervalo ou de desigualdade a 10.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 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)."]]