Ограничения и квоты хранилища

Браузерное хранилище, используемое через IndexedDB и библиотеки вроде Dexie.js, подчиняется системе ограничений, определяющей максимальный объём данных, который сайт может использовать. Эти ограничения не являются фиксированными числами и зависят от множества факторов: устройства, свободного дискового пространства, политики браузера, типа хранилища и режима работы пользователя.

IndexedDB предоставляет асинхронный API для работы с локальными базами данных, однако сама система хранения управляется браузером, а не приложением. Dexie.js лишь упрощает взаимодействие с IndexedDB, не изменяя принципов квотирования.

Общая модель квотирования в современных браузерах

Система квот в браузерах строится вокруг понятия origin storage, где каждый источник (протокол + домен + порт) получает собственный изолированный лимит.

Основные характеристики:

  • квота применяется ко всем типам хранилищ вместе (IndexedDB, Cache Storage, LocalStorage и др. в рамках одного origin);
  • лимиты динамические и зависят от свободного диска;
  • браузер может автоматически расширять или сокращать доступный объём;
  • при нехватке места применяется eviction-политика (удаление данных).

В современных Chromium-браузерах квота часто составляет до 60%–80% свободного дискового пространства, но это значение не гарантируется и может быть уменьшено политиками устройства.

Поведение при достижении лимита

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

  • QuotaExceededError

Dexie.js не подавляет эту ошибку, а передаёт её через промисы, что позволяет обрабатывать ситуацию стандартными средствами:

  • откат транзакции;
  • уведомление пользователя;
  • очистка устаревших данных;
  • повторная попытка записи после освобождения места.

Ключевая особенность IndexedDB — атомарность транзакций: если операция не помещается в квоту, вся транзакция откатывается.

Различия браузеров в реализации квот

Chromium (Chrome, Edge, Opera)

  • динамическое расширение квоты;
  • использование алгоритма LRU (least recently used) для удаления данных при нехватке места;
  • поддержка Storage Manager API для оценки доступного объёма;
  • более агрессивное освобождение места при системной нехватке диска.

Firefox

  • более консервативная модель;
  • жёсткие ограничения на origin;
  • менее предсказуемое поведение eviction;
  • строгая изоляция профилей.

Safari

  • наиболее ограниченная реализация;
  • часто применяет краткосрочные лимиты;
  • может очищать IndexedDB при политике «website data cleanup»;
  • ограниченная предсказуемость при долгосрочном хранении.

Оценка доступного хранилища

Для управления квотами используется Storage API:

  • navigator.storage.estimate()

Он возвращает два ключевых параметра:

  • usage — текущее использование;
  • quota — максимально доступный объём.

На основе этих значений можно строить стратегию хранения:

  • прогнозировать заполнение базы;
  • ограничивать запись больших объектов;
  • реализовывать собственные политики очистки.

Dexie.js не предоставляет встроенного контроля квот, но легко интегрируется с этим API через обычный JavaScript.

Постоянство данных и режимы хранения

Браузеры различают временное и постоянное хранилище.

Temporary storage

  • используется по умолчанию;
  • может быть очищено автоматически;
  • подвержено eviction при нехватке места.

Persistent storage

  • требует явного запроса через: navigator.storage.persist();
  • снижает вероятность удаления данных;
  • не гарантирует абсолютной сохранности, но повышает приоритет.

Dexie.js работает поверх IndexedDB и автоматически использует текущий режим хранения, не управляя им напрямую.

Eviction-политика и автоматическое удаление данных

При нехватке дискового пространства браузер может начать удаление данных origin без участия приложения.

Приоритет удаления обычно следующий:

  1. Cache Storage
  2. IndexedDB
  3. LocalStorage

Однако порядок может варьироваться.

Факторы, влияющие на eviction:

  • давность использования данных;
  • активность сайта;
  • объём занимаемого места;
  • пользовательские настройки;
  • режим инкогнито или приватный режим.

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

Особенности работы Dexie.js в условиях ограничений

Dexie.js предоставляет удобную обёртку над IndexedDB, но ограничения квот остаются полностью на стороне браузера.

Поведение при превышении лимита:

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

Типичные стратегии обработки:

  • разбиение больших операций на меньшие батчи;
  • использование bulk-запросов с контролем размера;
  • хранение крупных бинарных данных вне IndexedDB (например, в Cache Storage);
  • применение сжатия данных перед записью.

Большие объёмы данных и практические ограничения

IndexedDB теоретически позволяет хранить сотни мегабайт и даже гигабайты данных, но практические ограничения зависят от:

  • устройства пользователя (мобильное или десктоп);
  • доступного дискового пространства;
  • политики браузера;
  • активности других сайтов.

Особенно чувствительны:

  • хранение blob-файлов;
  • массивы больших объектов;
  • массовые операции записи без батчинга.

Dexie.js поддерживает bulk-операции (bulkAdd, bulkPut), однако даже они не защищают от квотирования.

Контроль размера базы данных

Типовые подходы к контролю роста базы:

  • ведение метаданных о размере записей;
  • периодическая агрегация и очистка;
  • TTL (time-to-live) для объектов;
  • сегментация данных по таблицам;
  • ограничение максимального числа записей.

Пример логической стратегии:

  • хранение последних N записей;
  • удаление устаревших по дате;
  • приоритетное сохранение критичных данных;
  • фоновые задачи очистки через Dexie.js транзакции.

Ошибки и диагностика квотирования

Основные признаки проблем с квотой:

  • QuotaExceededError при записи;
  • внезапные откаты транзакций;
  • частичная потеря данных после перезапуска;
  • рост времени выполнения операций из-за eviction.

Дополнительные диагностические инструменты:

  • navigator.storage.estimate() для анализа состояния;
  • DevTools Application tab (IndexedDB инспектор);
  • профилирование объёма объектов;
  • логирование операций Dexie.js через hooks (db.on('error'), transaction.on('error')).

Влияние приватного режима

В режиме инкогнито:

  • квоты значительно уменьшены;
  • данные часто хранятся только в памяти;
  • после закрытия сессии всё удаляется;
  • eviction может происходить мгновенно при достижении лимита.

Dexie.js в этом режиме не получает специальных уведомлений — поведение полностью определяется браузером.

Стратегии устойчивого хранения

Для надёжной работы с IndexedDB и Dexie.js в условиях квот применяются архитектурные подходы:

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

Роль архитектуры приложения в управлении квотами

Квоты хранилища напрямую влияют на архитектурные решения:

  • необходимость продуманной модели данных;
  • отказ от бесконтрольного логирования в IndexedDB;
  • ограничение глубины истории;
  • использование индексов только при реальной необходимости;
  • баланс между локальным хранением и серверной синхронизацией.

Dexie.js облегчает работу с IndexedDB, но не абстрагирует ограничения физического хранилища, поэтому проектирование структуры данных остаётся ключевым фактором стабильности.

Оглавление