Ограничения SQL

Чрезвычайно большие запросы могут потреблять слишком много памяти на стадии парсинга, в этом случае движок Elasticsearch SQL прервёт парсинг и выдаст ошибку. В таких случаях рекомендуется уменьшить размер запроса, потенциально упростив его или разделив на несколько меньших запросов.

Elasticsearch имеет специальный тип полей, называемых полями nested. В Elasticsearch SQL они могут использоваться путём обращения к их внутренним подполям. Несмотря на то, что SYS COLUMNS в режиме без драйвера (в консоли и в REST-вызовах) и DESCRIBE TABLE по-прежнему будут отображать их как имеющие тип NESTED, их нельзя использовать в запросе. Можно ссылаться только на его подполя в виде:

[nested_field_name].[sub_field_name]

Например:

SELECT dep.dep_name.keyword FROM test_emp GROUP BY languages;

Elasticsearch SQL не поддерживает использование скалярных функций над вложенными полями в клаузах WHERE и ORDER BY, за исключением сравнений и логических операторов.

Например:

SELECT * FROM test_emp WHERE LENGTH(dep.dep_name.keyword) > 5;

и

SELECT * FROM test_emp ORDER BY YEAR(dep.start_date);

не поддерживаются, но:

SELECT * FROM test_emp WHERE dep.start_date >= CAST('2020-01-01' AS DATE) OR dep.dep_end_date IS NULL;

поддерживается.

Elasticsearch SQL не поддерживает многоуровневые вложенные документы, поэтому запрос не может ссылаться более чем на одно вложенное поле в индексе. Это относится к многоуровневым вложенным полям, а также к нескольким вложенным полям, определённым на одном уровне. Например, для данного индекса:

       column         |     type      |    mapping
----------------------+---------------+-------------
nested_A              |STRUCT         |NESTED
nested_A.nested_X     |STRUCT         |NESTED
nested_A.nested_X.text|VARCHAR        |KEYWORD
nested_A.text         |VARCHAR        |KEYWORD
nested_B              |STRUCT         |NESTED
nested_B.text         |VARCHAR        |KEYWORD

nested_A и nested_B не могут быть использованы одновременно, так же как и nested_A/nested_B и nested_A.nested_X комбинация. В таких ситуациях Elasticsearch SQL отобразит сообщение об ошибке.

При выборке вложенного поля пейджинг будет работать не так, как ожидается, Elasticsearch SQL вернёт по крайней мере заданное количество записей. Это связано с тем, как работают вложенные запросы в Elasticsearch: корневое вложенное поле будет возвращено, а также соответствующие ему внутренние вложенные поля, пейджинг происходит на уровне корневого вложенного документа, а не на его внутренних хитах.

Поля keyword в Elasticsearch могут быть нормализованы путём определения normalizer. Такие поля не поддерживаются в Elasticsearch SQL.

Поля типа массив не поддерживаются из-за "скрытого" способа обработки Elasticsearch массива значений: сопоставление не указывает, является ли поле массивом (имеет несколько значений) или нет, поэтому без чтения всех данных Elasticsearch SQL не может узнать, является ли поле одно- или многозначным. Если для поля возвращаются несколько значений, Elasticsearch SQL по умолчанию выбросит исключение. Однако можно изменить это поведение с помощью параметра field_multi_value_leniency в REST (отключено по умолчанию) или параметра field.multi.value.leniency в драйверах (включено по умолчанию).

При выполнении агрегаций (GROUP BY) Elasticsearch SQL полагается на агрегацию composite Elasticsearch для поддержки пейджинга результатов. Однако этот тип агрегации имеет ограничение: сортировка может быть применена только к ключу, используемому для ведер агрегации. Elasticsearch SQL преодолевает это ограничение путём выполнения сортировки на стороне клиента, однако в целях безопасности разрешает только до 65535 строк.

Рекомендуется использовать LIMIT для запросов, использующих сортировку по агрегации, фактически указывая желаемый верхний N результатов:

SELECT * FROM test GROUP BY age ORDER BY COUNT(*) LIMIT 100;

