По сути нужен движок, оптимизированный под хранение «очередей». Топик/чат/дискуссия - это всегда очередь/list/vector. Элементы часто тупо не удаляются, а помечаются «deleted».

Не хочется ваять традиционную табличку в реляционке, где есть:
(это абстрактный псевдо-SQL)


куда потом пойдут селекты вида:



Хочется чего-то проще, менее общего назначения, более специфичное. Пускай не SQL - пофиг вообще.

1. Топик/тред - всегда последовательность событий (древовидные не смотрим пока). Это должно «осознаваться» самим движком, а не приложением: движок должен понимать что он добавляет событие В КОНЕЦ очереди и присваивать ему нужные для этого атрибуты сам (номер в последовательности, например). Конечно традиционный автоинкремент имеет то преимущество, что можно дропнуть строку и значения автоинкрементных полей сохранятся какие были, а не съедут назад на 1, но мы не будем в нашем движке ничего дропать.

2. В списке тредов часто делают авто-всплытие свежих тредов наверх. Пускай наш движок хранения очередей тупо имеет timestamp пополнения каждой из очередей и мы это можем (а можем и НЕ) использовать для этих целей.

3. Как хранят древовидные системы срачевания (комментирования) - вообще слабо представляю, по-моему никак; это всегда тяжело и ненужно; в нормальных заведениях рубят уровень комментирования очень рано, на ютубе например лесенка вообще только до 2 уровня идёт.


Короче, какие системы для реализации форумов/комментариев в виде такого вот "хранения очередей" существуют?

skyANAVocoder_5, и требования к "движку" у Вас слабенькие.

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

ДедушкаVocoder_51. Топик/тред - всегда последовательность событий (древовидные не смотрим пока). Это должно «осознаваться» самим движком, а не приложением: движок должен понимать что он добавляет событие В КОНЕЦ очереди и присваивать ему нужные для этого атрибуты сам (номер в последовательности, например). обычная реляционная таблица
Vocoder_52. В списке тредов часто делают авто-всплытие свежих тредов наверх. Пускай наш движок хранения очередей тупо имеет timestamp пополнения каждой из очередей и мы это можем (а можем и НЕ) использовать для этих целей.timestamp поле в обычной реляционной таблице
Vocoder_53. Как хранят древовидные системы срачевания (комментирования) - вообще слабо представляю, по-моему никакразличных многоуровневых каталогов на реляционных субд создано до... (много короче). вариантов хранения деревьев значительно больше одного.
Vocoder_5Хочется чего-то проще, менее общего назначения, более специфичное.обосновать хотение сможете?
Обосновать хотение просто: узкоспециальное решение всегда менее ресурсоёмко (быстрее и меньше жрёт памяти), чем использование системы общего назначения.

Например, хранение последовательности постов как последовательности строк в реляционной табличке вовлекает необходимость иметь, апдейтить индекс. Конечно вставка записи (которая в порядке сортировки старше всех) в "конец" b-tree - это дёшево, это append-only. Но мне не нужен индекс. Мне нужен плоский массив, умеющий индексировать по порядковому номеру. Да, индекс это умеет, но индекс - немного оверкилл. Мне например не нужна поддержка удалений, вставок в середину и т.п. Соответственно, структура данных B-tree излишняя, можно сэкономить на всех блоках дерева выше листовых. Получаем цепочку блоков. Достаточно SSTable от гугла.

Потенциально мне не нужна и реляционка, точнее модель при которой база знает что внутри записи. Т.е. мне не надо, чтобы база знала структуру записи и умела WHERE - мне не нужны колонки в таблице. Пускай база хранит линейную последовательность массивов байт и даёт мне массив байт по индексу. Пускай база знает какая из таких цепочек в какой timestamp обновилась. Далее моё приложение будет десериализовывать массив байтов в структуру типа "пост". Серверов приложений несколько, а база одна, решает свою маленькую задачку, зато очень быстро. Дальше сервера приложений пусть десериализуют и думают что делать с этой записью. В юз-кейсе отображения сообщений поста мы как правило просто выводим последовательность сообщений, редко нужно пропустить помеченные удалёнными. Для базы это линейное чтение, streaming, что супербыстро.

