SQLite в мобильной разработке: что это такое и как работает

Что такое SQLite?

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

SQLite поддерживает большую часть стандарта SQL:1999, включая JOIN, подзапросы, триггеры, представления, индексы и оконные функции. Ограничения касаются ALTER TABLE (ограниченная поддержка) и полноценных RIGHT/FULL OUTER JOIN. Тем не менее для мобильных приложений функциональности SQLite достаточно в 99% случаев локального хранения.

По данным опроса разработчиков от Stack Overflow (2025), SQLite является самой популярной базой данных для встраиваемых решений и занимает третье место по популярности среди всех СУБД после MySQL и PostgreSQL. В мобильной разработке SQLite используется в каждом приложении — напрямую или через обёртки.

Ключевые характеристики SQLite

Zero-configuration — SQLite не требует установки, настройки прав, создания пользователей или запуска сервиса. Библиотека подключается к проекту, и база данных создаётся вызовом одной функции. Это радикально упрощает развёртывание по сравнению с клиент-серверными СУБД, где требуется установка сервера, настройка портов и конфигурация пользователей.

Файл базы данных SQLite — обычный кросс-платформенный файл, который можно скопировать, проанализировать, отправить по сети или восстановить из резервной копии. Формат файла стабилен на уровне API: файлы SQLite 3, созданные в 2004 году, открываются текущей версией библиотеки, что гарантирует долговременную совместимость данных.

Как устроена SQLite: архитектура и хранение

Архитектура SQLite состоит из восьми виртуальных машин: Tokenizer, Parser, Code Generator, VM, B-Tree, Pager, OS Interface и Utilities. SQL-запрос проходит через Tokenizer (разбивка на токены), Parser (построение AST), Code Generator (преобразование в байт-код) и выполняется на виртуальной машине, которая читает страницы данных через B-Tree и Pager.

SQLite использует B-Tree для хранения таблиц и индексов. Каждая таблица хранится как отдельное B-Tree, где листовые узлы содержат строки данных. Индексы также хранятся как B-Tree, но с ключами в листьях. Pager управляет загрузкой страниц (по умолчанию 4096 байт) из файла в память, обеспечивая ACID-транзакции через журнал или WAL.

Режимы журналирования

WAL (Write-Ahead Logging) — рекомендуемый режим для мобильных приложений. Изменения сначала записываются в отдельный WAL-файл, а затем периодически переносятся в основную базу. WAL позволяет одновременно читать из БД (старые данные) и писать в неё (через WAL), что повышает производительность многопоточных приложений. Стандартный журнал (rollback journal) блокирует чтение при записи.

Переключение между режимами выполняется одним SQL-запросом: PRAGMA journal_mode=WAL. Для мобильных приложений с фоновой синхронизацией и UI-потоком, одновременно читающим данные, WAL обеспечивает лучшую производительность и отсутствие блокировок интерфейса.

SQLite vs другие БД в мобильной разработке

SQLite — не единственная опция для локального хранения данных, но наиболее универсальная. Realm предлагает более высокую скорость прямого доступа к объектам в памяти, но использует собственный NoSQL-формат и имеет больший размер библиотеки. Core Data на iOS — это ORM-слой поверх SQLite, который добавляет управление графом объектов и отмену операций.

Для большинства приложений SQLite остаётся оптимальным выбором благодаря предсказуемой производительности, нулевому vendor lock-in и проверенной временем стабильности. Realm и Core Data оправданы в проектах со сложными объектными графами, реактивными запросами или требованием к синхронизации между устройствами.

Выбор между SQLite, Realm и Core Data зависит от платформы, требований к объектной модели и стратегии синхронизации. Для кросс-платформенных проектов (KMP, Flutter) SQLite остаётся единственным универсальным выбором, работающим на всех целевых платформах без изменений в модели данных.

SQLite на Android: Room и SQLiteOpenHelper

Room — библиотека из Android Jetpack, предоставляющая ORM-слой поверх SQLite. Room автоматически генерирует SQL-запросы из аннотированных DAO-интерфейсов, проверяет корректность запросов на этапе компиляции и поддерживает миграции базы данных при изменении схемы. Room — рекомендуемый способ работы с SQLite на Android.

SQLiteOpenHelper — низкоуровневый API для прямого управления SQLite без ORM. Класс управляет созданием, открытием и обновлением базы данных. SQLiteOpenHelper подходит для проектов с простыми SQL-запросами или когда нужен полный контроль над SQL-логикой без абстракции Room.

Пример сущности и DAO для Room

Сущность в Room аннотируется @Entity, а DAO — @Dao. Room транслирует аннотированные методы в SQL-запросы: @Insert генерирует INSERT, @Query — SELECT с указанным SQL. Миграции добавляются через Migration с указанием старой и новой версии схемы. Room проверяет SQL на этапе компиляции, что исключает синтаксические ошибки в production.

