Допустимые ограничения реализации для SQLite

"Пределы" в контексте этой статьи означают размеры или количества, которые не могут быть превышены. Мы обеспокоены такими вещами, как максимальное количество байтов в BLOB или максимальное количество колонок в таблице.

SQLite был первоначально разработан с политикой предотвращения произвольных пределов. Конечно, у каждой программы, которая работает на машине с конечной памятью и дисковым пространством, есть пределы некоторого вида. Но в SQLite, те пределы не были четко определены. Политика состояла в том, что, если это уместится в памяти и вы могли бы посчитать его с 32-битным целым числом, тогда это должно работать.

К сожалению, политика без пределов, как показал опыт, создала проблемы. Поскольку верхние границы не были четко определены, они не были проверены, и ошибки часто находились. Поэтому у версий SQLite с 3.5.8 (2008-04-16) есть четко определенные пределы, и те пределы проверены как часть test suite.

Эта статья определяет пределы SQLite и то, как они могут быть настроены для определенных запросов. Настройки по умолчанию для пределов обычно довольно большие и достаточные для почти каждого применения. Некоторые запросы могут хотеть увеличить предел здесь или там, но мы ожидаем такие потребности редко. Чаще всего применение могло бы хотеть повторно собрать SQLite с очень низкими пределами, чтобы избежать избыточного использования ресурса в случае ошибки в высокоуровневых генераторах SQL-оператора или помешать нападавшим, которые вводят злонамеренные SQL-операторы.

Некоторые пределы могут быть изменены во время выполнения на основе для каждого подключения, используя sqlite3_limit() с одной из категорий предела , определенных для того интерфейса. Пределы во время выполнения разработаны для запросов, у которых есть многократные базы данных, некоторые из которых только для внутреннего пользования, и других, на которых могут влиять или управлять потенциально враждебные внешние агенты. Например, применение веб-браузера могло бы использовать внутреннюю базу данных, чтобы отследить исторические просмотры, но иметь одну или несколько отдельных базы данных, которые создают и управляют приложениями JavaScript, которые загружаются из Интернета. sqlite3_limit() позволяет внутренним базам данных, управляемым доверяемым кодом быть неограниченными, одновременно помещая серьезные ограничения на базы данных, созданные или управляемые внешним кодом, которому не доверяют, чтобы помочь предотвратить атаку "отказ в обслуживании".

1. Максимальная длина последовательности или BLOB

   Максимальное количество байтов в последовательности или BLOB в SQLite определяется макросом препроцессора SQLITE_MAX_LENGTH. Значение по умолчанию этого макроса 1,000,000,000. Можно поднять или понизить это значение во время компиляции, используя параметр командной строки:

   -DSQLITE_MAX_LENGTH=123456789

   Текущее внедрение поддерживает длину последовательности или BLOB только до 2³¹-1 или 2147483647. Некоторые встроенные функции, такие как hex(), могли бы потерпеть неудачу задолго до этого пункта. В чувствительных к безопасности запросах лучше не пытаться увеличить максимальную длину последовательности и blob. На самом деле вы могли бы их понизить к чему-то в диапазоне нескольких миллионов, если это возможно.

   Во время части обработки INSERT и SELECT полное содержание каждой строки в базе данных закодировано как единственный BLOB. Таким образом, параметр SQLITE_MAX_LENGTH также определяет максимальное количество байтов подряд.

   Максимальная длина последовательности или BLOB могут быть понижены во время выполнения, используя sqlite3_limit(db, SQLITE_LIMIT_LENGTH,size).

