|
Оптимальный движок хранения сообщений форума - ?
|
|||
---|---|---|---|
#18+
По сути нужен движок, оптимизированный под хранение «очередей». Топик/чат/дискуссия - это всегда очередь/list/vector. Элементы часто тупо не удаляются, а помечаются «deleted». Не хочется ваять традиционную табличку в реляционке, где есть: (это абстрактный псевдо-SQL) Код: plsql 1. 2. 3. 4. 5.
куда потом пойдут селекты вида: Код: plsql 1.
Хочется чего-то проще, менее общего назначения, более специфичное. Пускай не SQL - пофиг вообще. 1. Топик/тред - всегда последовательность событий (древовидные не смотрим пока). Это должно «осознаваться» самим движком, а не приложением: движок должен понимать что он добавляет событие В КОНЕЦ очереди и присваивать ему нужные для этого атрибуты сам (номер в последовательности, например). Конечно традиционный автоинкремент имеет то преимущество, что можно дропнуть строку и значения автоинкрементных полей сохранятся какие были, а не съедут назад на 1, но мы не будем в нашем движке ничего дропать. 2. В списке тредов часто делают авто-всплытие свежих тредов наверх. Пускай наш движок хранения очередей тупо имеет timestamp пополнения каждой из очередей и мы это можем (а можем и НЕ) использовать для этих целей. 3. Как хранят древовидные системы срачевания (комментирования) - вообще слабо представляю, по-моему никак; это всегда тяжело и ненужно; в нормальных заведениях рубят уровень комментирования очень рано, на ютубе например лесенка вообще только до 2 уровня идёт. Короче, какие системы для реализации форумов/комментариев в виде такого вот "хранения очередей" существуют? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.05.2017, 20:24 |
|
Оптимальный движок хранения сообщений форума - ?
|
|||
---|---|---|---|
#18+
Vocoder_51. Топик/тред - всегда последовательность событий (древовидные не смотрим пока). Это должно «осознаваться» самим движком, а не приложением: движок должен понимать что он добавляет событие В КОНЕЦ очереди и присваивать ему нужные для этого атрибуты сам (номер в последовательности, например). обычная реляционная таблица Vocoder_52. В списке тредов часто делают авто-всплытие свежих тредов наверх. Пускай наш движок хранения очередей тупо имеет timestamp пополнения каждой из очередей и мы это можем (а можем и НЕ) использовать для этих целей.timestamp поле в обычной реляционной таблице Vocoder_53. Как хранят древовидные системы срачевания (комментирования) - вообще слабо представляю, по-моему никакразличных многоуровневых каталогов на реляционных субд создано до... (много короче). вариантов хранения деревьев значительно больше одного. Vocoder_5Хочется чего-то проще, менее общего назначения, более специфичное.обосновать хотение сможете? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.05.2017, 23:11 |
|
Оптимальный движок хранения сообщений форума - ?
|
|||
---|---|---|---|
#18+
Vocoder_5, хм, мы храним в традиционной табличке в реляционке и проблем не испытываем, в том числе с "древовидной системой срачевания (комментирования)". ... |
|||
:
Нравится:
Не нравится:
|
|||
29.05.2017, 09:52 |
|
Оптимальный движок хранения сообщений форума - ?
|
|||
---|---|---|---|
#18+
Vocoder_5, и требования к "движку" у Вас слабенькие. Где хранить вставленные в тело картинки и документы, где хранить вложения, какие ограничения для них должны выполняться? Как обеспечить безопасность, простоту модерирования, защитить пользователя от спама? Как реализовать быстрый полнотекстовый поиск и поиск по тагам, разделам, категориям? ... |
|||
:
Нравится:
Не нравится:
|
|||
29.05.2017, 09:59 |
|
Оптимальный движок хранения сообщений форума - ?
|
|||
---|---|---|---|
#18+
skyANAVocoder_5, и требования к "движку" у Вас слабенькие. Где хранить вставленные в тело картинки и документы, где хранить вложения, какие ограничения для них должны выполняться? Как обеспечить безопасность, простоту модерирования, защитить пользователя от спама? Как реализовать быстрый полнотекстовый поиск и поиск по тагам, разделам, категориям? Это всё реализуется на уровне приложения, юзающего базу. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.05.2017, 13:25 |
|
Оптимальный движок хранения сообщений форума - ?
|
|||
---|---|---|---|
#18+
ДедушкаVocoder_51. Топик/тред - всегда последовательность событий (древовидные не смотрим пока). Это должно «осознаваться» самим движком, а не приложением: движок должен понимать что он добавляет событие В КОНЕЦ очереди и присваивать ему нужные для этого атрибуты сам (номер в последовательности, например). обычная реляционная таблица Vocoder_52. В списке тредов часто делают авто-всплытие свежих тредов наверх. Пускай наш движок хранения очередей тупо имеет timestamp пополнения каждой из очередей и мы это можем (а можем и НЕ) использовать для этих целей.timestamp поле в обычной реляционной таблице Vocoder_53. Как хранят древовидные системы срачевания (комментирования) - вообще слабо представляю, по-моему никакразличных многоуровневых каталогов на реляционных субд создано до... (много короче). вариантов хранения деревьев значительно больше одного. Vocoder_5Хочется чего-то проще, менее общего назначения, более специфичное.обосновать хотение сможете? Обосновать хотение просто: узкоспециальное решение всегда менее ресурсоёмко (быстрее и меньше жрёт памяти), чем использование системы общего назначения. Например, хранение последовательности постов как последовательности строк в реляционной табличке вовлекает необходимость иметь, апдейтить индекс. Конечно вставка записи (которая в порядке сортировки старше всех) в "конец" b-tree - это дёшево, это append-only. Но мне не нужен индекс. Мне нужен плоский массив, умеющий индексировать по порядковому номеру. Да, индекс это умеет, но индекс - немного оверкилл. Мне например не нужна поддержка удалений, вставок в середину и т.п. Соответственно, структура данных B-tree излишняя, можно сэкономить на всех блоках дерева выше листовых. Получаем цепочку блоков. Достаточно SSTable от гугла. Потенциально мне не нужна и реляционка, точнее модель при которой база знает что внутри записи. Т.е. мне не надо, чтобы база знала структуру записи и умела WHERE - мне не нужны колонки в таблице. Пускай база хранит линейную последовательность массивов байт и даёт мне массив байт по индексу. Пускай база знает какая из таких цепочек в какой timestamp обновилась. Далее моё приложение будет десериализовывать массив байтов в структуру типа "пост". Серверов приложений несколько, а база одна, решает свою маленькую задачку, зато очень быстро. Дальше сервера приложений пусть десериализуют и думают что делать с этой записью. В юз-кейсе отображения сообщений поста мы как правило просто выводим последовательность сообщений, редко нужно пропустить помеченные удалёнными. Для базы это линейное чтение, streaming, что супербыстро. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.05.2017, 13:35 |
|
Оптимальный движок хранения сообщений форума - ?
|
|||
---|---|---|---|
#18+
Vocoder_5skyANAVocoder_5, и требования к "движку" у Вас слабенькие. Где хранить вставленные в тело картинки и документы, где хранить вложения, какие ограничения для них должны выполняться? Как обеспечить безопасность, простоту модерирования, защитить пользователя от спама? Как реализовать быстрый полнотекстовый поиск и поиск по тагам, разделам, категориям? Это всё реализуется на уровне приложения, юзающего базу. Отлично. А можете рассказать, как полнотекстовый поиск реализуется на уровне приложения? ... |
|||
:
Нравится:
Не нравится:
|
|||
29.05.2017, 13:49 |
|
Оптимальный движок хранения сообщений форума - ?
|
|||
---|---|---|---|
#18+
skyANAVocoder_5пропущено... Это всё реализуется на уровне приложения, юзающего базу. Отлично. А можете рассказать, как полнотекстовый поиск реализуется на уровне приложения? Да господи, точно так же как написано внутри какого-нибудь elasticsearch. Пишем код, который работает во внешнем по отношению к базе "микросервисе", получает поток новых сообщений и строит свой инвертированный индекс или какой там надо. В общем, к самой "хранилке" (базе) это может отношения не иметь, заменяться, апгрейдиться, шардироваться и т.п. не трогая базу. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.05.2017, 13:55 |
|
Оптимальный движок хранения сообщений форума - ?
|
|||
---|---|---|---|
#18+
Vocoder_5, ну таким образом и весь движок можно построить: микросервис для хранения, микросервис для поиска :) ... |
|||
:
Нравится:
Не нравится:
|
|||
29.05.2017, 15:01 |
|
Оптимальный движок хранения сообщений форума - ?
|
|||
---|---|---|---|
#18+
Вот только не понятно, почему для хранения ищется что-то готовое, а для поиска как-нибудь сами напишем. Пишите и хранения сами, в чём проблема? :) ... |
|||
:
Нравится:
Не нравится:
|
|||
29.05.2017, 15:04 |
|
Оптимальный движок хранения сообщений форума - ?
|
|||
---|---|---|---|
#18+
skyANAВот только не понятно, почему для хранения ищется что-то готовое, а для поиска как-нибудь сами напишем. Пишите и хранения сами, в чём проблема? :) Выделенное жирным - ложно. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.05.2017, 16:00 |
|
Оптимальный движок хранения сообщений форума - ?
|
|||
---|---|---|---|
#18+
Vocoder_5skyANAВот только не понятно, почему для хранения ищется что-то готовое, а для поиска как-нибудь сами напишем. Пишите и хранения сами, в чём проблема? :) Выделенное жирным - ложно. Хорошо, тогда поясните следующее: Vocoder_5Пишем код, который работает во внешнем по отношению к базе "микросервисе", получает поток новых сообщений и строит свой инвертированный индекс или какой там надо. Это разве не означает, что Вы планируете написать полнотекстовый поиск как-нибудь самостоятельно? ... |
|||
:
Нравится:
Не нравится:
|
|||
29.05.2017, 18:01 |
|
Оптимальный движок хранения сообщений форума - ?
|
|||
---|---|---|---|
#18+
skyANAVocoder_5пропущено... Выделенное жирным - ложно. Хорошо, тогда поясните следующее: Vocoder_5Пишем код, который работает во внешнем по отношению к базе "микросервисе", получает поток новых сообщений и строит свой инвертированный индекс или какой там надо. Это разве не означает, что Вы планируете написать полнотекстовый поиск как-нибудь самостоятельно? Не означает. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.05.2017, 18:31 |
|
Оптимальный движок хранения сообщений форума - ?
|
|||
---|---|---|---|
#18+
И вообще, что мы там планируем или нет - наша забота, вопрос был не "проконсультируйте нас, как нам лучше поступить и оцените наши намерения". Вопрос был о существующих системах хранения очередей. О том, как мессенджеры хранят мессаги, когда хранят их не в реляционках. Помню вконтактик вываливал на хабр рекламу своего репозитория, где куча всяких демонов на С написана, каждый под свою мелкую задачку. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.05.2017, 18:32 |
|
Оптимальный движок хранения сообщений форума - ?
|
|||
---|---|---|---|
#18+
А причем тут очереди? Разве "мессаги" (в контексте "личные сообщения", я так понимаю) - это очередь? Берет любую удобную Вам СУБД, делаете таблиу/схему/коллекцию: id, user_id, created_at, text Создаете индексы какие надо (прямые, обратные, какие будут необходимы) и используете. Если нужен шардинг, конечно лучше брать решения которые умеют делать это с коробки. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.05.2017, 18:58 |
|
Оптимальный движок хранения сообщений форума - ?
|
|||
---|---|---|---|
#18+
Vocoder_5, форум - это не очередь, а список, или дерево ... |
|||
:
Нравится:
Не нравится:
|
|||
29.05.2017, 21:41 |
|
Оптимальный движок хранения сообщений форума - ?
|
|||
---|---|---|---|
#18+
HettА причем тут очереди? Разве "мессаги" (в контексте "личные сообщения", я так понимаю) - это очередь? Берет любую удобную Вам СУБД, делаете таблиу/схему/коллекцию: id, user_id, created_at, text Создаете индексы какие надо (прямые, обратные, какие будут необходимы) и используете. Если нужен шардинг, конечно лучше брать решения которые умеют делать это с коробки. Да, мессаги - это очередь. Например этот топик - небольшая очередь с началом. События (сообщения) добавляются только в конец этой очереди и имеют некоторые атрибуты (автор, мессага, аватарка, время). В общем, табличка вами описанная - это взять средство общего назначения и реализовать на нём очередь, где путём фичи "автоинкремент" и добавления этого автоинкрементного поля в индекс реализуется свойство очереди "адресация по индексу". А хочется прямо узко-специальное решение для таких очередей. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.05.2017, 22:47 |
|
Оптимальный движок хранения сообщений форума - ?
|
|||
---|---|---|---|
#18+
Список, добавление в который происходит только в конец - является очередью. То, что из начала этой очереди ничего не достаётся - частный случай. То, что очередь просматривается целиком и ничего не удаляется у неё с начала - частный случай. Теоретически можно и удалять сообщения из начала, теряя начало топика, если он слишком разрастётся и будет ценна не его целостность, а некий последний контекст (топик вырожден в чатик). Ну да неважно, мыслите про список - суть не изменится. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.05.2017, 22:49 |
|
Оптимальный движок хранения сообщений форума - ?
|
|||
---|---|---|---|
#18+
Vocoder_5, следуя Вашей логике, чем Вам таблица не очередь? ... |
|||
:
Нравится:
Не нравится:
|
|||
29.05.2017, 23:45 |
|
Оптимальный движок хранения сообщений форума - ?
|
|||
---|---|---|---|
#18+
В очереди и стеке можно посмотреть "безболезненно" только первый/последний (соответственно) элемент. Чтобы получить доступ к следующему, первый придется изъять (dequeue), изъятие из очереди приводит к удалению элемента. Дальше развивать мысль, почему очереди не подходят для вашей задачи? ... |
|||
:
Нравится:
Не нравится:
|
|||
30.05.2017, 06:25 |
|
Оптимальный движок хранения сообщений форума - ?
|
|||
---|---|---|---|
#18+
Чтобы доставить сообщение до пользователя Вы, конечно, можете использовать MQ сервисы, но не для хранения. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.05.2017, 06:27 |
|
Оптимальный движок хранения сообщений форума - ?
|
|||
---|---|---|---|
#18+
skyANAVocoder_5, следуя Вашей логике, чем Вам таблица не очередь? Вполне себе очередь. Просто не хочется тратиться на поддержку B+-tree индекса. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.05.2017, 13:45 |
|
Оптимальный движок хранения сообщений форума - ?
|
|||
---|---|---|---|
#18+
HettВ очереди и стеке можно посмотреть "безболезненно" только первый/последний (соответственно) элемент. Чтобы получить доступ к следующему, первый придется изъять (dequeue), изъятие из очереди приводит к удалению элемента. Дальше развивать мысль, почему очереди не подходят для вашей задачи? Это частный случай очереди. В моём понимании определение очереди может быть шире. На каких условиях возможен просмотр того, что лежит в очереди - это частности. Главное в очереди - сохранение последовательности. Из простого правила "сохранение последовательности" вытекают особенности операций типа pop и push. Удаляя как-то иначе, чем самое старое или новое мы нарушаем это правило. Да, в моём расширенном определении очереди возможно удаление только что добавленного, это я бы назвал "отмена добавления", что допустимо. Короче не суть, это срачь не по сабжу, это академическая тема. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.05.2017, 13:48 |
|
Оптимальный движок хранения сообщений форума - ?
|
|||
---|---|---|---|
#18+
Vocoder_5skyANAVocoder_5, следуя Вашей логике, чем Вам таблица не очередь? Вполне себе очередь. Просто не хочется тратиться на поддержку B+-tree индекса. Дак не создавайте его. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.05.2017, 14:46 |
|
Оптимальный движок хранения сообщений форума - ?
|
|||
---|---|---|---|
#18+
skyANAVocoder_5пропущено... Вполне себе очередь. Просто не хочется тратиться на поддержку B+-tree индекса. Дак не создавайте его. Но хочется быстро выгребать сообщения, относящиеся к одному топику и следующие в порядке возрастания message id. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.05.2017, 15:15 |
|
|
start [/forum/topic.php?fid=48&msg=39462287&tid=1856688]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
167ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
62ms |
get tp. blocked users: |
1ms |
others: | 239ms |
total: | 515ms |
0 / 0 |