Правильное использование SQLite

SQLite напрямую не сравнимо с клиент-серверными СУБД, такими как MySQL, Oracle, PostgreSQL или SQL Server, так как SQLite пытается решить другую задачу.

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

SQLite не конкурирует с клиент-серверными базами данных. SQLite конкурирует с fopen().

1. Ситуации, где SQLite работает хорошо

• Встроенные устройства и интернет вещей

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

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

• Формат файла приложения

  SQLite часто используется в качестве формата файла на диске для настольных приложений, таких как системы управления версиями, инструменты финансового анализа, комплекты для каталогизации и редактирования медиа, пакеты САПР, программы ведения записей и так далее. Традиционные вызовы File/Open используют вызов sqlite3_open() для подключения к файлу базы данных. Обновления происходят автоматически по мере изменения содержимого приложения, поэтому опция меню File/Save становится излишней. Опция меню File/Save_As может быть реализована с помощью API резервного копирования.

  Этот подход имеет много преимуществ, включая улучшенную производительность, снижение затрат и сложности, а также повышение надёжности. Для получения дополнительной информации см. технические заметки "aff_short.html", "appfileformat.html" и "fasterthanfs.html". Этот случай тесно связан с приведенными ниже примерами использования формата передачи данных и контейнера данных.

• Веб-сайты

  SQLite прекрасно работает в качестве движка базы данных для большинства веб-сайтов с низким и средним трафиком (а это, можно сказать, большинство веб-сайтов). Объём веб-трафика, который может обрабатывать SQLite, зависит от того, насколько активно веб-сайт использует свою базу данных. Как правило, любой сайт, который получает меньше 100 000 просмотров в день, должен работать нормально с SQLite. Цифра 100 000 просмотров в день является оценочной, а не жёстким верхним пределом. Было продемонстрировано, что SQLite работает с трафиком в 10 раз больше.

  Веб-сайт SQLite (https://www.sqlite.org/) использует сам SQLite, разумеется, и на момент написания (2015 г.) он обрабатывает около 400 000-500 000 HTTP-запросов в день, примерно 15-20% из которых являются динамическими страницами, взаимодействующими с базой данных. Динамическое содержимое использует примерно 200 SQL-запросов на веб-страницу. Эта установка работает на одном виртуальном сервере, который разделяет физический сервер с 23 другими, и при этом средняя нагрузка большую часть времени остаётся ниже 0,1.

  См. также: обсуждение на Hacker News от 13.12.2022.

• Анализ данных

  Пользователи, знакомые с SQL, могут использовать командную оболочку sqlite3 (или различные сторонние программы доступа к SQLite) для анализа больших наборов данных. Сырые данные могут быть импортированы из файлов CSV, затем эти данные могут быть проанализированы для генерации множества сводных отчётов. Более сложный анализ может быть выполнен с помощью простых скриптов, написанных на Tcl или Python (оба из которых поставляются с встроенным SQLite) или на R или других языках с помощью легкодоступных адаптеров. Возможные применения включают анализ журналов веб-сайтов, анализ спортивных статистик, составление метрик программирования и анализ результатов экспериментов. Многие биоинформатики используют SQLite таким образом.

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

• Кэш для корпоративных данных

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

• База данных на стороне сервера

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

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

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

• Формат передачи данных

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

  База данных SQLite облегчает передачу данных между системами даже в том случае, если у конечных точек разные размеры слов и/или порядок байтов. Данные могут быть сложной смесью больших бинарных блоков, текста и небольших числовых или логических значений. Формат данных легко расширяется путём добавления новых таблиц и/или столбцов без нарушения работы устаревших получателей. Язык запросов SQL означает, что получателям не требуется анализировать всю передачу сразу, но они могут вместо этого запрашивать полученное содержимое по мере необходимости. Формат данных «прозрачен» в том смысле, что его легко декодировать для просмотра человеком с помощью различных универсальных открытых инструментов от разных поставщиков.

• Архив файлов и/или контейнер данных

  Идея SQLite Archive показывает, как SQLite может использоваться в качестве замены архивам ZIP или Tar. Архив файлов, хранящихся в SQLite, лишь немного больше, а в некоторых случаях даже меньше, чем эквивалентный архив ZIP. А архив SQLite имеет возможности инкрементного и атомарного обновления и возможность хранить гораздо более богатые метаданные.

  Fossil версии 2.5 и выше предлагает файлы архива SQLite в качестве формата для загрузки помимо традиционных tarball и ZIP архивов. Командная оболочка sqlite3.exe версии 3.22.0 и выше будет создавать, перечислять или распаковывать SQL-архив, используя команду .archive.

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

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

• Замена произвольных файлов на диске

  Многие программы используют fopen(), fread() и fwrite() для создания и управления файлами данных в собственных форматах. SQLite особенно хорошо подходит в качестве замены этих произвольных файлов данных. Вопреки интуиции, SQLite может быть быстрее файловой системы для чтения и записи содержимого на диск.

• Внутренние или временные базы данных

  Для программ, имеющих большое количество данных, которые необходимо сортировать и фильтровать различными способами, часто проще и быстрее загрузить данные в базу данных SQLite в оперативной памяти и использовать запросы с объединениями и условиями ORDER BY для извлечения данных в нужном формате и порядке, чем пытаться программно реализовать эти же операции. Использование SQL-базы данных внутри программы также даёт ей большую гибкость, так как можно добавлять новые столбцы и индексы без переписывания каждого запроса.

• Замена корпоративной базы данных во время демонстраций или тестирования

  Приложения-клиенты обычно используют универсальный интерфейс базы данных, который позволяет подключаться к различным СУБД. Разумно включить SQLite в список поддерживаемых баз данных и статически связать движок SQLite с клиентом. Таким образом, программа-клиент может использоваться автономно с файлом данных SQLite для тестирования или демонстраций.

• Обучение и подготовка

  Поскольку SQLite просто настроить и использовать (установка тривиальна: просто скопируйте исполняемый файл sqlite3 или sqlite3.exe на целевой компьютер и запустите его), SQLite хорошо подходит в качестве СУБД для обучения SQL. Студенты могут легко создавать любое количество баз данных и отправлять базы данных преподавателю для проверки или оценки. Для более продвинутых студентов, которые заинтересованы в изучении реализации СУБД, модульный и хорошо прокомментированный и документированный код SQLite может служить хорошей основой.

• Экспериментальные расширения языка SQL

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

2.Ситуации, где СУБД клиент-сервер может быть предпочтительнее

• Клиентские/серверные приложения

  Если много клиентских программ отправляют запросы SQL в одну базу данных по сети, то используйте клиентско-серверный движок базы данных вместо SQLite. SQLite может работать по сети через файловую систему, но из-за задержки, связанной с большинством сетевых файловых систем, производительность будет низкой. Кроме того, логика блокировки файлов в многих реализациях сетевых файловых систем (как в Unix, так и в Windows) имеет ошибки. Если блокировка файлов не работает правильно, две или более клиентов могут пытаться изменить одну и ту же часть одной и той же базы данных одновременно, что приведёт к её повреждению. Поскольку эта проблема вызвана ошибками в реализации файловой системы, SQLite ничего не может сделать, чтобы её предотвратить.

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

• Высокопосещаемые веб-сайты

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

• Очень большие наборы данных

  База данных SQLite ограничена размером в 281 терабайт (2⁴⁸ байт, 256 тибибайт). И даже если бы она могла обрабатывать более крупные базы данных, SQLite хранит всю базу данных в одном файле на диске, и многие файловые системы ограничивают максимальный размер файлов значением меньше этого. Поэтому, если вы рассматриваете базы данных такого масштаба, вам следует рассмотреть использование клиентско-серверного движка базы данных, который распределяет своё содержимое по нескольким файлам на диске, а возможно, и по нескольким томам.

• Высокая конкурентность

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

3. Список проверочных пунктов для выбора подходящего движка базы данных

1. Данные разделены от приложения сетью? → выбирайте клиентско-серверный

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

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

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

2. Много одновременных авторов? → выбирайте клиентско-серверный

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

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

3. Большие данные? → выбирайте клиентско-серверный

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

4. В противном случае → выбирайте SQLite!

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

Эта страница была изменена в последний раз 03 апреля 2024 г. 17:48:26 UTC