Как лучше организовать архитектуру онлайн-библиотеки?

Доброго времени суток, возник следующий вопрос.
Как лучше организовать архитектуру онлайн-библиотеки, если подразумевается следующий функционал:
- Добавление пользователем своей книги (файл)
- Добавление в свою библиотеку книги из глобальной

Глобальная библиотека = список всех существующих на платформе книг, комментарии к ним и вся информация

Как лучше реализовать это с точки зрения базы данных?
  • Вопрос задан
  • 2804 просмотра
Пригласить эксперта
Ответы на вопрос 1
TDz
@TDz
Вопрос очень обобщенный, уточните пожалуйста масштаб проекта, т.к. раздутость архитектуры зависит напрямую от количества фишек и ожидаемой нагрузки, от списка юзкейсов в первую очередь. Я разрабатывал ряд крупных книжных проектов архитектура в целом где-то такая

1) ядро, хранит базовые сущности (книги, авторов, коллекции, категории, серии, издания, итд) и их связи. Предоставляет такие сервисы как GetBookById, GetListByCategory, GetListByAuthor, GetListByCollection... если проект большой и распределенный к к ядру идут несколько "декораторов" - они подбирают и сериализуют полученные данные в требуемое представление (JSON/XML для предоставления API, объекты разной степени детализованности для внутреннего использования)

Крутится как правило на стандартных базах, т.к. набор фич ядра довольно примитивен а паттерны доступа простые. Ну а кодит кто на чём горазд. Каждой сущности таблица, связи как правило n-m так что сразу заводите единый реестр XtoY (ну или для каждой пары свой если хотите).

2) индексатор берёт данные из ядра и генерирует на их основании метаданные (графы, полнотекстовые индексы, prediction индексы, стоплисты итд). Поиск по этим метаданным значительно более эффективный чем выборки их базы на сложных и запросах. Также индексатор позволяет осуществлять быстрый полнотекстовый поиск по описаниям данным и даже внутренностям книг и делать выборки типа "дай мне книги на немецком, изданные между 1920 и 1940 на исторические темы авторами чьё имя начинается на А и которые имеют рейтинг не менее 4 а стоят не более 20 баксов, нго только те у которых в описании есть слово любовь а в тайтле либо ненависть либо смерть".

тут использ-уют как правило спец демоны типа sphinx/lucene

3) Фасеточный поисковик собтвенно умеет убращаться к индексаторам и из полученных в прошлом модуле метаданных получать полезные функции типа "какие книги похожи на эту", "какие авторы в разделе наиболее популярны", накладывать фильтры на листинги сущностей итд

4) Фронт-энд - собственно логика отображения сайта, код состоит по большей части из запросов к ядру и фасеточнику и шаблонизатора который их ответ завернёт в красивый лейаут

5) CDN - хранилище и система доставки статических файлов. Обложки книг, семплы, сами книги итд. Ресайзилка картинок, управление кешем, защита от скачивания итд итп. На высоконагруженном проекте тут логики может быть довольно много. На маленьком сайте достаточно тупо складывать файлики в папочку ))))

6) Редакционная система - книги товар с огромным количеством важных метаданных, критичных для юзера (если книги научные), иногда нужна серьёзная система сбора и модификации этих метаданных

В общем говорить можно долго, если решите всерьёз заняться - пишите. Поделюсь опытом и наработками
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы