Почему в ВК не используют JOIN?

Question

[Богдан Кучерук]

Читал про ВК. Писали что они не используют никаких JOINов. Почему и чем он плохой?

Comments

[Дмитрий]

Количество чтений возрастает

[Богдан Кучерук]

Дмитрий, т.е. его лучше не использовать вообще?

[Дмитрий]

Богдан Кучерук, нет.
Нормализация имеет свои плюсы минусы, денормализация свои. Нужно применять и то и то вдумчиво, там где надо. А где не надо - не применять.

[Богдан Кучерук]

Дмитрий, спасибо)

[Дмитрий]

Богдан Кучерук, как бы учитывая что по подписи "вы только изучаете" с ситуацией когда не надо join вы столкнетесь очень не скоро - по этому пока можете забыть.

[Богдан Кучерук]

Дмитрий, благодарю ещё раз) Хорошего вам дня!)

[Сергей Горностаев]

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

[Богдан Кучерук]

Уже не найду. Запомнил про «никаких joinов». Не вылетает из головы уже 2-ю неделю.

[Сергей Горностаев]

Богдан Кучерук, на сколько я помню, в VK использутся какие-то самописанные СУБД, которые скорее всего нереляционные. Так что можно расслабиться, в них в принципе нет join'ов, да и вряд ли вы когда-либо с ними столкнётесь.

[Богдан Кучерук]

Сергей Горностаев, почему вряд-ли когда-либо столкнусь? Сами писали

оценочные категории без контекста - это простительно только для дошколят

[Сергей Горностаев]

Богдан Кучерук, потому что чисто статистически очень малы шансы столкнутся с самописанным софтом. Из 30 миллионов программистов в мире едва ли тысяча работает с VK'шными СУБД.

[Богдан Кучерук]

Сергей Горностаев, понял, спасибо большое) Хорошего Вам дня!)

[Василий Банников]

Сергей Горностаев, на сколько я слышал, они кастомные бэкенды пишут для мускула, под некоторые данные.

[Сергей Горностаев]

Василий Банников, отказались они от MySQL давно.

[Василий Банников]

Сергей Горностаев, ну и статья та достаточно старая, где они про это рассказывали

Answer 1

[mayton2019]

JOIN - не плохой.

В эпоху соц-сетей (facebook e.t.c.) придумали подготавливать веб-контент на сервере для каждого пользователя персонально. Ваша лента новостей. Ваш landing. Статистика. Все это хранится в какой нибудь RocksDb (на самом деле я не знаю в какой просто для примера взял) и извлекается просто по ключу. Обновляются эти документы по событиям. Тоесть мессенджинг системы тоже нужны. LinkedIn был настолько озабочен этим вопросом что создал Kafka решая задачи своей соц-сети.

Все эти хитрости сделаны только для того чтобы убрать реляционные БД из стека веб-технологий и сделать отрисовку landing как можно более быстрой. И этой быстроты невозможно было-бы достичь если-бы делать select всех новостей где подписчик == вы и где еще и все 100500 новостей order by... короче поняли. Ну и join тоже убрать. В любой умной БД есть звезда или снежинка и отрисовать на экране звезду и снежинку без join невозможно. Вобщем join здесь не причем. А важно что - убрали стек одинаковых повторяющихся операций поиска-соединения-фильтрации-сортировки и заменили на извлечение документа из документной БД.