170 похожих чатов

Всем привет. У кого есть опыт разработки сервисов email рассылки.

Интересует вопрос организации БД, планировщика рассылок по кампаниям.

Есть таблицы:


subscribers (group_id | email | name)
subscribers_groups (id)
campaigns
campaigns_scheduled_overview (email | name | status | campaign_id | server_id | send_at | open_at | click_at | unsubscribe_at и т.д)


Сейчас так:

1. В рекламной кампании выбираю группу подписчиков для рассылки
2. Далее по группе подписчиков получаю получателей и добавляю в очередь на добавление в планировщик campaigns_scheduled_overview
3. Получатели добавляются в планировщик со статусом "Ожидает рассылки", далее уже работаю с таблицей campaigns_scheduled_overview (осуществляю выборку и рассылку писем

В чем вопрос: мне нужна полная стстистика по каждому получателю(ожидает, получил письмо, открыл, перешел по ссылке и т.д), на сколько так оптимально поступать (копировать получателей в промежуточную таблицу)?

Пункт 4. По идее я мог бы сразу брать получателей из таблицы subscribers, отправлять по ним письма и записывать информацию в таблицу статистики и потом ее уже обновлять,

но есть определенные НО:

1. Количество получателей больше млн.
2. Нужна очень быстрая выборка получателей, остановка рассылки, лимиты на отправку писем в СЕКУНДЫ, т.е дополнительные проверки, как следствие запросы в БД.

Вернемся к пункту 4. Если сразу брать данные из таблицы subscribers, отправлять информацию и записывать в таблицу статистики по каждой кампании,
то в случае проверки дополнительных условия (ограничение кол-ва отправок в секунды, минуты и т.д) выборка будет осуществляться из нескольких связанных таблиц, что по идее медленнее, чем из одной campaigns_scheduled_overview

При копировании получателей в промежуточную таблицу campaigns_scheduled_overview, выборки быстрые, но дублирование данных (получателей для каждой кампании), где компромисс? У кого есть опыт подобный? какие базы использовали и подходы?

2 ответов

19 просмотров

готовишь данные, складываешь в кеш (редис, например). Из кеша берёшь и обрабатываешь. Статисктику кладёшь в очередь, не стоит её обрабатывать сиюминутно. И из очереди потихоньку складируешь в основную бд

Aleksey- Автор вопроса
Anton Gordeev
готовишь данные, складываешь в кеш (редис, наприме...

По поводу кеша думал уже, но в итоге все равно получается так, что после рассылки 1 млн. писем для разных кампаний, у меня они все лягут либо в связанные таблицы(статистики) либо в одну таблицу campaigns_scheduled_overview о которой я писал выше. Т.е за счет кеша я получаю только быстрый доступ и проверки на момент отправки, но тогда получается, что при таком подходе, вполне можно использовать связанные таблицы

Похожие вопросы

Обсуждают сегодня

Господа, а что сейчас вообще с рынком труда на делфи происходит? Какова ситуация?
Rꙮman Yankꙮvsky
29
А вообще, что может смущать в самой Julia - бы сказал, что нет единого стандартного подхода по многим моментам, поэтому многое выглядит как "хаки" и произвол. Короче говоря, с...
Viktor G.
2
30500 за редактор? )
Владимир
47
а через ESC-код ?
Alexey Kulakov
29
Чёт не понял, я ж правильной функцией воспользовался чтобы вывести отладочную информацию? но что-то она не ловится
notme
18
У меня есть функция где происходит это: write_bit(buffer, 1); write_bit(buffer, 0); write_bit(buffer, 1); write_bit(buffer, 1); write_bit(buffer, 1); w...
~
14
Добрый день! Скажите пожалуйста, а какие программы вы бы рекомендовали написать для того, чтобы научиться управлять памятью? Можно написать динамический массив, можно связный ...
Филипп
7
Недавно Google Project Zero нашёл багу в SQLite с помощью LLM, о чём достаточно было шумно в определённых интернетах, которые сопровождались рассказами, что скоро всех "ибешни...
Alex Sherbakov
5
Ребят в СИ можно реализовать ООП?
Николай
33
https://github.com/erlang/otp/blob/OTP-27.1/lib/kernel/src/logger_h_common.erl#L174 https://github.com/erlang/otp/blob/OTP-27.1/lib/kernel/src/logger_olp.erl#L76 15 лет назад...
Maksim Lapshin
20
Карта сайта