SQLite в качестве формата файлов приложения

Резюме

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

1. Упрощение разработки приложений
2. Документы в единственном файле
3. Язык запросов высокого уровня
4. Доступное содержимое
5. Кроссплатформенность
6. Атомарные транзакции
7. Инкрементные и непрерывные обновления
8. Легко расширяемый
9. Производительность
10. Одновременное использование несколькими процессами
11. Поддержка нескольких языков программирования
12. Лучшие приложения

Каждый из этих пунктов будет описан более подробно ниже, после предварительного рассмотрения значения «формата файла приложения». См. также краткую версию этой белой книги.

Что такое формат файла приложения?

«Формат файла приложения» — это формат файла, используемый для сохранения состояния приложения на диске или для обмена информацией между программами. В настоящее время используется тысячи форматов файлов приложений. Вот несколько примеров:

• DOC — документы Word Perfect и Microsoft Office
• DWG — чертежи AutoCAD
• PDF — формат портативных документов от Adobe
• XLS — электронные таблицы Microsoft Excel
• GIT — хранилище исходного кода Git
• EPUB — формат электронных публикаций, используемый электронными книгами, не являющимися Kindle
• ODT — открытый формат документов, используемый OpenOffice и другими
• PPT — презентации Microsoft PowerPoint
• ODP — формат открытых презентаций, используемый OpenOffice и другими

Мы различаем «формат файла» и «формат приложения». Формат файла используется для хранения одного объекта. Например, файл GIF или JPEG хранит одно изображение, а файл XHTML хранит текст, поэтому они являются «форматами файлов», а не «форматами приложений». Файл EPUB, напротив, хранит и текст, и изображения (в виде содержащихся файлов XHTML и GIF/JPEG), и поэтому считается «форматом приложения». Эта статья посвящена «форматам приложений».

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

Большинство форматов приложений попадают в одну из трех категорий:

1. Полностью настраиваемые форматы. Настраиваемые форматы специально разработаны для одного приложения. DOC, DWG, PDF, XLS и PPT являются примерами настраиваемых форматов. Настраиваемые форматы обычно содержатся в одном файле для удобства переноса. Они обычно двоичные, хотя формат DWG является заметным исключением. Для чтения и записи настраиваемых форматов файлов требуется специализированный код приложения, и обычно они недоступны для общедоступных инструментов, таких как программы командной строки Unix и текстовые редакторы. Другими словами, настраиваемые форматы обычно являются «непрозрачными блоками». Чтобы получить доступ к содержимому настраиваемого формата файла приложения, требуется инструмент, специально разработанный для чтения и/или записи этого формата.

2. Форматы кучи файлов. Иногда состояние приложения хранится в виде иерархии файлов. Git является лучшим примером, хотя это явление часто встречается в разовых и специализированных приложениях. Формат кучи файлов по существу использует файловую систему как базу данных ключ/значение, сохраняя небольшие фрагменты информации в отдельных файлах. Это дает преимущество в большей доступности содержимого для общих утилит, таких как текстовые редакторы или «awk» или «grep». Но даже если многие файлы в формате кучи файлов легко читаемы, обычно некоторые файлы имеют собственный формат (например, «Packfiles» Git) и поэтому являются «непрозрачными блоками», которые нельзя прочитать или записать без специализированных инструментов. Перемещение кучи файлов из одного места или компьютера в другое также намного менее удобно, чем перемещение одного файла. И трудно сделать документ кучи файлов, например, вложением в электронное письмо. Наконец, формат кучи файлов нарушает «метафору документа»: нет одного файла, на который пользователь может указать, который является «документом».

3. Форматы обернутой кучи файлов. Некоторые приложения используют кучу файлов, которая затем инкапсулируется в некий контейнер одного файла, обычно архив ZIP. EPUB, ODT и ODP являются примерами этого подхода. Электронная книга EPUB представляет собой всего лишь архив ZIP, содержащий различные файлы XHTML для текста глав книги, GIF- и JPEG-изображения для графики и специализированный файл каталога, который указывает читателю электронных книг, как все файлы XML и изображения объединяются вместе. Документы OpenOffice (ODT и ODP) также являются архивами ZIP, содержащими XML и изображения, которые представляют их содержимое, а также файлы «каталога», которые показывают взаимосвязи между составными частями.

   Формат обернутой кучи файлов представляет собой компромисс между полным настраиваемым форматом файла и чистым форматом кучи файлов. Формат обернутой кучи файлов не является непрозрачным блоком в том же смысле, что и настраиваемый формат, поскольку к составляющим частям все еще можно получить доступ с помощью любого стандартного архиватора ZIP, но формат не так доступен, как чистый формат кучи файлов, так как все равно нужен архиватор ZIP, а в файловой иерархии нельзя обычно использовать инструменты командной строки, такие как «find», без предварительного распаковки. С другой стороны, формат обернутой кучи файлов сохраняет метафору документа, помещая все содержимое в один диск. Кроме того, из-за сжатия формат обернутой кучи файлов имеет тенденцию быть более компактным.

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