2. Максимальное количество колонок

   Параметр времени компиляции SQLITE_MAX_COLUMN используется, чтобы установить верхнюю границу на:

   • Количество колонок в таблице
   • Количество колонок в индексе
   • Количество колонок в обзоре
   • Количество условий в SET оператора UPDATE
   • Количество колонок в наборе результатов SELECT
   • Количество условий в GROUP BY или ORDER BY
   • Количество значений в INSERT

   Настройка по умолчанию для SQLITE_MAX_COLUMN = 2000. Можно изменить это во время компиляции на значение максимум 32767. С другой стороны, многие опытные проектировщики базы данных будут утверждать, что хорошо нормализованной базе данных никогда не будут нужно больше, чем 100 колонок на таблицу.

   В большинстве запросов количество колонок маленькое, несколько дюжин. Есть места в генераторе кода SQLite, которые используют алгоритмы, которые являются O(N²), где N это количество колонок. Таким образом, если вы пересматриваете SQLITE_MAX_COLUMN, чтобы быть действительно огромным, и вы производите SQL, который использует большое количество колонок, можно найти, что sqlite3_prepare_v2() работает медленно.

   Максимальное количество колонок может быть понижено во время выполнения, используя sqlite3_limit(db, SQLITE_LIMIT_COLUMN,size).

3. Максимальная длина SQL-оператора

   Максимальное количество байтов в тексте SQL-оператора ограничивается SQLITE_MAX_SQL_LENGTH который по умолчанию 1,000,000,000.

   Если SQL-оператор будет ограничен, чтобы быть миллион байтов в длину, то, очевидно, вы не будете в состоянии вставить многомиллионные строки байтов, включая их как литералы в операторах INSERT. Но вы не должны делать этого так или иначе. Используйте параметры для своих данных. Подготовьте короткие SQL-операторы:

   INSERT INTO tab1 VALUES(?,?,?);

   Тогда используйте sqlite3_bind_XXXX(), чтобы связать ваши большие строковые значения с SQL-оператором. Использование закрепления устраняет потребность экранировки символов кавычки в последовательности, снижая риск атак с использованием кода на SQL. Это также работает быстрее, так как большая последовательность не должна быть разобрана или скопирована.

   Максимальная длина SQL-оператора может быть понижена во время выполнения, используя sqlite3_limit(db, SQLITE_LIMIT_SQL_LENGTH,size).

4. Максимальное количество таблиц в соединении

   SQLite не поддерживает соединения, содержащие больше, чем 64 таблицы. Этот предел является результатом того, что генератор кода SQLite использует битовые массивы с одним битом объединяющую таблицу в оптимизаторе запросов.

   SQLite использует эффективный алгоритм планировщика запроса, и поэтому даже большое соединение может быть подготовлено быстро. Следовательно, нет никакого механизма, чтобы повысить или понизить ограничение на количество таблиц в соединении.

5. Максимальная глубина дерева выражений

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

   SQLITE_MAX_EXPR_DEPTH определяет максимальную глубину дерева выражений. Если это 0, то никакой предел не проведен в жизнь. У текущего внедрения есть значение по умолчанию 1000.

   Максимальная глубина дерева выражений может быть понижена во время выполнения, используя sqlite3_limit(db, SQLITE_LIMIT_EXPR_DEPTH,size), если SQLITE_MAX_EXPR_DEPTH первоначально положительный. Другими словами, максимальная глубина выражения может быть понижена во время выполнения, если уже есть ограничение времени компиляции на глубину выражения. Если SQLITE_MAX_EXPR_DEPTH установлен в 0 во время компиляции (если глубина выражений неограниченна), sqlite3_limit(db, SQLITE_LIMIT_EXPR_DEPTH,size) ничего не сделает.

6. Максимальное количество аргументов функции

   SQLITE_MAX_FUNCTION_ARG определяет максимальное количество параметров, которые могут быть переданы к функции SQL. Значение по умолчанию этого предела равняется 100. SQLite должен работать с функциями, у которых есть тысячи параметров. Однако мы подозреваем, что кто-либо, кто пытается вызвать функцию с больше, чем несколькими параметрами, действительно пытается найти проблемы безопасности в системах, которые используют SQLite, не делают полезную работу, по этой причине мы установили этот параметр относительно низко.

   Количество аргументов функции иногда хранится в signed символе. Таким образом, есть жесткая верхняя граница на SQLITE_MAX_FUNCTION_ARG 127.

   Максимальное количество аргументов в функции может быть понижено во время выполнения, используя sqlite3_limit(db, SQLITE_LIMIT_FUNCTION_ARG,size).

