Лёгкие СУБД¶

Лёгкие СУБД (англ. lightweight database management systems) — это класс систем управления базами данных, отличающихся минимальными требованиями к вычислительным ресурсам (оперативной памяти, процессорному времени, дисковому пространству) и предназначенных для работы на устройствах с ограниченной производительностью, во встраиваемых системах, мобильных приложениях, а также для простых однопользовательских или маломасштабных проектов. В отличие от тяжеловесных серверных СУБД (например, Oracle Database, Microsoft SQL Server, PostgreSQL), лёгкие СУБД часто не требуют отдельного серверного процесса, управляются библиотекой, встраиваемой непосредственно в приложение, и имеют упрощённую архитектуру.

¶История

Развитие лёгких СУБД началось в конце 1980-х — начале 1990-х годов, когда рост популярности персональных компьютеров и появление портативных устройств (карманных компьютеров, смартфонов) потребовали решений для локального хранения данных без постоянного подключения к централизованным серверам. Одним из первых широко известных представителей стала СУБД dBase (1980-е), которая, хотя и не была полностью лёгкой по современным меркам, задала тренд на встраиваемость и простоту.

Настоящий прорыв произошёл в 2000 году с выходом SQLite — самой популярной на сегодняшний день лёгкой реляционной СУБД. SQLite была создана Ричардом Хиппом (D. Richard Hipp) как встраиваемая библиотека, работающая без отдельного сервера. Её исходный код помещается в один файл (амальгамация), а база данных хранится в единственном файле на диске. К 2020-м годам SQLite используется в миллиардах устройств: от смартфонов на Android и iOS до браузеров (Firefox, Chrome), встроенных систем автомобилей, бытовой техники и промышленного оборудования.

Параллельно развивались и другие направления. В 2009 году появилась Berkeley DB (изначально разрабатывалась в Калифорнийском университете в Беркли, затем приобретена Oracle) — нереляционная (ключ-значение) СУБД, ориентированная на высокую производительность и встраиваемость. В 2010-х годах с ростом популярности NoSQL-решений возникли лёгкие документоориентированные СУБД, такие как LevelDB (Google, 2011) и RocksDB (Facebook, 2013), оптимизированные для работы с SSD и флэш-памятью.

В России лёгкие СУБД активно применяются в разработке встраиваемых систем, автоматизации промышленности и мобильных приложениях. Например, SQLite используется в операционной системе Аврора (российская мобильная ОС) для хранения настроек и пользовательских данных.

¶Классификация

Лёгкие СУБД можно классифицировать по нескольким признакам.

¶По модели данных

• Реляционные (SQL) — поддерживают язык SQL, таблицы, строки и столбцы. Примеры: SQLite, H2 (Java), Firebird Embedded.
• Ключ-значение (key-value) — хранят данные как пары «ключ — значение». Примеры: Berkeley DB, LevelDB, RocksDB.
• Документоориентированные — хранят данные в виде документов (обычно JSON или BSON). Примеры: LiteDB (.NET), UnQLite.
• Графовые — оптимизированы для хранения и обработки связей между объектами. Примеры: Neo4j Embedded (ограниченная версия).

¶По способу развёртывания

• Встраиваемые (embedded) — библиотека, которая включается непосредственно в приложение. Не требуют установки отдельного сервера. Примеры: SQLite, LevelDB, Berkeley DB.
• Локальные (desktop) — могут работать как отдельное приложение, но не требуют сетевого доступа. Примеры: Microsoft Access (лёгкая версия), LibreOffice Base.

¶По типу хранения

• Файловые — вся база данных хранится в одном или нескольких файлах на диске. Примеры: SQLite (один файл), Berkeley DB (несколько файлов).
• В памяти (in-memory) — данные хранятся исключительно в оперативной памяти, что обеспечивает максимальную скорость, но данные теряются при выключении. Примеры: Redis (хотя он не является чисто лёгким, но часто используется в лёгких конфигурациях), SQLite в режиме :memory:.

¶Характеристики

Лёгкие СУБД обладают рядом общих характеристик, отличающих их от полноценных серверных решений:

