Загрузка данных
Библиотека: хранение данных
1. Список данных и категории
Категория данных Что входит
Основные сущности читатели, книги, авторы, издательства, жанры, экземпляры книг
Операции выдачи выдача и возврат книг, даты, штрафы, бронирование
Профили и настройки настройки читателя, избранное, списки «хочу прочитать», уведомления
Описания книг аннотации, обложки, отзывы, теги (у разных книг разный набор полей)
Часто запрашиваемые популярные книги, результаты поиска, наличие экземпляров сейчас
Сессии авторизация, токены входа, корзина бронирования
Журнал событий посещения, входы в систему, поисковые запросы, логи
Статистика нагрузка по дням и часам, динамика выдач, история популярности
2. Выбор хранилища и обоснование
Читатели, книги, авторы, экземпляры → реляционная БД. Данные имеют строгую структуру и связи: книга связана с автором и издательством, экземпляр с книгой, читатель с выдачами. Нужны целостность и транзакции.
Выдача и возврат книг, штрафы → реляционная БД. Это связи «читатель — экземпляр — дата». Важно, чтобы одну книгу нельзя было выдать двум людям одновременно, а это обеспечивают транзакции.
Настройки читателя, избранное, уведомления → документная БД. У каждого читателя свой набор полей, структура гибкая и меняется без перестройки таблиц.
Описания книг: аннотации, отзывы, теги → документная БД. Книги различаются по составу полей: у одних есть аудиоверсия, у других QR-код или несколько обложек.
Популярные книги, результаты поиска, текущая доступность → кэш. Данные запрашиваются очень часто и могут храниться временно, а кэш снижает нагрузку на основную БД.
Сессии, токены авторизации → хранилище «ключ-значение». Нужен быстрый доступ по ключу (id сессии → данные пользователя), и сессии со временем истекают.
Журнал посещений, входов, поисковых запросов → БД временных рядов. Данные поступают регулярно, по времени, и их удобно агрегировать по периодам.
Статистика нагрузки и выдач → БД временных рядов: графики по дням, неделям, месяцам.
Если библиотека очень большая (миллионы записей, например архив всех операций за много лет) → широкколоночная БД, так как важны большие объёмы данных.
3. Итоговая таблица
Данные Хранилище Почему
Читатели, книги, авторы, экземпляры, выдачи Реляционная БД строгая структура и связи
Настройки, избранное, отзывы, описания Документная БД разный состав полей
Сессии, токены Ключ-значение быстрый доступ по ключу
Популярные книги, поиск, наличие Кэш частые запросы, можно хранить временно
Журнал посещений, статистика БД временных рядов регулярный поток данных по времени
Архив операций за годы Широкколоночная БД огромные объёмы
4. Схема архитектуры (для тетради)
Пользователь (читатель / библиотекарь)
│
▼
Приложение
│
┌────────┬─────────┼──────────┬──────────────┐
▼ ▼ ▼ ▼ ▼
Реляционная Документная КЭШ Ключ-значение БД временных
БД БД (сессии) рядов
(читатели, (настройки, (популярные (токены, (журнал
книги, отзывы, книги, сессии) посещений,
выдачи) описания) наличие) статистика)
Стрелки: приложение → хранилище. Дополнительно можно нарисовать, что кэш стоит перед реляционной БД: приложение сначала смотрит в кэш, и только если там нет данных, обращается к реляционной БД.
5. Что сказать на защите
Мы выписали все данные библиотеки и разделили их на 8 категорий.
Для каждой категории выбрали хранилище по принципу из таблицы технологий: строгие связи → реляционная, разные поля → документная, быстрый доступ по ключу → ключ-значение, частые запросы → кэш, поток по времени → временные ряды.
Одна БД на всё не подходит: история посещений быстро разрастётся и замедлит основную базу, а гибкие данные неудобно хранить в жёстких таблицах.
Пример потока: читатель открывает каталог → приложение берёт популярные книги из кэша → при выдаче книги запись идёт в реляционную БД → событие попадает в журнал во временных рядах.
Если нужно, могу сократить до формата, как в примере (в одну строчку на каждое хранилище), или подготовить ответы на возможные вопросы преподавателя.