Я бы не сказал, что Percona, Jenkins и другие упомянутые инструменты — это прошлый век. И с чего вы взяли, что статья ориентирована именно на тех, кто ставит WordPress в два клика? По такой логике можно совсем ничего не писать о том, что под капотом.
Конечно необязательно. Я вот даже примеры монговские в спойлеры попрятал. Но тем не менее, монга очень хорошо подходит и для варианта с кэшем с её capped-массивами и шардированием.
Такой вариант вполне приемлемый. Скажу более, я именно такой вариант использовал, пока не узнал о новых подходах на MongoDB World. Первые два подхода на практике не использовал, но может кому-то понадобятся, поэтому я о них упомянул. А вот третий подход, с кэшированием, считаю мега крутым.
Из всех веток наших дискуссий я понял, что помимо Монги у вас был неудачный опыт с формированием ленты на запись. Расскажу одну историю. Пару недель назад заводил профиль в Facebook своей бабушке. Добавил ей пару человек из мемьи в друзья. Представьте себе моё удивление, когда после добавления друзей я увидел у неё `девственно чистую ленту` (вы не против заимствования термина). Лента заполнилась, если я не ошибаюсь, на следующий день. Думаю вывод из этого вы можете сделать сами. Хотя я сам не считаю такою ситуацию нормальной, думаю это какая-то перемудрённая система приоритетов в их очередях. Но факт остаётся фактом.
И на счёт столь важной для вас темы приватности и удаления. На самом деле, если после удаления/скрытия поста/фото/etc что-то пойдёт не так, и процесс удаления ссылок на запись в лентах подписчиков оборвётся, то ничего страшного не произойдёт. Объясню почему. В летах подписчиков останется ссылка на запись, но оригинал записи уже будет помечена как удалённая/приватная. Поэтому подписчки её не увидят. А возникшую ситуацию можно использовать с пользой как триггер для перезапуск операции удаления ссылок.
1. В своей статье я сознательно опустил огромную кучу нюансов, с которыми сталкивался лично и описал магистральные идеи. Иначе пришлось бы раздувать статью до неприличных размеров. Но от ответа уходить не стану. Проблема решается довольно просто путём добавления ID автора к ссылке на событие (пост/лайк/etc). Т.е. мы храним не только ID оригинального события, но и юзера, который это событие породил. Таким образом очень легко и быстро можно «отписывать» от пользователей.
2.
особенно если оно рабтает на монге
Огорчает ваше предвязтое отновшение к Монге, в таком ключе тяжело вести конструктивный диалог. Я вот даже отадлённо не представляю, как в более-менее большой сети этот процесс можно реализовать атомарно. Вот честно.
Вы невнимательно читаете. Я написал про полмиллиона записей в сервис ленты, а не контента. Т.е. это записи в персональные ленты пользователей. Самая что ни на есть ключевая метрика.
Вы это серьёзно, про N-1 связей у каждого пользователя? Скажите честно, вы разрабатывали хотя бы одну социальную сеть, живущую в продакшене? В реальности, средняя цифра связей у каждого пользователя — это практически константа, абсолютно не зависящая от общего количества пользователей.
Ключевой параметр я уже вам написал. Пользователей и связей может быть сколь угодно много, но все они будут неактивными, это не показатель. И про квадратичную зависимость улыбнуло. Это показывает, что вы далеки от темы и от математики.
Стас, это не «отмазка», а пример из рабочих проектов. При чём не только из тех проектов, в которых я участвовал. Поэтому мне совершенно не понятно ваше хейтерство.
Охохо, знали бы вы, сколько там всякой всячины с удалением фото. И посты в ленте, которые удалили или сделали приватными, не такая уж и редкость (когда переходишь по ним, попадаешь на страницу с ошибкой). Более того, там и новый посты не моментально появляются. Часто видишь пост «just now», у которого уже несколько десятков лайков.
А самое главное, в бизнес требованиях к нашей системе необходимости «моментального» удаления небыло. Так что 10-20-30 секунд это абсолютно ок.
Решается довольно просто. Записи в ленте помимо ID оригинального события (поста/лайка/etc) должны содержать ID автора этого ивента. Добавляем индекс по ID автора и процессим удаление/отписку в бэкграунде. Запрос конечно получается ощутимо тяжелее чтения, но во-первых такого рода запросы случаются несравнимо реже запросов на чтение. Ну и во-вторых, скорость таких запросов некритична.
Это не сложно, но что это даст? Ведь у каждого фолловера свои персональные настройки того, что он читает. Представьте, что вам надо взять все записи всех ваших друзей, отсортировать их по времени, а потом отфильтровать кастомными фильтрами.
Проблема в том, что в новостной ленте часто показывается много больше активности пользователей, чем отображается на стене этих пользователей. Т.е. помимо постов друзей, в ленту попадает что они лайкали, с кем подружились, во что сыграли, etc.
Даже с локом на коллекцию, система без проблема держала нагрузку до полмиллиона постов в сутки. Это конечно близко не стоит с Diaspora и Facebook, но и вовсе не мало.
А в новом релизе уже реализован document-level lock. Вот так сразу снимаются все проблемы.
И на счёт столь важной для вас темы приватности и удаления. На самом деле, если после удаления/скрытия поста/фото/etc что-то пойдёт не так, и процесс удаления ссылок на запись в лентах подписчиков оборвётся, то ничего страшного не произойдёт. Объясню почему. В летах подписчиков останется ссылка на запись, но оригинал записи уже будет помечена как удалённая/приватная. Поэтому подписчки её не увидят. А возникшую ситуацию можно использовать с пользой как триггер для перезапуск операции удаления ссылок.
Не верно. Как раз таки если событи уже попало в сервис ленты, то оно обязательно отобразится у пользователя в его персональной ленте.
2. Огорчает ваше предвязтое отновшение к Монге, в таком ключе тяжело вести конструктивный диалог. Я вот даже отадлённо не представляю, как в более-менее большой сети этот процесс можно реализовать атомарно. Вот честно.
Вы это серьёзно, про N-1 связей у каждого пользователя? Скажите честно, вы разрабатывали хотя бы одну социальную сеть, живущую в продакшене? В реальности, средняя цифра связей у каждого пользователя — это практически константа, абсолютно не зависящая от общего количества пользователей.
А самое главное, в бизнес требованиях к нашей системе необходимости «моментального» удаления небыло. Так что 10-20-30 секунд это абсолютно ок.
А в новом релизе уже реализован document-level lock. Вот так сразу снимаются все проблемы.