• Минимальное потребление ресурсов: типичный объём оперативной памяти для работы SQLite составляет 250 КБ — 1 МБ, размер библиотеки — около 600 КБ. Для сравнения, минимальные требования PostgreSQL — не менее 10 МБ ОЗУ и 50 МБ дискового пространства.
• Отсутствие отдельного серверного процесса: библиотека работает в адресном пространстве приложения, что исключает накладные расходы на межпроцессное взаимодействие (IPC) и сетевые задержки.
• Упрощённая модель параллельного доступа: большинство лёгких СУБД (например, SQLite) поддерживают только один пишущий процесс или поток в любой момент времени. Это ограничение делает их непригодными для высоконагруженных многопользовательских систем, но оптимально для однопользовательских сценариев.
• Портативность: код написан на C/C++ и может быть скомпилирован практически для любой платформы — от микроконтроллеров до мейнфреймов.
• Надёжность: многие лёгкие СУБД (SQLite, Berkeley DB) проходят строгие тесты на отказоустойчивость (например, тестирование при внезапном отключении питания) и соответствуют стандарту ACID (атомарность, согласованность, изолированность, долговечность).

¶Применение

Лёгкие СУБД находят применение в широком спектре областей:

• Мобильные приложения: Android и iOS используют SQLite как стандартное хранилище для большинства приложений (контакты, сообщения, настройки).
• Встраиваемые системы: автомобильные мультимедийные системы, промышленные контроллеры, медицинские приборы, «умные» бытовые приборы (холодильники, стиральные машины).
• Браузеры и веб-технологии: Firefox хранит закладки, историю и пароли в SQLite; WebSQL (устаревший стандарт) также базировался на SQLite.
• Научные и исследовательские проекты: для хранения небольших объёмов экспериментальных данных на портативных устройствах.
• Прототипирование и обучение: лёгкие СУБД часто используются в учебных курсах по базам данных из-за простоты установки и настройки.

¶Примеры лёгких СУБД

¶SQLite

Наиболее распространённая встраиваемая реляционная СУБД. Поддерживает большинство стандарта SQL-92, транзакции ACID, индексы, триггеры, представления. Ограничения: отсутствие полноценной поддержки хранимых процедур, ограниченная конкурентность записи. Лицензия: общественное достояние (public domain).

¶Berkeley DB

Нереляционная СУБД (ключ-значение), разработанная Oracle. Отличается высокой производительностью при операциях вставки и чтения. Поддерживает транзакции, репликацию, шифрование. Используется в таких продуктах, как OpenLDAP, Subversion, Bitcoin Core.

¶LevelDB

Разработана Google как библиотека для хранения пар ключ-значение с упорядоченными ключами. Оптимизирована для последовательной записи на SSD. Используется в браузере Chrome (IndexedDB) и блокчейн-проектах (например, Ethereum).

¶RocksDB

Форк LevelDB, созданный Facebook (продукт Meta, признанной экстремистской и запрещённой в РФ). Добавлена поддержка многопоточности, сжатия, различных стратегий слияния файлов. Применяется в высоконагруженных системах, таких как Apache Kafka, MySQL (как альтернативный движок MyRocks), а также в распределённых базах данных (например, TiKV).

¶H2

Реляционная СУБД, написанная на Java. Поддерживает режимы как встраиваемой (embedded), так и клиент-серверной работы. Часто используется для тестирования и разработки Java-приложений, а также как встроенная база данных в таких продуктах, как IntelliJ IDEA.

¶Firebird Embedded

Встраиваемая версия СУБД Firebird. Поддерживает полноценный SQL, хранимые процедуры, триггеры. Отличается от SQLite поддержкой многопользовательского доступа и более сложной архитектурой.

¶Критика и ограничения

Несмотря на широкое распространение, лёгкие СУБД имеют ряд недостатков:

• Ограниченная масштабируемость: невозможность обработки большого количества параллельных запросов на запись. Например, SQLite блокирует всю базу данных на время записи.
• Отсутствие или упрощённая система безопасности: встроенные СУБД обычно не поддерживают разграничение прав доступа на уровне пользователей (аутентификация и авторизация возлагаются на приложение).
• Ограниченные возможности администрирования: нет инструментов для мониторинга производительности, резервного копирования «на лету» (без остановки приложения), репликации в реальном времени.
• Риск повреждения данных: при некорректном завершении работы приложения (например, сбой питания) файл базы данных может быть повреждён, хотя современные версии SQLite и Berkeley DB минимизируют этот риск за счёт журналирования.

¶Источники

• SQLite Documentation. SQLite Consortium. 2023.
• Oracle Berkeley DB Programmer's Reference Guide. Oracle Corporation. 2021.
• Dean, J., Ghemawat, S. LevelDB: A Fast Persistent Key-Value Store. Google Inc. 2011.
• Dong, S., et al. RocksDB: Evolution of a Key-Value Store for Flash Storage. Facebook Inc. 2017.
• H2 Database Engine Documentation. H2 Group. 2024.
• Firebird Embedded Server Guide. Firebird Foundation. 2022.