Можно выполнить те же запросы без LIMIT, однако в этом случае, если максимальный размер (10000) будет превышен, будет возвращено исключение, так как Elasticsearch SQL не может отследить (и отсортировать) все возвращаемые результаты.

Кроме того, используемые в клаузе ORDER BY агрегации должны быть только простыми агрегирующими функциями. Нельзя использовать скалярные функции или операторы, а значит, нельзя использовать сложные столбцы, объединяющие две или более агрегирующие функции для сортировки. Вот несколько примеров запросов, которые не допускаются:

SELECT age, ROUND(AVG(salary)) AS avg FROM test GROUP BY age ORDER BY avg;

SELECT age, MAX(salary) - MIN(salary) AS diff FROM test GROUP BY age ORDER BY diff;

Использование подзапросов (SELECT X FROM (SELECT Y)) частично поддерживается: любой подзапрос, который может быть "разворотён" в единственный SELECT, возможен в Elasticsearch SQL. Например:

SELECT * FROM (SELECT first_name, last_name FROM emp WHERE last_name NOT LIKE '%a%') WHERE first_name LIKE 'A%' ORDER BY 1;

  first_name   |   last_name
---------------+---------------
 Alejandro     |McAlpine
 Anneke        |Preusig
 Anoosh        |Peyn
 Arumugam      |Ossenbruggen

Вышеупомянутый запрос возможен, потому что он эквивалентен:

SELECT first_name, last_name FROM emp WHERE last_name NOT LIKE '%a%' AND first_name LIKE 'A%' ORDER BY 1;

Однако, если подзапрос будет включать GROUP BY или HAVING, или окружающий SELECT будет сложнее, чем SELECT X FROM (SELECT ...) WHERE [simple_condition], это в настоящее время не поддерживается.

Использование FIRST и LAST в клаузе HAVING не поддерживается. То же самое относится к MIN и MAX, когда их целевой столбец имеет тип keyword, так как они внутренне переводятся в FIRST и LAST.

Использование типа данных TIME в качестве ключа группировки в настоящее время не поддерживается. Например:

SELECT count(*) FROM test GROUP BY CAST(date_created AS TIME);

С другой стороны, его можно использовать, если он обернут скалярной функцией, возвращающей другой тип данных, например:

SELECT count(*) FROM test GROUP BY MINUTE((CAST(date_created AS TIME));

Тип данных TIME также в настоящее время не поддерживается в функции группировки гистограмм. Например:

SELECT HISTOGRAM(CAST(birth_date AS TIME), INTERVAL '10' MINUTES) as h, COUNT(*) FROM t GROUP BY h

Так как поля geo_shape не имеют значений документов, эти поля не могут использоваться для фильтрации, группировки или сортировки.

По умолчанию, поля geo_points индексируются и имеют значения документов. Однако, только широта и долгота хранятся и индексируются с некоторой потерей точности по сравнению с исходными значениями (4.190951585769653E-8 для широты и 8.381903171539307E-8 для долготы). Компонент высоты принимается, но не хранится в значениях документов и не индексируется. Поэтому вызов функции ST_Z в фильтрации, группировке или сортировке вернёт null.

Elasticsearch SQL получает значения столбцов, используя параметр API поиска fields. Любые ограничения параметра fields также применяются к запросам Elasticsearch SQL. Например, если _source отключён для любого из возвращаемых полей или на уровне индекса, значения получить нельзя.

Выражение агрегации в клаузе PIVOT в настоящее время будет принимать только одну агрегацию. Поэтому невозможно получить несколько агрегаций для одного столбца, подвергнутого сворачиванию.

Значения, которые запрос PIVOT мог бы свёрнуть, должны быть предоставлены в запросе как список литералов; предоставление подзапроса для построения этого списка в настоящее время не поддерживается. Например, в этом запросе:

SELECT * FROM test_emp PIVOT (SUM(salary) FOR languages IN (1, 2))

значения languages должны быть перечислены явно: IN (1, 2). С другой стороны, этот пример не будет работать:

SELECT * FROM test_emp PIVOT (SUM(salary) FOR languages IN (SELECT languages FROM test_emp WHERE languages <=2 GROUP BY languages))