Соответствующее использование для SQLite

SQLite не непосредственно сопоставим с системами базы данных SQL клиент-сервер, такими как MySQL, Oracle, PostgreSQL или SQL Server, так как SQLite пытается решить иную проблему.

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

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

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

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

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

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

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

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

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

• Websites

  SQLiteSQLite работает отлично как ядро базы данных для большинства мелких и средних веб-сайтов (которых, должен сказать, большинство). Объем интернет-трафика, с которым может обращаться SQLite, зависит от того, как веб-сайт использует свою базу данных. Вообще говоря, любое место, которое получает меньше, чем 100K hits/day, должно хорошо работать с SQLite. Число в 100K хитов/день это осторожная оценка, не твердая верхняя граница. SQLite был продемонстрирован, чтобы работать с объемом трафика в 10 раз больше.

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

  См. также Hacker New discussion from 2022-12-13.

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

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

  То же самое может быть сделано с СУБД enterprise client/server. Преимущество SQLite состоит в том, что его легче установить и использовать, а получающаяся база данных это единственный файл, который может быть написан на карту памяти USB или послан по электронной почте коллеге.

• Кэш для данных предприятия

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Образование и обучение

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

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

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

Ситуации, где RDBMS клиент-сервер может работать лучше

• Приложения Client/Server

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

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

• Веб-сайты большого трафика

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

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

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

• Высокий параллелизм

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

Контрольный список для выбора правильного ядра базы данных

1. Данные отделены от применения сетью? → client/server

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

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

   Nota Bene: В этом правиле "приложение" означает код, который выпускает SQL-операторы. Если "приложение" это сервер приложений и если содержание проживает на той же самой физической машине как сервер приложений, то SQLite мог бы все еще быть соответствующим даже при том, что конечный пользователь далеко в сети.

2. Многие параллельные писатели? > выбирают клиент-сервер

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

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

3. Big data? → client/server

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

4. Что-то еще → выберите SQLite!

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