@Entity
data class User(
    @PrimaryKey val id: Long,
    val name: String,
    @ColumnInfo(name = "created_at")
    val createdAt: Long
)

@Dao
interface UserDao {
    @Query("SELECT * FROM user ORDER BY name ASC")
    suspend fun getAllUsers(): List<User>

    @Insert(onConflict = OnConflictStrategy.REPLACE)
    suspend fun insertUser(user: User)

    @Query("DELETE FROM user WHERE id = :id")
    suspend fun deleteUser(id: Long)
}

Room автоматически генерирует имплементацию UserDao_Impl, которая содержит runtime-запросы к SQLite через внутренний RoomDatabase. Благодаря корутинам (suspend) DAO-методы выполняются асинхронно на фоновом потоке, не блокируя UI. Flow-возвращаемые типы в @Query автоматически обновляют результат при изменении таблицы.

SQLite на iOS: FMDB и GRDB

FMDB — Objective-C обёртка над SQLite C API, исторически первая популярная библиотека для iOS. Предоставляет объекты FMDatabase и FMResultSet для выполнения запросов и получения результатов. FMDB проста и минималистична, но не поддерживает Swift-специфичные конструкции — опционалы, Codable, async/await.

GRDB — современная Swift-библиотека для работы с SQLite. Предоставляет type-safe API, поддержку Codable, Combine Publishers, async/await, миграции и наблюдение за изменениями в реальном времени. GRDB предпочтительна для новых проектов на Swift благодаря полной интеграции со Swift Concurrency и лучшей читаемости кода.

Пример GRDB на Swift

GRDB определяет таблицы через Record-классы, соответствующие протоколу FetchableRecord и TableRecord. Запросы пишутся на Swift с type-safe синтаксисом, а не сырым SQL. GRDB также поддерживает DatabaseMigrator для версионирования схемы и миграций между версиями приложения.

struct User: Codable, FetchableRecord, TableRecord {
    var id: Int64
    var name: String
    var createdAt: Date
}

let dbPool = try DatabasePool(path: dbPath)
var migrator = DatabaseMigrator()
migrator.registerMigration("v1") { db in
    try db.create(table: "user") { t in
        t.autoIncrementedPrimaryKey("id")
        t.column("name", .text).notNull()
        t.column("createdAt", .datetime).notNull()
    }
}

let users = try await dbPool.read { db in
    try User.order(Column("name")).fetchAll(db)
}

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

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

Индексы — самый эффективный способ ускорения SQLite-запросов. Индекс создаётся на колонках, участвующих в WHERE, JOIN и ORDER BY. Для таблицы с 100000 записей поиск по индексированной колонке выполняется за миллисекунды вместо секунд. Однако индексы замедляют INSERT и UPDATE, поэтому их количество должно быть сбалансировано с частотой записи.

Пакетная вставка (batch insert) в рамках одной транзакции радикально ускоряет массовую загрузку данных. Вставка 1000 записей по одной даёт накладные расходы ~1 секунду. Те же 1000 записей в одной транзакции — ~5-10 миллисекунд. Разница объясняется тем, каждая отдельная INSERT создаёт новую транзакцию с синхронной записью на диск.

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

PRAGMA — SQLite-команды для настройки поведения библиотеки. Ключевые оптимизационные прагмы: PRAGMA synchronous=NORMAL (снижает частоту fsync), PRAGMA cache_size=-8000 (выделяет 8 МБ кэша), PRAGMA temp_store=MEMORY (временные таблицы в памяти). Для мобильных приложений с большими объёмами данных комбинация этих прагм ускоряет запросы в 2-3 раза.

Ещё одна важная оптимизация — предварительная компиляция SQL-запросов (prepared statements). Если запрос выполняется многократно (например, вставка 10000 строк), компиляция SQL один раз с последующим использованием statement снижает загрузку CPU на 30-50%. Room и GRDB автоматически кешируют prepared statements, но при прямом использовании SQLite C API компиляцию нужно выполнять вручную.

class UserRepository(private val db: RoomDatabase) {

    suspend fun insertBatch(users: List<User>) {
        db.withTransaction {
            users.chunked(500).forEach { batch ->
                batch.forEach { user ->
                    insertUser(user)
                }
            }
        }
    }
}

Пакетная вставка с withTransaction гарантирует, что все INSERT выполняются в рамках одной транзакции. Разбивка на подбатчи (chunked) предотвращает слишком большой размер одной транзакции, которая могла бы заблокировать другие потоки на длительное время. Для фоновой синхронизации размер подбатча 500 записей даёт оптимальный баланс скорости и отзывчивости UI.