LINUX.ORG.RU

СУБД оптимальная для форумов/чатов?

 


0

2

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

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

create table posts (
      topic_id INT,
      message_id INT autoincrement,
      msg VARCHAR
) INDEX (topic_id, message_id);

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

SELECT .. from posts where topic_id = 555 ORDER BY message_id offset ..;

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

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

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

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

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



Последнее исправление: hlamotron (всего исправлений: 1)

Касандру бери. Её дискорд юзает как хранилище.

anonymous
()

Ну я даже не знаю... А зачем тебе именно оптимальная система?

anonymous
()
Ответ на: комментарий от hlamotron

Для «классических» чатов всегда хватало хранения всей истории сообщений как plain text в любом удобном виде. Но вы, кажется, хотите чего-то более сложного.

Leupold_cat ★★★★★
()
Ответ на: комментарий от Leupold_cat

Для «классических» чатов всегда хватало хранения всей истории сообщений как plain text в любом удобном виде. Но вы, кажется, хотите чего-то более сложного.

Чё вы все уцепились за эти чаты.

Речь идёт об абстрактной последовательности реплик. Представьте для наглядности политический срач на 80К страниц на форуме. Тот же чатик, только представленный в ином виде с другой формой взаимодействия человеков.

hlamotron
() автор топика

Чел явно просит не реляционные базы данных, а ему уже понасоветовали InnoDB, Postgres.

А я скажу следующее: делай обертку над MySQL / Postgres на том же PDO.

Я использовал для похожей темы mongodb, у меня был сбор статистики с сайтов, где тонна инсертов и селектов, думал убегу от MySQL, ага щаз, валилась эта монгла, головняка больше стало, в итоге все равно пришел к MySQL.

А теперь по делу: дерево хранят в одной таблице через parent_id. По пункту 1: я так понял хочешь работать с объектом к примеру Post, а не с записью в базе данных? Используй ActiveRecord / DataMapper он как раз от этого абстрагируется.

Пункт 2: я делал через две таблицы, к примеру: posts и posts_queue, где последняя запись является первой в выводе (ORDER BY id DESC)

На счет Select, вы думаете меньше запросов писать будете? Ищите QueryBuilder, тут чувак недавно похожий QueryBuilder на Java писал.

fman2
()

Теоретически для таких задач как нельзя лучше подойдет документо-ориентированная БД с полнотекстовым поиском. У всех реляционных видно с этим проблемы, потому повсеместно к сайтам прикручивают поиск от google. Я сталкивался только с двумя документо-ориентированными базами, MongoDB и Elasticsearch, последнюю в java мире часто используют утилитарно, для хранения логов, хорошо работает против кучи поступающих сообщений при фейле кластеризованного приложения, когда вал однотипных логов поуступает с нескольких серверов. Про MongoDB ничего плохого сказать не могу, кроме того, что она склонна полностью занимать доступную память. Сильно много с ними не работал, ничего конкретного не скажу.

Aber ★★★★★
()
Ответ на: комментарий от Aber

У монги проблемы начинаются на крупных базах.

fman2
()

Не увидел в требованиях, почему это не должна быть любая реляционная СУБД.

ThePretender
()
Последнее исправление: ThePretender (всего исправлений: 1)

Mongo вполне может подойти Хранение дерева - банально, через индексированные поля parent и parent_thread. Первое показывает на собственно родителя в дереве, второе - на заглавный пост дерева - по таковому, например, удобно быстро выгрести и отфильтровать все посты, когда разворачивается большое подмножество (можно сначала попробовать развернуть 2-3 уровня отдельными запросами, если получили много постов - выгребаем все id и parent'ы по parent_thread и дальше процессим уже их в нужный нам список id).

AlexAT
()

Berkley DB или dbf. или csv или lmdb...

mos ★★☆☆☆
()

JSON в PostgreSQL

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.