Цель этого документа — высказаться в пользу четвертой новой категории форматов файлов приложения: файл базы данных SQLite.

SQLite в качестве формата файла приложения

Любое состояние приложения, которое может быть записано в кучу файлов, также может быть записано в базу данных SQLite с простой схемой ключ/значение, такой как эта:

CREATE TABLE files(filename TEXT PRIMARY KEY, content BLOB);

Но база данных SQLite не ограничивается простой структурой ключ/значение, как база данных кучи файлов. База данных SQLite может иметь десятки или сотни или тысячи различных таблиц, с десятками или сотнями или тысячами полей в каждой таблице, каждый с разными типами данных и ограничениями и особым значением, все взаимосвязаны, соответствующим образом и автоматически индексируются для быстрого извлечения и все хранятся эффективно и компактно в одном файле. И вся эта структура кратко документирована для людей схемой SQL.

Другими словами, база данных SQLite может делать всё, что может делать формат кучи файлов или обернутой кучи файлов, плюс многое другое, и с большей ясностью. База данных SQLite — более универсальный контейнер, чем файловая система ключ/значение или архив ZIP. (Подробный пример см. в эссе о исследовании OpenOffice.)

В теории, возможности базы данных SQLite можно было бы достичь, используя настраиваемый формат файла. Но любой настраиваемый формат файла, который столь же выразителен, как реляционная база данных, вероятно, потребовал бы огромного описания дизайна и многих десятков или сотен тысяч строк кода для реализации. И конечный результат был бы «непрозрачным блоком», недоступным без специализированных инструментов.

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

1. Упрощенное создание приложений. Для чтения или записи файла приложения не требуется новый код. Достаточно связаться с библиотекой SQLite или включить единственный файл «sqlite3.c» в остальной код приложения на C, и SQLite позаботится обо всех операциях ввода-вывода файла приложения. Это может сократить размер кода приложения на тысячи строк, с соответствующей экономией затрат на разработку и обслуживание.

   SQLite — одна из самых используемых библиотек программного обеспечения в мире. Ежедневно используются десятки миллиардов файлов баз данных SQLite на смартфонах, гаджетах и в настольных приложениях. SQLite тщательно протестирован и зарекомендовал себя как надёжный инструмент. Это не компонент, требующий значительной настройки или отладки, что позволяет разработчикам сосредоточиться на логике приложения.

2. Файлы-документы. База данных SQLite содержится в одном файле, который легко копировать, перемещать или подключать. Сохраняется метафора «документа».

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

3. Язык запросов высокого уровня. SQLite — это полноценный реляционный движок базы данных, что означает, что приложение может получать доступ к содержимому с помощью запросов высокого уровня. Разработчикам приложений не нужно тратить время на то, «как» извлечь необходимую информацию из документа. Разработчики пишут запросы SQL, которые выражают «какую» информацию они хотят, а движок базы данных определяет, как лучше извлечь это содержимое. Это помогает разработчикам работать «свободно» и оставаться сосредоточенными на решении проблемы пользователя, а не тратить время на «мелкие» детали форматирования файлов.

   Формат «кучи файлов» можно рассматривать как базу данных «ключ-значение». База данных «ключ-значение» лучше, чем вообще никакой базы данных. Но без транзакций, индексов, языка запросов высокого уровня или надлежащей схемы использование базы данных «ключ-значение» гораздо сложнее и подвержено ошибкам, чем реляционной базы данных.