7. Максимальное количество условий в комплексном операторе SELECT

   Составной SELECT это два или больше оператора SELECT, связанные операторами UNION, UNION ALL, EXCEPT или INTERSECT. Мы называем каждый отдельный оператор SELECT в составном SELECT "термином".

   Генератор кода в процессах SQLite составляет операторы SELECT, используя рекурсивный алгоритм. Чтобы ограничить размер стека, мы поэтому ограничиваем количество условий в составном SELECT. Максимальное количество условий SQLITE_MAX_COMPOUND_SELECT по умолчанию 500. Мы думаем, что это щедрое распределение, на практике мы почти никогда не видим, что количество условий в комплексе превышает единицы.

   Максимальное количество составных условий SELECT может быть понижено во время выполнения, используя sqlite3_limit(db, SQLITE_LIMIT_COMPOUND_SELECT,size).

8. Максимальная длина образца LIKE или GLOB

   Алгоритм сопоставления с образцом использовал по умолчанию в LIKE и GLOB производительность O(N²) (N количество знаков в образце) для определенных патологических случаев. Чтобы избежать атак "отказ в обслуживании" от злодеев, которые в состоянии определить их собственный LIKE или GLOB, длина образца LIKE или GLOB ограничивается SQLITE_MAX_LIKE_PATTERN_LENGTH байт. Значение по умолчанию этого предела 50000. Современная рабочая станция может оценить даже патологический образец LIKE или GLOB в 50000 байтов относительно быстро. Проблема отказа в обслуживании играет роль только, когда длина образца входит в миллионы байтов. Тем не менее, так как самый полезный LIKE или GLOB это самое большее несколько дюжин байтов в длину, параноидальные разработчики приложений могут хотеть уменьшить этот параметр до чего-то в диапазоне нескольких сотен, если они знают, что внешние пользователи в состоянии произвести произвольные образцы.

   Максимальная длина LIKE или GLOB может быть понижена во время выполнения, используя sqlite3_limit(db, SQLITE_LIMIT_LIKE_PATTERN_LENGTH,size).

9. Максимальное количество параметров хоста в единственном SQL-операторе

   Параметры это заполнитель в SQL-операторе, который заполнен при использовании одного из sqlite3_bind_XXXX(). Многие SQL программисты знакомы с использованием вопросительного знака ("?") как параметра. SQLite также поддерживает названные параметры, снабженные предисловием ":", "$" или "@", или пронумерованные параметры в форме "?123".

   Каждому параметру в запросе SQLite назначают число. Числа обычно начинаются с 1 и увеличены на 1 с каждым новым параметром. Однако, когда использована форма "?123", число параметра это число, которое следует за вопросительным знаком.

   SQLite выделяет место, чтобы хранить все параметры от 1 до самого большого количества используемых параметров. Следовательно, SQL-оператор, который содержит параметр вроде ?1000000000, потребовал бы гигабайты для хранения. Это могло легко сокрушить ресурсы хост-машины. Чтобы предотвратить чрезмерные выделения памяти, максимальное значение числа параметра SQLITE_MAX_VARIABLE_NUMBER, который по умолчанию 999 для SQLite до 3.32.0 (2020-05-22) или 32766 для SQLite после 3.32.0.

   Максимальное число параметров может быть понижено во время выполнения, используя sqlite3_limit(db, SQLITE_LIMIT_VARIABLE_NUMBER,size).

