{"componentChunkName":"component---src-templates-blog-post-js","path":"/blog/potega-podzapytan-w-cosmos-db","result":{"data":{"markdownRemark":{"html":"

Cosmos DB Query Playground to interaktywne środowisko do eksperymentowania z kwerendami do Cosmos DB. Jako dane testowe zawiera ono bazę produktów spożywczych wraz z informacjami o ich wartościach odżywczych. Przykładowy dokument wygląda mniej-więcej tak:

\n
{\n  \"food\": {\n    \"id\": \"14203\",\n    \"description\": \"Coffee, instant, regular, powder, half the caffeine\",\n    \"tags\": [\n      {\n        \"name\": \"coffee\"\n      },\n      {\n        \"name\": \"instant\"\n      },\n      ...\n      // pomijam resztę\n    ],\n    \"foodGroup\": \"Beverages\",\n    \"nutrients\": [\n      {\n        \"id\": \"204\",\n        \"description\": \"Total lipid (fat)\",\n        \"nutritionValue\": 0.5,\n        \"units\": \"g\"\n      },\n      {\n        \"id\": \"205\",\n        \"description\": \"Carbohydrate, by difference\",\n        \"nutritionValue\": 73.18,\n        \"units\": \"g\"\n      },\n      ...\n      // pomijam resztę\n    ]\n    ...\n    // pomijam resztę\n  }\n}
\n

Posłużmy się tym \"typem\" danych jako przykładem dla zobrazowania, jak bardzo mogą się różnić koszty zapytania.

\n

Załóżmy, że chcemy wybrać wszystkie produkty, które zawierają 1g lub więcej kofeiny. A zatem musimy dla każdego produkty wyszukać w liście nutrients elementu o description równym \"Caffeine\" oraz nutritionValue >= 1000.

\n

Podejście \"łopatologiczno-proceduralne\" może nas zaprowadzić do pomysłu, żeby dodać sobie user-defined-function, która \"opakuje\" te warunki, powiedzmy coś takiego:

\n
function hasHighLevelOfCaffeine(food) {\n  return food.nutrients.some(\n    n => n.description == \"Caffeine\" && n.nutritionValue >= 1000\n  )\n}
\n

Wówczas główne zaptanie się \"upraszcza\":

\n
SELECT food FROM food WHERE udf.hasHighLevelOfCaffeine(food)
\n

Problem z tym zapytaniem jest jednak taki, że zżera ono sporo RU. Na potrzeby obliczeń zrobiłem sobie przykładową bazę, gdzie miałem niecałe 2000 produktów i tylko jeden z \"wysokim poziomem kofeiny\". Dla takich dancyh zwykły select zeżarł ponad 600 RUs. Co gorsza - im więcej dokumentów w kolekcji, tym koszt będzie jeszcze większy. Wynika to prawdopodobnie z tego, że Cosmos nie potrafi sobie \"zoptymalizować\" zapytania z użyciem UDF, operującej na podkolekcji.

\n

Spróbujmy zatem do problemu podejść inaczej. Korzystając z dokumentacji możemy spróbować użyć podzapytania - tak byśmy przecież postąpili w \"zwykłym SQL-u\". (Mamy tu relację jeden-do-wielu, więc za pomocą EXISTS i podzapytania moglibyśmy to ograć.) W Cosmosie spraw wygląda podobnie, z tą różnicą, że używamy JOIN i podzapytania. Finalnie query wygląda tak:

\n
SELECT\nfood\nFROM food\nJOIN (SELECT VALUE n FROM n IN food.nutrients\nWHERE\n\tn.description = 'Caffeine' and n.nutritionValue >= 1000)
\n

Dla wspomnianej wyżej \"benchmarkowej\" bazy z 2000 produktów - to zapytanie \"kosztowało\" tylko 2 RU. I to w zasadzie niezależnie od ilości dokumentów.

\n

Ciekawe, prawda? :)

","excerpt":"Cosmos DB Query Playground to interaktywne środowisko do eksperymentowania z kwerendami do Cosmos DB. Jako dane testowe zawiera ono bazę produktów spożywczych…","frontmatter":{"date":"30 January, 2020","path":"/blog/potega-podzapytan-w-cosmos-db","title":"Potęga podzapytań w Cosmos DB"},"fields":{"readingTime":{"text":"2 min read"}}}},"pageContext":{}},"staticQueryHashes":["3649515864","63159454"]}