4. Доступ к содержимому. К информации, хранящейся в файле базы данных SQLite, можно получить доступ с помощью общедоступных инструментов командной строки с открытым исходным кодом — инструментов, которые устанавливаются по умолчанию в системах Mac и Linux и доступны в виде автономного файла EXE в Windows. В отличие от пользовательских форматов файлов, для чтения или записи содержимого в базе данных SQLite не требуются специализированные программы. Файл базы данных SQLite не является непрозрачным блоком. Действительно, инструменты командной строки, такие как текстовые редакторы или «grep» или «awk», не подходят для базы данных SQLite, но язык запросов SQL является гораздо более мощным и удобным способом просмотра содержимого, поэтому невозможность использования «grep» и «awk» и аналогичных инструментов не считается потерей.

   База данных SQLite — это хорошо определённый и хорошо документированный формат файла, широко используемый миллионами приложений и обратной совместимости с момента создания в 2004 году, и который обещает сохранять совместимость в течение десятилетий. Долговечность файлов баз данных SQLite особенно важна для специализированных приложений, так как она позволяет получать доступ к содержимому документа в будущем, когда все следы исходного приложения исчезнут. Данные живут дольше, чем код. Базы данных SQLite рекомендуются Библиотекой Конгресса США в качестве формата хранения для долгосрочного сохранения цифрового контента.

5. Многоплатформенность. Файлы баз данных SQLite совместимы между 32-разрядными и 64-разрядными машинами, между системами с порядком байтов big-endian и little-endian и между различными версиями Windows и Unix-подобных операционных систем. Приложение, использующее формат файла приложения SQLite, может хранить двоичные числовые данные, не беспокоясь о порядке байтов целых чисел или чисел с плавающей запятой. Текстовое содержимое может быть прочитано или записано как UTF-8, UTF-16LE или UTF-16BE, и SQLite автоматически выполнит необходимые преобразования в режиме реального времени.

6. Атомарные транзакции. Записи в базе данных SQLite атомарны. Они либо происходят полностью, либо вообще не происходят, даже при сбоях системы или отключении питания. Таким образом, нет опасности повреждения документа только потому, что питание выключилось в тот момент, когда изменение записывалось на диск.

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

7. Инкрементные и непрерывные обновления. При записи в файл базы данных SQLite на диск записываются только те части файла, которые фактически изменились. Это ускоряет запись и снижает износ SSD. Это огромное преимущество перед пользовательскими и обернутыми форматами «кучи файлов», которые обычно требуют переписывания всего документа для изменения одного байта. Форматы «чистой кучи файлов» также могут выполнять инкрементные обновления в определенной степени, хотя размер записей обычно больше в формате «кучи файлов» (один файл), чем в SQLite (одна страница).

   SQLite также поддерживает непрерывное обновление. Вместо того, чтобы собирать изменения в памяти и записывать их на диск только при действии «Файл/Сохранить», изменения могут записываться обратно на диск по мере их возникновения. Это предотвращает потерю работы при сбоях системы или отключении питания. Автоматический стек отмены/повтор, управляемый триггерами, может храниться в базе данных на диске, что означает, что отмена/повтор может происходить между сеансами.

8. Легкая расширяемость. По мере роста приложения новые функции могут быть добавлены в формат файла приложения SQLite путем добавления новых таблиц в схему или добавления новых столбцов в существующие таблицы. Добавление столбцов или таблиц не изменяет смысл предыдущих запросов, поэтому, при надлежащем уходе за сохранением смысла устаревших столбцов и таблиц, поддерживается обратная совместимость.

   Конечно, расширить пользовательские или форматы «кучи файлов» тоже возможно, но это часто намного сложнее. Если добавляются индексы, весь код приложения, изменяющий соответствующие таблицы, необходимо найти и изменить, чтобы поддерживать актуальность этих индексов. Если добавляются столбцы, весь код приложения, который обращается к соответствующей таблице, необходимо найти и изменить, чтобы учесть новые столбцы.

9. Производительность. Во многих случаях формат файла приложения SQLite будет быстрее, чем формат «кучи файлов» или пользовательский формат. Помимо того, что он быстрее при чтении и записи, SQLite часто может значительно улучшить время запуска, потому что вместо того, чтобы читать и анализировать весь документ в память, приложение может выполнять запросы для извлечения только информации, необходимой для начального экрана. По мере работы приложения ему нужно загружать только столько материала, сколько нужно для отображения следующего экрана, и он может отбрасывать информацию с предыдущих экранов, которая больше не используется. Это помогает контролировать размер занимаемой памяти приложения.

   Формат «кучи файлов» можно читать инкрементально, как и SQLite. Но многие разработчики удивлены, узнав, что SQLite может читать и записывать меньшие BLOB (размером менее примерно 100 КБ) из своей базы данных быстрее, чем эти же BLOB могут быть прочитаны или записаны как отдельные файлы из файловой системы. (См. 35% быстрее, чем файловая система и Внутренние и внешние BLOB для получения дополнительной информации.) Однако, использование реляционного движка базы данных сопряжено с издержками, но не следует полагать, что прямые операции ввода-вывода файлов быстрее операций ввода-вывода базы данных SQLite, поскольку часто это не так.

   В любом случае, если в приложении SQLite возникают проблемы с производительностью, их часто можно решить, добавив одну или две команды CREATE INDEX в схему или, возможно, выполнив ANALYZE один раз, не затрагивая ни одной строки кода приложения. Но если проблема с производительностью возникнет в пользовательском или формате «кучи файлов», исправление часто потребует значительных изменений в коде приложения для добавления и поддержки новых индексов или извлечения информации с помощью других алгоритмов.

10. Одновременное использование несколькими процессами. SQLite автоматически координирует одновременный доступ к одному и тому же документу из нескольких потоков и/или процессов. Два или более приложения могут подключаться и читать один и тот же документ одновременно. Записи сериализуются, но поскольку записи обычно занимают лишь миллисекунды, приложения просто по очереди выполняют запись. SQLite автоматически гарантирует, что низкоуровневый формат документа не поврежден. Для достижения того же с пользовательским или форматом «кучи файлов», наоборот, требуется значительная поддержка в приложении. И логика приложения, необходимая для поддержки одновременного доступа, является известным источником ошибок.

11. Поддержка нескольких языков программирования. Хотя сам SQLite написан на ANSI-C, существуют интерфейсы практически для всех остальных языков программирования: C++, C#, Objective-C, Java, Tcl, Perl, Python, Ruby, Erlang, JavaScript и так далее. Таким образом, программисты могут разрабатывать на том языке, с которым они наиболее знакомы и который лучше всего отвечает потребностям проекта.

    Формат файла приложения SQLite — это отличный выбор в случаях, когда имеется набор или «федерация» отдельных программ, часто написанных на разных языках и разными командами разработчиков. Это часто встречается в исследовательских или лабораторных средах, где одна команда отвечает за сбор данных, а другие команды — за различные этапы анализа. Каждая команда может использовать любое оборудование, операционную систему, язык программирования и методологию разработки, которые им удобны, и если все программы используют базу данных SQLite с общей схемой, они могут взаимодействовать друг с другом.

1. Лучшие приложения. Если формат файла приложения — база данных SQLite, полное описание этого формата состоит из схемы базы данных, возможно, с несколькими дополнительными словами о том, что представляет собой каждая таблица и столбец. Описание пользовательского формата файла, с другой стороны, обычно занимает сотни страниц. Формат «куча файлов», хотя и намного проще и легче для описания, чем полностью пользовательский формат, всё же, как правило, значительно больше и сложнее, чем дамп схемы SQL, так как необходимо описать имена и формат отдельных файлов.

   Это не тривиальный момент. Чётко определённый, лаконичный и простой в понимании формат файла является важнейшей частью любого проектирования приложений. Фред Брукс в своей бестселлеровской книге по компьютерным наукам «Мифический человек-месяц» говорит:

   Представление — сущность программирования на компьютере.
   …
   Покажите мне ваши блок-схемы и скройте ваши таблицы, и я буду продолжать оставаться в недоумении. Покажите мне ваши таблицы, и мне, как правило, не понадобятся ваши блок-схемы; они будут очевидны.

   Роб Пайк в своих «Правилах программирования» выражает ту же идею так:

   Данные доминируют. Если вы выбрали правильные структуры данных и хорошо их организовали, алгоритмы почти всегда будут очевидны. Структуры данных, а не алгоритмы, являются центральными в программировании.

   Линус Торвальдс использовал другие слова, чтобы сказать практически то же самое на почтовой рассылке Git от 2006-06-27:

   Плохие программисты беспокоятся о коде. Хорошие программисты беспокоятся об структурах данных и их взаимосвязях.

   Суть в том, что схема базы данных SQL почти всегда обеспечивает гораздо лучшую работу по определению и организации таблиц, структур данных и их взаимосвязей. И чёткое, лаконичное и хорошо определённое представление почти всегда приводит к приложению, которое работает лучше, имеет меньше проблем и проще разрабатывать и поддерживать.

Заключение

SQLite не является идеальным форматом файла приложения для каждой ситуации. Но во многих случаях SQLite является гораздо лучшим выбором, чем пользовательский формат файла, формат «куча файлов» или обернутый формат «куча файлов». SQLite — это высокоуровневый, стабильный, надёжный, кроссплатформенный, широко используемый, расширяемый, производительный, доступный, многопоточный формат файла. Он заслуживает вашего внимания в качестве стандартного формата файла при проектировании вашего следующего приложения.

Эта страница была в последний раз изменена 08 января 2022 г. в 05:02:57 UTC