Обзор SQLite Version 3

SQLite version 3.0 вводит важные изменения библиотеки, включая:

• Более компактный формат для файлов базы данных.
• Явная типизация и поддержка BLOB.
• Поддержка UTF-8 и UTF-16.
• Пользовательский текст, сопоставляющий последовательности.
• 64-bit ROWID.
• Улучшенный параллелизм.

Этот документ это краткое введение в изменения для SQLite 3.0 для пользователей, которые уже знакомы с версией 2.8 SQLite.

Обозначение изменений

SQLite version 2.8 продолжит поддерживаться с исправлениями ошибок для обозримого будущего. Чтобы позволить версии 2.8 SQLite и версии 3.0 SQLite мирно сосуществовать, названия файлов ключей и API в SQLite version 3.0 были изменены, чтобы включать символ "3". Например, включемый файл, используемый программами C, был изменен от "sqlite.h" на "sqlite3.h". И название программной оболочки, используемой, чтобы взаимодействовать с базами данных, было изменено от "sqlite.exe" на "sqlite3.exe". С этими изменениями возможно иметь SQLite 2.8 и SQLite 3.0, установленными на той же самой системе в то же время. И для той же самой программы C возможно связаться с SQLite 2.8 и SQLite 3.0 в то же время и пользоваться обеими библиотеками в то же время.

Новый формат файла

Формат, используемый файлами базы данных SQLite, был полностью пересмотрен. Старый формат 2.1 и новый формат 3.0 несовместимы друг с другом. Версия 2.8 SQLite не прочитает базу данных 3.0, и версия 3.0 SQLite не прочитает файл базы данных 2.8.

Чтобы преобразовать базу данных SQLite 2.8 в базу данных SQLite 3.0, имейте готовые оболочки командной строки для обеих версий 2.8 и 3.0. Затем выполните команду:

sqlite OLD.DB .dump | sqlite3 NEW.DB

Новый формат файла базы данных использует B+tree для таблиц. В B+tree все данные хранятся в листьях дерева, раньше они хранились в листьях и в промежуточных узлах отделения. Использование B+tree допускает лучшую масштабируемость и хранение более крупных полей данных без использования страниц переполнения. Традиционные B-деревья все еще используются для индексов.

Новый формат файла также поддерживает переменные размеры страниц между 512 и 65536 байтами. Размер страницы сохранен в заголовке файла, таким образом, та же самая библиотека может прочитать базы данных с различными размерами страниц в теории, хотя эта опция еще не была реализована на практике.

Новый формат файла опускает неиспользованные области от своих образов дисков. Например, индексы используют только ключевую часть записи B-дерева а не данные. Таким образом для индексов, область, которая делает запись длины данных, опущена. Целочисленные значения, такие как длина ключа и данных сохранены, используя кодирование переменной длины так, чтобы только один или два байта потребовались, чтобы хранить наиболее распространенные случаи, но до 64 битов информации могут быть закодированы в случае необходимости. Целочисленные данные и данные с плавающей запятой сохранены на диске в двоичном виде вместо того, чтобы быть преобразованными в ASCII как в версии 2.8 SQLite. Эти изменения, внесенные вместе, приводят к файлам базы данных, которые, как правило, являются на 25%-35% меньше, чем эквивалентные файлы в версии 2.8 SQLite.

Детали формата B-дерева низкого уровня, используемого в версии 3.0 SQLite, могут быть найдены в комментариях заголовка к файлу btreeInt.h и в описании формата файла.

Явная типизация и BLOB

SQLite version 2.8 будет иметь дело с данными в различных форматах внутренне, но при записи на диск или взаимодействуя через его API, SQLite 2.8 всегда преобразовывает данные в текст ASCII. SQLite 3.0, напротив, выставляет свои внутренние представления данных пользователю и хранит двоичное представление на диске в надлежащих случаях. Демонстрация представлений не-ASCII была добавлена, чтобы поддержать BLOB.

У SQLite version 2.8 была особенность, что любой тип данных мог быть сохранен в любом столбце таблицы независимо от заявленного типа той колонки. Эта особенность сохраняется в версии 3.0, хотя в немного измененной форме. Каждый столбец таблицы сохранит любой тип данных, хотя колонки обнаруживают сходство для формата данных, определенных их заявленным типом данных. Когда данные будут вставлены в колонку, та колонка предпримет попытку преобразовать формат данных в заявленный тип колонки. Все движки базы данных SQL делают это. Различие в том, что SQLite 3.0 будет все еще хранить данные, даже если преобразование формата не будет возможно.

Например, если вам объявят, что столбец таблицы имеет тип "INTEGER" и вы пытаетесь вставить последовательность, колонка будет смотреть на текстовую строку и видеть, похоже ли это на число. Если последовательность действительно похожа на число, она преобразовывается в число и в целое число, если число не имеет дробной части. Но если последовательность не правильно построенное число, она все еще сохранена как последовательность. Колонка с типом "TEXT" пытается преобразовать числа в представление ASCII-Text прежде, чем сохранить. BLOB сохранены в столбцах TEXT как BLOB, потому что вы не можете в общем случае конвертировать BLOB в текст.

В большинстве других движков данных SQL тип данных связан со столбцом таблицы, который содержит данные, контейнером данных. В SQLite 3.0 тип данных связан с самими данными, не с контейнером. Paul Graham в его книге ANSI Common Lisp называет эту собственность "Manifest Typing". У других писателей есть другие определения для термина "manifest typing", поэтому остерегайтесь беспорядка. Но любое имя, которое является моделью типа данных, поддержано SQLite 3.0.

