Огромные различия в производительности между Order By ASC и DESC - PullRequest
Новая
       12

Огромные различия в производительности между Order By ASC и DESC

0 голосов
/ 19 февраля 2019

Я записываю огромную разницу между ORDER BY ASC и DESC в CosmosDB SQL API.ASC почти в 200 раз дешевле в RU, чем DESC.

Вот вывод из моего инструмента тестирования: 

INFO ------------------- QUERY -----------------

SELECT TOP 100 * FROM root
WHERE
    root.projectId = '783af8f2-8e2f-0083-5d86-2f60f34e11b4'
        AND NOT ARRAY_CONTAINS(root.translatedLanguages, '0d42a87f-4d68-417b-99a9-a228cb63edce')
ORDER BY root._srtDue DESC


INFO ------------------- ROUND 1 -----------------
INFO Request Charge: 2532.53
INFO Count: 100
INFO Metrics: {
  "TotalTime": "00:00:01.7036800",
  "RetrievedDocumentCount": 38238,
  "RetrievedDocumentSize": 236459696,
  "OutputDocumentCount": 100,
  "IndexHitRatio": 0.0,
  "QueryPreparationTimes": {
    "CompileTime": "00:00:00.0001900",
    "LogicalPlanBuildTime": "00:00:00.0000700",
    "PhysicalPlanBuildTime": "00:00:00.0000600",
    "QueryOptimizationTime": "00:00:00.0000100"
  },
  "QueryEngineTimes": {
    "IndexLookupTime": "00:00:00.0298500",
    "DocumentLoadTime": "00:00:01.4093599",
    "WriteOutputTime": "00:00:00.0001300",
    "RuntimeExecutionTimes": {
      "TotalTime": "00:00:00.2636001",
      "SystemFunctionExecutionTime": "00:00:00.0132800",
      "UserDefinedFunctionExecutionTime": "00:00:00"
    }
  },
  "Retries": 0
}

против 

INFO ------------------- QUERY -----------------

SELECT TOP 100 * FROM root
WHERE
    root.projectId = '783af8f2-8e2f-0083-5d86-2f60f34e11b4'
        AND NOT ARRAY_CONTAINS(root.translatedLanguages, '0d42a87f-4d68-417b-99a9-a228cb63edce')
ORDER BY root._srtDue ASC


INFO ------------------- ROUND 1 -----------------
INFO Request Charge: 14.22
INFO Count: 100
INFO Metrics: {
  "TotalTime": "00:00:00.0047500",
  "RetrievedDocumentCount": 131,
  "RetrievedDocumentSize": 187130,
  "OutputDocumentCount": 100,
  "IndexHitRatio": 0.75572519083969469,
  "QueryPreparationTimes": {
    "CompileTime": "00:00:00.0001300",
    "LogicalPlanBuildTime": "00:00:00.0000700",
    "PhysicalPlanBuildTime": "00:00:00.0000600",
    "QueryOptimizationTime": "00:00:00.0000100"
  },
  "QueryEngineTimes": {
    "IndexLookupTime": "00:00:00.0010400",
    "DocumentLoadTime": "00:00:00.0020299",
    "WriteOutputTime": "00:00:00.0002200",
    "RuntimeExecutionTimes": {
      "TotalTime": "00:00:00.0008301",
      "SystemFunctionExecutionTime": "00:00:00.0000500",
      "UserDefinedFunctionExecutionTime": "00:00:00"
    }
  },
  "Retries": 0
}

Я не нашел, как именнорассчитывается ли IndexHitRatio и как планируется выполнение Cosmos DB, но мне кажется, что в данном конкретном случае он запускает предикаты для документов в указанном направлении, а документы, выполняющие эти предикаты, находятся в конце этого порядка сортировки, поэтому он долженпрочитайте много документов, 38 КБ, чтобы получить эти ТОП 100 выходных документов.

Мы считаем, что мы все правильно проиндексировали: 

path": "/*",
            "indexes": [
                {
                    "kind": "Range",
                    "dataType": "Number",
                    "precision": -1
                },
                {
                    "kind": "Range",
                    "dataType": "String",
                    "precision": -1
                }
            ]
...
"path": "/translatedLanguages/[]/?",
            "indexes": [
                {
                    "kind": "Range",
                    "dataType": "String",
                    "precision": -1
                },
                {
                    "kind": "Range",
                    "dataType": "Number",
                    "precision": -1
                }
            ]

К сожалению, эта производительность неприемлема для нашего варианта использования иесли мы не решим это каким-либо образом, мы будем вынуждены изменить движок базы данных.

Есть ли способ каким-то образом изменить этот план выполнения для повышения производительности?

...