кулинарных рецептов, соответственно будут юзеры, посты с рецептами, фолловеры (основные сущности). Вот остановился на построении архитектуры. Смотрел на реляционные базы в частности постгрес, как стандартное решение. Но вот если у нас будет оочень много юзеров, постов и т.д., запросы джоинов буду проходить очень медленно (такие, как сделать сначала выдачу постов юзеров, за которыми следит данный пользователь). Потом пошел к NoSQL решениям, смотрел Кассандру - но в ней не получится сделать то, что нужно (например отфильтровать посты по кол-ву ингредиентов (ну сами понимаете, как устроена Кассандра)). Смотрел графовые БД, Neo4j, но они не очень предназначены для хранения больших данных, запросы тоже будут идти долго. Потом решил загуглить как устроен Интсаграмм, они как-то умудряются юзать и Кассандру и Постгрес, не знаю как. Ну ок. Решил всё таки остановится на Постгресе. Но вопрос в том как с помощью системы кеширования (Редис, например) ускорить время ответа на запрос. Можно ли делать так? Берем 1000 грубо говоря постов с постгреса и кладём в Редис, ну и потом уже с клиента идём в Редис и пагиннируем (с лимитом 12 постов допустим) эти посты и возвращаем нужное клиенту? Или можно как-то по-другому это реализовать? Подскажите пожалуйста, буду очень благодарен)
Как у вас все интересно медленно получилось еще даже без какой либо реализации 😄 Ни сколько пользователей предполагается, ни сколько постов предполагается, ни каких цифр, но все медленно, даже на касандре 😅
По-моему вы слишком заранее оптимизируете. Просто набросайте архитектуру для ваших требований, надо будет нормализовать данные в каком-то виде? нормализуйте! надо будет кешить какие-то выборки? ну используете редис для сохранения ответа от бд при конкретном запросе, а не переносите бд из постгреса в редис!
С Closure table можно уже много джойнов оптимизировать, если структура вроде форума. https://bitworks.software/en/2017-10-20-storing-trees-in-rdbms.html
Обсуждают сегодня