10. Максимальная глубина рекурсии триггера

    SQLite ограничивает глубину рекурсии триггеров, чтобы предотвратить запрос, включающий рекурсивные триггеры, использующие неограниченный объем памяти.

    До SQLite version 3.6.18 (2009-09-11) триггеры не были рекурсивными и таким образом, этот предел был бессмыслен. Начиная с версии 3.6.18, рекурсивные триггеры были поддержаны, но должны были быть явно позволены, используя PRAGMA recursive_triggers. Начиная с version 3.7.0 (2009-09-11), рекурсивные триггеры позволены по умолчанию, но могут быть вручную отключены, используя PRAGMA recursive_triggers. SQLITE_MAX_TRIGGER_DEPTH значащий только, если рекурсивные триггеры позволены.

    Глубина рекурсии триггера по умолчанию максимум 1000.

11. Максимальное количество приложенных баз данных

    ATTACH это расширение SQLite, которое позволяет двум или больше базам данных быть связанными с тем же самым соединением с базой данных и работать, как будто они были единой базой данных. Количество одновременно приложенных баз данных ограничивается SQLITE_MAX_ATTACHED, который установлен в 10 по умолчанию. Максимальное число приложенных баз данных не может быть увеличено выше 125.

    Максимальное количество приложенных баз данных может быть понижено во время выполнения, используя sqlite3_limit(db, SQLITE_LIMIT_ATTACHED,size).

12. Максимальное количество страниц в файле базы данных

    SQLite в состоянии ограничить размер файла базы данных, чтобы препятствовать тому, чтобы файл базы данных стал слишком большим и потреблял слишком много дискового пространства. Параметр SQLITE_MAX_PAGE_COUNT, который обычно устанавливается в 1073741823, является максимальным количеством страниц, позволенных в файле единой базы данных. Попытка вставить новые данные, которые заставили бы файл базы данных расти больше, чем это, возвратит SQLITE_FULL.

    Самое большое урегулирование для SQLITE_MAX_PAGE_COUNT равняется 4294967294. Когда используется с максимальным размером страницы 65536, это дает максимальный размер базы данных SQLite приблизительно 281 терабайт.

    max_page_count PRAGMA может использоваться, чтобы повысить или понизить этот предел во время выполнения.

13. Максимальное количество строк в таблице

    Теоретическое максимальное количество строк в таблице 2⁶⁴ (18446744073709551616 или около 1.8e+19). Этот предел недостижим, так как максимальный размер базы данных в 281 терабайт будет достигнут сначала. База данных на 281 терабайт может содержать не больше, чем приблизительно 2e+13 строк, больше только при отсутствии индексов и если каждая строка содержит очень небольшие данные.

14. Максимальный размер базы данных

    Каждая база данных состоит из одной или более "страниц". В единой базе данных каждая страница имеет тот же самый размер, но у различных баз данных могут быть размеры страницы, которые являются степенями 2 между 512 и 65536, включительно. Максимальный размер файла базы данных составляет 4294967294 страницы. При максимальном размере страницы 65536 байтов это приводит к максимальному размеру базы данных приблизительно 1.4e+14 байт (281 ТБ).

    Эта конкретная верхняя граница не проверена, так как у разработчиков нет доступа к аппаратным средствам способным к достижению этого предела. Однако, тесты действительно проверяют, что SQLite ведет себя правильно и нормально когда база данных достигает максимального размера файла основной файловой системы (который является обычно намного меньше, чем максимальный теоретический размер базы данных) и когда база данных неспособна вырасти из-за истощения дискового пространства.

15. Максимальное количество таблиц в схеме

    Каждая таблица и индекс требуют по крайней мере одной страницы в файле базы данных. "Индекс" в предыдущем предложении означает индекс, созданный, явно используя запрос CREATE INDEX, или неявные индексы, созданные ограничениями PRIMARY KEY и UNIQUE. Так как максимальное количество страниц в файле базы данных 2147483646 (немногим более, чем 2 миллиарда), это также верхняя граница на количество таблиц и индексов в схеме.

    Каждый раз, когда база данных открыта, вся схема отсканирована и размечена, и дерево синтаксического анализа для схемы проводится в памяти. Это означает, что время запуска соединения с базой данных и начальное использование памяти пропорциональны размеру схемы.