В распределенных системах вообще нет синхронного в классическом понимании этого слова (есть синхронные и асинхронные процессы, но это немного другое).

Да и вообще, не факт, что синхронная и асинхронная репликация — общепринятые понятия (могут означать разное в разных СУБД). О какой речь?

#вакансия #разработчик #базаданных #бд #москва #удаленно
Разработчик Баз Данных
Компания: Ланит
Формат: Офис в мск или удаленно
Зарплата: обсуждаем оклад до 300 тысяч рублей.

Задачи:
➖Повышение качества разработки в части БД (как техническими изменениями, так и организационными);
➖Поддержка и разработка ETL-процедур
➖Разработка серверной части БД, проектирование решений
➖Оптимизация работы БД (секционирование, архивы, рефакторинг кода, физмодели и т.д);

Ожидания:
➖Опыт разработки базы данных (Postgres-based)
➖Навыки проектирования и оптимизации структуры БД с учетом выбранного профиля нагрузки (OLAP/OLTP), создание объектов БД
➖Написание хранимых процедур, функций, пакетов на PL/SQL, PL/pgSQL для формирования аналитических отчетов
➖Разработка хранилищ данных
➖Опыт администрирования СУБД

Условия:
➖Вознаграждение в виде оклада, готовы обсуждать до 300 тысяч
➖Гибкий график
➖Удаленно или офис в Москве
➖Социальный пакет (медицинская страховка, корпоративные скидки на посещение фитнес-центра)
➖Обучение приветствуется и стимулируется: необходимое обучение оплачивается, сертификация поощряется премиями по результатам сдачи экзаменов

Контакт для связи: @IskraDem

Приветствую. Какие есть варианты реализации системы подсчета не просмотренных сообщений в групповых чатах при нагрузках равнозначных телеграму?

Есть следующие варианты:

1. Вести учет просмотренных сообщений сообщений для каждого пользователя. Создавать запись в таблице message_views, указывая id пользователя и id сообщения, а при необходимости узнать кол-во непрочитанных, проверять, для скольких сообщений чата не записей в message_views. Огроаный недостаток - слишком долгая операция. Если нужно посчитать, к примеру, 1000000 непрочитанных сообщений. 1000000 - приблизительно, максимальное количество сообщений для чата, которое хранит телеграм. Так же и другие варианты с подсчетом кол-ва непрочитанных сообщений, в которых надо использовать COUNT(*)
2. Хранить в отдельном поле кол-во непрочитанных сообщений для каждого участника чата. После отправки сообщения, делать инкремент для каждого пользователя. Недостатки: если, к примеру, есть группа в которой 200 тыс. пользователей, то обновление счетчика для всех пользователей - слишком дорогая операция, но можно обновлять счетчик в несколько итераций, к примеру, для 3-5 тыс. участников за раз.

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

Ребят, привет. Кто может подсказать: (MSSQL)

Если смотреть второй вариант, то это получается для каждого чата надо новое поле инкремента? Мне кажется надо новую таблицу где будет id пользователя, id чата и id последнего прочитанного сообщения. В момент входа в чат, создавать запись с максимальным сообщением на этот момент. В момент прочитывания сообщения выполнять update по тем id которое прочитано.

Зачем вообще делать апдейты по сообщениям? Изначально ставьте гарантией, что чат - это список сообщений, у каждого из которых есть индекс, для чата запоминаете индекс последнего сообщения (это и так автоматом будет необходимо), для пользователя - идентификатор чата и индекс последнего прочитанного сообщения, количество непрочитанных сообщений есть разница между ними, никаких комбинаторных взрывов и обновления данных всех участников на каждое сообщение.

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

Допустим, у чата всего 1000 сообщений. Пользователь удалил сообщение с индексом 900. Последнее сообщение чата имеет индекс 1000, хоть по факту в чате осталось 999 сообщений. Допустим, у пользователя последнее прочитанное сообщение с индексом 1000  - 800 = 200, но по факту, непрочитанных сообщений 199

По факту непрочитанных сообщений все равно двести, просто одно он никогда не сможет прочитать 😏😏😏

Вам точно нужна эта точность? И добавление "здесь было Х удаленных сообщений" не решит проблему?

Коварный чат))

Нужна

Ну делайте тогда те же индексы, но вместо простой разницы впустую нагружайте машины COUNT(*) WHERE index BETWEEN (:last_seen, :current) AND status != 'deleted', чего

Мне подсказали другое решение. Делать count(*) 1001, и на клиенте отображать "1000+", если их больше 1000

Посчитать 1000 сообщений быстро

что является вариацией "нам наплевать на реальную точность и разница в пару сообщений никого не волнует"

Ну да)

тогда уж 999+

Только в отличии от вашего варианта, тут сохраняется согласованность

Можно и так)