"Законы написанные под большую войну"⁠⁠2

Касаемо инструментов. Мне кажется тут, как инженеру, следует сосредоточиться на двух проблемах:

1. Быстрое чтение.

2. Шардирование. В каждом посту не так много комментариев, но в совокупности речь идет о миллиардах записей.

Что касается графовых баз.

Я представляю, как будут выглядеть эти данные в виде графа. Здорово будут выглядеть.

А теперь вопрос:

Вам нужно подгрузить следующие N записей.

Эти записи могут быть как и корнями, так и узлами. Или только узлами, если корневой комментарий собрал больше N ответов.

Причем отправной точкой, от которой нужно добрать еще N ответов, не обязательно будет корень, а может быть как терминальный узел, так и промежуточный.

То есть Traverse от терминального или промежуточного узла, здесь не подойдет. Так как количество выбранных данных может оказаться меньшим чем N.

Но допустим, что движок графовой бд при траверсе ломанется не только по out-вершинам, но и по in-вершинам. Казалось бы что мы "сделаль задачу", но есть подвох.

Представим что вы сейчас на ответе 2 уровня, который получил 300 ответов 3 уровня. Но ответы 3 уровня на странице нет, их еще не загрузили. То есть последний видимый на странице ответ - это ответ 2 уровня.

И вам на ответ 2 уровня нужно получить следующие 100 элементов. Загрузили. Вы сейчас на 100 элементе 3 уровня, но пользователь хочет еще 100...

Если мы работаем с графом, а не b-tree, нам нужно как-то отсечь уже загруженные 100 элементов. Можно использовать дату. А если дата одинаковая?

Полагаю, что в графовых базах явно или неявно для каждого узла, в рамках своего уровня и родителя, есть sequence_id и тогда проблема отсчета следующих 100 соседей решена. Но опять же этот узел, для отсчета ближайших 100 соседей, надо быстро найти. И мы опять приходим к некоему индексу (B-tree или Inverted), которому пофиг на графовость/вершины и который нужен, лишь для того чтобы быстро найти вершину от которой мы начнем траверсить граф.

В общем, вернулись обратно к индексу.

И нужна ли тут графовость? Нужны ли нам вершины и указание их направления? При чтении важно лишь получить набор узлов дерева, ключи которых находятся в диапазоне "текущий узел + N"

Поэтому ответом на проблему является B-tree.

Тут уж для решения проблем подойдет любая БД, которая позволит раскидать комменты по разным шардам с ключом шардирования "идентификатор поста" и с возможностью построить составной индекс.

По поводу денормализации:

Стремиться к нормальным формам, это круто. Но на практике денормализуют для ускорения чтения/вставки.

Минусы денормализации тоже понятны - дублирование данных и проблемы с обновлением. Но в данном случае положение комментария в иерархии неизменно.

А еще реляционки используют, чтобы иметь транзакционность. Это не наш продуктовый сценарий, в комментариях пикабу она не нужна.

Но если нужно быстро читать/вставлять, а для некоторых сценариев транзакционность , то тут уже денормализованная реляционка.

Касаемо распределенных блокировок, естественно что их стоит избегать, если их избежать возможно. Как альтернативу распределенной блокировке, можно в прикладном коде поменять решение на использование ретраев с оптимистичной блокировкой.

P.S. Кстати, а как графовая БД обеспечивает уникальность seq_id в рамках родителя? Это маленький намек насчет блокировок :)

Во время путчей (=вооруженных беспорядков в Москве) в 1991 и 1993 годах по телевизору круглые сутки крутили балет типа Лебединое озеро. С тех пор это ассоциация, что происходит какой-то пздц.

Ну оркестр - это, разумеется, про ЧВК Вагнера

Можно)

"Саш, ну мы же с первого класса вместе. И за всё что мы делаем, отвечаем тоже вместе!"

Недавно вылетал самолётом в одну из стран ближнего зарубежья — так после таможенного контроля, в зале с дьютиками всё увешано рекламой службы в армии. Это, типа, чтобы даже сомневающийся (если относится к определённой половозрастной группе) твёрдо решил, что нахер ему обратный билет?

напечатали же. Счас по 90 же еще, да?

К сожалению, вся наша жизнь вертится вокруг заработка. И очень грустно, что сейчас, возможно, толковые люди могут только  заработать  ценой своей жизни.