skyANAVocoder_5пропущено...

Это всё реализуется на уровне приложения, юзающего базу.
Отлично. А можете рассказать, как полнотекстовый поиск реализуется на уровне приложения?
Да господи, точно так же как написано внутри какого-нибудь elasticsearch.
Пишем код, который работает во внешнем по отношению к базе "микросервисе", получает поток новых сообщений и строит свой инвертированный индекс или какой там надо. В общем, к самой "хранилке" (базе) это может отношения не иметь, заменяться, апгрейдиться, шардироваться и т.п. не трогая базу.

skyANAВот только не понятно, почему для хранения ищется что-то готовое, а для поиска как-нибудь сами напишем.
Пишите и хранения сами, в чём проблема? :)
Выделенное жирным - ложно.

skyANAVocoder_5пропущено...

Выделенное жирным - ложно.
Хорошо, тогда поясните следующее:
Vocoder_5Пишем код, который работает во внешнем по отношению к базе "микросервисе", получает поток новых сообщений и строит свой инвертированный индекс или какой там надо.
Это разве не означает, что Вы планируете написать полнотекстовый поиск как-нибудь самостоятельно?
Не означает.

И вообще, что мы там планируем или нет - наша забота, вопрос был не "проконсультируйте нас, как нам лучше поступить и оцените наши намерения".
Вопрос был о существующих системах хранения очередей. О том, как мессенджеры хранят мессаги, когда хранят их не в реляционках.
Помню вконтактик вываливал на хабр рекламу своего репозитория, где куча всяких демонов на С написана, каждый под свою мелкую задачку.

HettА причем тут очереди? Разве "мессаги" (в контексте "личные сообщения", я так понимаю) - это очередь?
Берет любую удобную Вам СУБД, делаете таблиу/схему/коллекцию: id, user_id, created_at, text
Создаете индексы какие надо (прямые, обратные, какие будут необходимы) и используете.
Если нужен шардинг, конечно лучше брать решения которые умеют делать это с коробки.
Да, мессаги - это очередь. Например этот топик - небольшая очередь с началом. События (сообщения) добавляются только в конец этой очереди и имеют некоторые атрибуты (автор, мессага, аватарка, время).

В общем, табличка вами описанная - это взять средство общего назначения и реализовать на нём очередь, где путём фичи "автоинкремент" и добавления этого автоинкрементного поля в индекс реализуется свойство очереди "адресация по индексу".

А хочется прямо узко-специальное решение для таких очередей.

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

skyANAVocoder_5, следуя Вашей логике, чем Вам таблица не очередь?
Вполне себе очередь. Просто не хочется тратиться на поддержку B+-tree индекса.

HettВ очереди и стеке можно посмотреть "безболезненно" только первый/последний (соответственно) элемент. Чтобы получить доступ к следующему, первый придется изъять (dequeue), изъятие из очереди приводит к удалению элемента. Дальше развивать мысль, почему очереди не подходят для вашей задачи?
Это частный случай очереди. В моём понимании определение очереди может быть шире.
На каких условиях возможен просмотр того, что лежит в очереди - это частности.
Главное в очереди - сохранение последовательности.
Из простого правила "сохранение последовательности" вытекают особенности операций типа pop и push. Удаляя как-то иначе, чем самое старое или новое мы нарушаем это правило. Да, в моём расширенном определении очереди возможно удаление только что добавленного, это я бы назвал "отмена добавления", что допустимо. Короче не суть, это срачь не по сабжу, это академическая тема.

skyANAVocoder_5пропущено...

Вполне себе очередь. Просто не хочется тратиться на поддержку B+-tree индекса.
Дак не создавайте его.
Но хочется быстро выгребать сообщения, относящиеся к одному топику и следующие в порядке возрастания message id.