Sasha_Odesskiy
@Sasha_Odesskiy
бла-бла-бла!

В каком виде, хранятся записи в БД, подобные постам в соц.сетях?

Доброго времени.
Как сохраняются(в каком виде) записи постов соц.сетей/мессенджеров таких как Телеграм, ОК, ВК, Фейсбук и прочее?
P.S.
Целиком в БД сохраняют с тегами HTML, или Объектом JSON. Поскольку в посте, могут быть изображения, ссылки, видео, эмоджи и т.д.
  • Вопрос задан
  • 478 просмотров
Решения вопроса 1
mayton2019
@mayton2019
Bigdata Engineer
Современная соц-сеть - это уникальная софтварная архитектура которая строилась индивидуально.
Вряд-ли вы сможете ее просто повторить имея mysql/php/nginx.

VK/Facebook имеют свои технологии кеширования контента в основном построенные на материализации
страниц. Базы данных обычно - не-реляционные. Модель проектируется так чтобы не было joins между
таблицами. И активно используются очереди сообщений. Вот в соц-сети Linked-In это было настолько
важно что даже был создан отдельный программный продукт который сейчас называют Apache Kafka.

Активно используются горизонтальное масштабирование. Сеть наращивает мощности просто путем подключения
новых адресов в dns с балансом по географии, и запуска новых web-nodes и новых дисковых реплик хранилищ для картинок и текстов постов.

Поэтому вопрос в каком виде хранятся записи - тут не важен. Тут важно чтоб кеши обновились синхронно с событием поста например.
Ответ написан
Пригласить эксперта
Ответы на вопрос 1
Stalker_RED
@Stalker_RED
что-то по лучше, чем MySQL
а что получше - феррари, карьерный самосвал или метро?
Феррари вроде как быстрее, но не может перевезти 500 тонн за один рейс. Карьерный самосвал перевезти может, но расход горючки сумасшедший. А у метро фича - гоняет без пробок, но только там, где рельсы заранее проложили.

Все хорошо у MySQL с ресурсами.
У вас сейчас нет соцсети с миллионами юзеров, поэтому вам не нужна никакая навороченная сверхпроизводительная архитектура и бигдата.
Когда упретесь в производительность вы сперва подкрутите настройки того-же мускула, потом распараллелите, потом часть данных вынесете в какой-нибудь редис, и только когда и этого будет мало, вот тогда вы задумаетесь о смене основной БД.
К этому времени вы уже будете иметь представления какие у вас посты, сколько их, где у вас в архитектуре узкие места, и будете неплохо представлять какие есть альтернативы.
Альтернативы конечно и сейчас есть, но они вам не нужны в данный момент - больше мороки с ними, чем пользы. Ну выберете вы сейчас метро, например, будете инвестировать скиллы и время в рельсы, а в тоге окажется что вам нужно не метро и не самоствалы, а больше подошли бы нефтеналивные танкеры. Вы заранее не можете предсказать что и как у вас будет устроено.

Целиком в БД сохраняют с тегами HTML, или Объектом JSON

Начать можете с подхода "храним в том виде в котором пришло с клиента, перед показом чистим".
Это позволит на лету подправлять тот функционал что перед показом, и заплатите вы за это только некоторым количеством процессорной нагрузки.
Когда он окончательно утвердится, можно перейти на "чистим пред сохраннением в БД", что сэкономит ту самую нагрузку (очистка ровно один раз), но сразу упадет гибкость, так как данные, которые вы удалили при чистке уже не восстановить.

Тяжелые медиа, типа видеороликов, вы довольно скоро вынесете в отдельное хранилище, как только заметите что у вас этих одинаковых роликов тысячи, и неплохо бы к ним дедупликацию прикрутить.
А как хранить эмоджи - практически не важно.
Ответ написан
Комментировать
Ваш ответ на вопрос

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

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