Задача на system design UPDATE: Файлы нужно хранить в распределенном файловом хранилище, а не в базе данных. Телеграм канал t.me/roadofbug... Блог на бусти boosty.to/road...
Спасибо за видео! Есть несколько вопросов/уточнений: 1. Фотографии нужно хранить в Object Storage (S3, например) 2. Откуда в БД подписок будет ID ленты? 3. Для БД подписок лучше использовать, например, GraphDB, чтобы быстрее находить связи между подписками 4. Нет Load Balancer, это самое первое, что нужно нарисовать на собеседованиях 5. Нет CDN для фотографий 6. Нет какой-то логики генерации лент, если у человека действительно много подспичиков 7. Лучше изначально использовать реляционные базы данных
Привет. 1. Думал об этом. Не смог объяснить, чем это лучше любой распределенной документной БД. 2. ID ленты = ID юзера. Например, юзер с ID=123 подписался на 10 других юзеров. В ленте с ID=123 будет поток событий от этих 10 юзеров. 3. В задаче нет нужды обрабатывать граф связей и находить, например, подписчиков подписчиков. Если бы такая нужда была, то, конечно, графовая БД подошла бы. Но сходу такой необходимости не увидел. 4. Согласен с замечанием. 5. Согласен с замечанием. 6. Логика описана в видео. Ленты обновляются асинхронно. Конфликтов обновления нет, так как топик событий лент партицирован по ID ленты. То есть, все события обновления ленты приходят в один consumer. 7. Реляционная БД будет ограничивать масштабирование в части записи. Нагрузка по части записи высокая, как раз в сервисе лент.
"Реляционная БД будет ограничивать масштабирование в части записи. Нагрузка по части записи высокая, как раз в сервисе лент." Для собесов лучше использовать реляционные с ремаркой, что если мы достигнем потолка в этом типе СУБД, то перейти на NoSQL решения, т.к. у него есть свои минусы и плюсы, если конечно не хочешь сразу отвечать, а почему NoSQL? :) "ID ленты = ID юзера. Например, юзер с ID=123 подписался на 10 других юзеров. В ленте с ID=123 будет поток событий от этих 10 юзеров." К сожалению, я всё равно до конца не понял концепцию, т.к. нам нужно обновлять ленту не того пользователя, который запостил фотку, а ленты всех его подписчиков и тут как раз нужна графовая БД. И как раз про алгоритм, что иногда нет смысла обновлять все ленты всех подписчиков, можно ограничиться, например, 10% самых активных пользователей, а для остальных генерировать "на лету". Просто представьте, что пользователь с большим количеством подписок запостит 50 фото в течение 5-10 минут. "Думал об этом. Не смог объяснить, чем это лучше любой распределенной документной БД." Любой контент: фото, видео, аудио и т.д. должны храниться только в Object Storage, а в БД должны быть только ссылки на эти файлы
@@SinXхранение файлов в БД уже выстрел в ногу 😂 сервис фотографий идюзера+идфайла, сервис ленты идюзера+идфайла, никого не смутило. Также я бы посмотрел на сценарий удаления или изменения файлы в ленте, думаю он будет очень веселым. Ну и главный вопрос: чем 3 масштабируемые монги лучше одной.
@@roadofbugs 2. В качестве самой примитивной возможности, да, ID ленты = ID юзера, но в перспективе можно заложить основу для нескольких лент для каждого пользователя (об этом и спрашивал человек как мне кажется, по типу премиум ленты, ленты со скрытым контентом если в будущем будут уровни подписки как например на бусти...). 6. Здесь тоже "Логика описана в видео", на сколько я понял будет показываться, условно, 20 последних событий, но можно предусмотреть возможность ранжирования, исключения ранеепоказанного (если у вас 1000 подписок и вы всегда смотрите одно и тоже не добираясь до конца из-за того что сервис не определяет что вы уже видели, а что нет) и так далее... может быть увеличение вероятности показа в зависимости от статуса пользователя (сейчас все пользователи равны, но в перспективе при развитии проекта лучше иметь такую архитектуру изначально) Это не замечания, так как я не разработчик таких систем)))) скорее мои мысли как диванного эксперта
А если я подписался на юзера вот только что, тогда я не увижу его старые записи, потому что меня не было в сервисе подписок на него? И еще вопрос: если у юзера миллион подписчиков, то 1 его фотка сгенерит миллион записей в такой архитектуре?
В предложенной архитектуре - да. А какова альтернатива? Не хранить, а генерировать ленты при каждом ображении каждого юзера за лентой? Нагрузка побольше будет на систему, имхо
@@user-rs3lv9yc1g, а что такое лента? Это просто выборка из таблицы событий, отфильтрованная по ид юзера. Большинство SQL баз данных отлично справляются с такими запросами. Все эти навороты с MongoDB и Kafka только на собеседованиях прикольно выглядят. В реальности PostgreSQL+Redis за глаза хватает для подобных систем
Их не надо в Docker запихивать или другие контейнеры. А вот без виртуальных машин не обойтись в ЦОДах и Cloud -> там все виртуализировало 🙂 Ну или использовать их платформы-хранилища.
@@denyskovzikov1034 Тема в принципе холиварная. Но несколько причин почему не стоит именно долгосрочную информацию там сохранять: - драйверы управления сохранением данных считаются до сих пор не такие надежные у контейнеров, чем у компьютерных машин, даже виртуальных. - контейнеры изначально не задумывались как полноценная замена виртуальной машины. Это скорее узел в распределенной среде, где контейнеры как элементы Лего, легко можно поднимать/запускать/вынимать/разрушать и вместо ставить новый, если старый завис или вышел из строя. За счет контейнеров можно универсально поднимать много одинаковых нод и балансировать нагрузку больших распределенных приложений. То есть это контейнер с программным кодом, который легко поднять как сервер и легко утилизировать, если он не нужен. И хранить в таких динамичных контейнерах долгосрочную информацию опасно, чтоб не попрощаться с ней) Плюс если мы говорим о распределенном приложении, то база данных общая и не должна принадлежать одной ноде. Ноды только как канал обработки вытягивают/обрабатывают и складывают обратно в базу инфу. - на сколько я знаю, если нода Docker вышла из строя, вытянуть от туда нужные файлы или базы уже достаточно проблематично.
@@denyskovzikov1034 потому что любая виртуализация это лишний слой общения с железом. Современная бд, оптимизирована на прямое общение с диском (особенно если это hdd). Плюс представь контейнер размером несколько терабайт, где 99.999% его размера это данные, которые просто так не извлечешь, нужно запустить контейнер. Перенести его просто тоже не получится.
Спасибо за видео!
Есть несколько вопросов/уточнений:
1. Фотографии нужно хранить в Object Storage (S3, например)
2. Откуда в БД подписок будет ID ленты?
3. Для БД подписок лучше использовать, например, GraphDB, чтобы быстрее находить связи между подписками
4. Нет Load Balancer, это самое первое, что нужно нарисовать на собеседованиях
5. Нет CDN для фотографий
6. Нет какой-то логики генерации лент, если у человека действительно много подспичиков
7. Лучше изначально использовать реляционные базы данных
Привет.
1. Думал об этом. Не смог объяснить, чем это лучше любой распределенной документной БД.
2. ID ленты = ID юзера. Например, юзер с ID=123 подписался на 10 других юзеров. В ленте с ID=123 будет поток событий от этих 10 юзеров.
3. В задаче нет нужды обрабатывать граф связей и находить, например, подписчиков подписчиков. Если бы такая нужда была, то, конечно, графовая БД подошла бы. Но сходу такой необходимости не увидел.
4. Согласен с замечанием.
5. Согласен с замечанием.
6. Логика описана в видео. Ленты обновляются асинхронно. Конфликтов обновления нет, так как топик событий лент партицирован по ID ленты. То есть, все события обновления ленты приходят в один consumer.
7. Реляционная БД будет ограничивать масштабирование в части записи. Нагрузка по части записи высокая, как раз в сервисе лент.
"Реляционная БД будет ограничивать масштабирование в части записи. Нагрузка по части записи высокая, как раз в сервисе лент."
Для собесов лучше использовать реляционные с ремаркой, что если мы достигнем потолка в этом типе СУБД, то перейти на NoSQL решения, т.к. у него есть свои минусы и плюсы, если конечно не хочешь сразу отвечать, а почему NoSQL? :)
"ID ленты = ID юзера. Например, юзер с ID=123 подписался на 10 других юзеров. В ленте с ID=123 будет поток событий от этих 10 юзеров."
К сожалению, я всё равно до конца не понял концепцию, т.к. нам нужно обновлять ленту не того пользователя, который запостил фотку, а ленты всех его подписчиков и тут как раз нужна графовая БД. И как раз про алгоритм, что иногда нет смысла обновлять все ленты всех подписчиков, можно ограничиться, например, 10% самых активных пользователей, а для остальных генерировать "на лету". Просто представьте, что пользователь с большим количеством подписок запостит 50 фото в течение 5-10 минут.
"Думал об этом. Не смог объяснить, чем это лучше любой распределенной документной БД."
Любой контент: фото, видео, аудио и т.д. должны храниться только в Object Storage, а в БД должны быть только ссылки на эти файлы
@@SinXхранение файлов в БД уже выстрел в ногу 😂 сервис фотографий идюзера+идфайла, сервис ленты идюзера+идфайла, никого не смутило. Также я бы посмотрел на сценарий удаления или изменения файлы в ленте, думаю он будет очень веселым. Ну и главный вопрос: чем 3 масштабируемые монги лучше одной.
@@roadofbugs
2. В качестве самой примитивной возможности, да, ID ленты = ID юзера, но в перспективе можно заложить основу для нескольких лент для каждого пользователя (об этом и спрашивал человек как мне кажется, по типу премиум ленты, ленты со скрытым контентом если в будущем будут уровни подписки как например на бусти...).
6. Здесь тоже "Логика описана в видео", на сколько я понял будет показываться, условно, 20 последних событий, но можно предусмотреть возможность ранжирования, исключения ранеепоказанного (если у вас 1000 подписок и вы всегда смотрите одно и тоже не добираясь до конца из-за того что сервис не определяет что вы уже видели, а что нет) и так далее... может быть увеличение вероятности показа в зависимости от статуса пользователя (сейчас все пользователи равны, но в перспективе при развитии проекта лучше иметь такую архитектуру изначально)
Это не замечания, так как я не разработчик таких систем)))) скорее мои мысли как диванного эксперта
@@nnz13 "хранение файлов в БД уже выстрел в ногу" - а как их надо хранить? (п.с. я не разработчик, поэтому понятия не имею, но интересно)
Не хватает расчета нагрузки: количество клиентов, постов, запросов
хорошее видео, спасибо!
Сколько лет у вас опыт разработки, если не секрет?
А если я подписался на юзера вот только что, тогда я не увижу его старые записи, потому что меня не было в сервисе подписок на него?
И еще вопрос: если у юзера миллион подписчиков, то 1 его фотка сгенерит миллион записей в такой архитектуре?
В предложенной архитектуре - да.
А какова альтернатива?
Не хранить, а генерировать ленты при каждом ображении каждого юзера за лентой? Нагрузка побольше будет на систему, имхо
@@user-rs3lv9yc1g, а что такое лента? Это просто выборка из таблицы событий, отфильтрованная по ид юзера. Большинство SQL баз данных отлично справляются с такими запросами.
Все эти навороты с MongoDB и Kafka только на собеседованиях прикольно выглядят.
В реальности PostgreSQL+Redis за глаза хватает для подобных систем
а как называется программа для создания схемы соцсети ?
excalidraw
Базы данных лучше не виртуализировать, насколько мне известно.
Интересная мысль👍, а почему так? Было бы интересно узнать🤔
Их не надо в Docker запихивать или другие контейнеры. А вот без виртуальных машин не обойтись в ЦОДах и Cloud -> там все виртуализировало 🙂 Ну или использовать их платформы-хранилища.
@@Mytest437 Да я понял, ты просто продублировал его коментарий. Я же спросил почему так? Никогда не слышал такого вот и интересуюсь почему?
@@denyskovzikov1034 Тема в принципе холиварная. Но несколько причин почему не стоит именно долгосрочную информацию там сохранять:
- драйверы управления сохранением данных считаются до сих пор не такие надежные у контейнеров, чем у компьютерных машин, даже виртуальных.
- контейнеры изначально не задумывались как полноценная замена виртуальной машины. Это скорее узел в распределенной среде, где контейнеры как элементы Лего, легко можно поднимать/запускать/вынимать/разрушать и вместо ставить новый, если старый завис или вышел из строя. За счет контейнеров можно универсально поднимать много одинаковых нод и балансировать нагрузку больших распределенных приложений. То есть это контейнер с программным кодом, который легко поднять как сервер и легко утилизировать, если он не нужен. И хранить в таких динамичных контейнерах долгосрочную информацию опасно, чтоб не попрощаться с ней) Плюс если мы говорим о распределенном приложении, то база данных общая и не должна принадлежать одной ноде. Ноды только как канал обработки вытягивают/обрабатывают и складывают обратно в базу инфу.
- на сколько я знаю, если нода Docker вышла из строя, вытянуть от туда нужные файлы или базы уже достаточно проблематично.
@@denyskovzikov1034 потому что любая виртуализация это лишний слой общения с железом. Современная бд, оптимизирована на прямое общение с диском (особенно если это hdd). Плюс представь контейнер размером несколько терабайт, где 99.999% его размера это данные, которые просто так не извлечешь, нужно запустить контейнер. Перенести его просто тоже не получится.
Балансировщика не хватает
Думаю Api (http) может быть как прокси так и балансировщиком