Дополнительная информация о типах данных в версии 3.0 SQLite доступна отдельно.

Поддержка UTF-8 и UTF-16

Новый API для SQLite 3.0 содержит установленный порядок, который принимает текст как UTF-8 и как UTF-16 в родном порядке байтов хост-машины. Каждый файл базы данных управляет текстом как UTF-8, UTF-16BE (обратный порядок байтов) или как UTF-16LE (прямой порядок байтов). Внутренне и в дисковом файле, то же самое текстовое представление используется везде. Если текстовое представление, определенное файлом базы данных (в заголовке файла), не соответствует текстовому представлению, требуемому интерфейсным установленным порядком, то текст преобразовывается на лету. Постоянное преобразование текста от одного представления до другого может быть в вычислительном отношении дорогим, таким образом, предложено, чтобы программисты выбрали единственное представление и придерживались его всюду по их применению.

В текущем внедрении SQLite анализатор SQL работает только с текстом UTF-8. Таким образом, если вы будете поставлять текст UTF-16, то он будет преобразован. Это просто проблема внедрения и нет ничего, чтобы препятствовать тому, чтобы будущие версии SQLite разобрали UTF-16.

Когда выполняется создание новых определенных пользователями функций SQL и сопоставление последовательностей, каждая функция или сопоставление последовательности могут определить, работает ли это с UTF-8, UTF-16be или UTF-16le. Отдельные внедрения могут быть зарегистрированы для каждого кодирования. Если функция SQL или последовательность сопоставления требуются, но версия для кодирования текущего текста недоступна, то текст автоматически преобразовывается. Как прежде, это преобразование занимает время вычисления, таким образом, программистам рекомендуют выбрать единственное кодирование и придерживаться его, чтобы минимизировать объем ненужного манипулирования форматами.

SQLite не следит за текстом, который он получает и более, чем счастлив последовательностям текста процесса, которые не нормализованный или даже не правильно построенный UTF-8 или UTF-16. Таким образом программисты, которые хотят хранить данные ISO8859, могут это сделать, используя интерфейсы UTF-8. Пока никакие попытки не предприняты, чтобы использовать UTF-16 сопоставление последовательности или функции SQL, последовательность байтов текста не будет изменена ни в каком случае.

Определенные пользователями последовательности сопоставления

Последовательность сопоставления это просто определенный порядок текста. Когда SQLite 3.0 сортирует (или использует оператор сравнения вроде "<" или ">="), порядок сортировки сначала определяются по типу данных.

• NULL всегда первые.
• Числовые значения затем в числовом порядке.
• Текстовые значения поступают после численных данных.
• BLOB всегда последние.

Сопоставляющие последовательности используются для сравнения двух текстовых строк. Последовательность сопоставления не изменяет порядок NULL, чисел или BLOB, только текст.

Последовательность сопоставления осуществляется как функция, которая берет две сравниваемые последовательности в качестве входов и возвращает отрицательное значение, ноль или положительное значение, если первая последовательность меньше, равна или больше, чем вторая. SQLite 3.0 идет с единственной встроенной последовательностью сопоставления под названием "BINARY", которая осуществляется, используя memcmp() от стандартной библиотеки для C. BINARY работает хорошо на английском тексте. Для других языков или мест действия, могут быть предпочтены альтернативные последовательности сопоставления.

Решением того, какую последовательность использовать, управляет пункт COLLATE в SQL. COLLATE может произойти в определении таблицы, чтобы определить последовательность сопоставления по умолчанию столбца таблицы, в области индекса или в пункте ORDER BY оператора SELECT. Запланированные улучшения к SQLite должны включать стандартный CAST(), чтобы позволить задать последовательность сопоставления выражения.

64-bit ROWID

У каждой строки таблицы есть уникальный rowid. Если таблица определяет колонку с типом "INTEGER PRIMARY KEY", тогда эта колонка становится псевдонимом для rowid. Но с или без колонки INTEGER PRIMARY KEY, у каждой строки все еще есть rowid.

В SQLite version 3.0 rowid это 64-bit signed integer. Это расширение версии 2.8 SQLite, которая разрешила rowid только в 32 бита.

Чтобы минимизировать пространство памяти, 64 бита rowid сохранены как целое число переменной длины. Rowid между 0 и 127 используют только единственный байт. Rowid между 0 и 16383 используют всего 2 байта. До 2097152 используются три байта. И т.д. Отрицательные rowid позволены, но они всегда используют девять байтов хранения и таким образом, их использованию препятствуют. Когда rowid произведены автоматически SQLite, они всегда будут неотрицательными.

Улучшенный параллелизм

SQLite version 2.8 позволил работать многократным одновременным читателям или единственному писателю, но не обоим. Версия 3.0 SQLite позволяет одному процессу начинать писать базу данных, в то время как другие процессы продолжают читать. Писатель должен все еще получить монопольную блокировку на базе данных для краткого интервала, чтобы передать его изменения, но монопольная блокировка больше не требуется для всей операции записи. Более подробный отчет о поведении при блокировании версии 3.0 SQLite доступен отдельно.

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

Благодарность

SQLite version 3.0 сделана возможной частично разработчиками AOL, поддерживающими и охватывающими большое Open-Source Software.