Главная задача сделать оптимальную структуру. Так же не забывать про масштабируемость.
Дано:
* User - просто user
* Заказ - Сушность.
** field_date (куда будет прописываться время завершения хостинга).
** field_tarif - связка с тарифом
* Тариф - В неё записана стоимость.
Думалось мне всё это сделать на нодах, но терзают смутные сомнения.
Так же надо оповещать юзера о завершении тарифа "30, 15, 5 дней" (по полю field_date). Будет ли тут оптимален rules? Cron custom module?
Прикреплю схему для наглядности:
Ответы
Оптимально все писать в одну сущность. Пользователь будет отдельно (референс по UID), все остальное - свойства сущности, не поля (чтоб в 1 табличке). С другой стороны - не понимаю как там со связностью данных, это надо задачку целиком смотреть - могут быть нюансы которые все ломают, тут удаленно ответ не дать. Это первая мысль к вопросу о нагрузке.
Вторая мысль - биллинговые операции, особенно про хостинг, это совсем не история highload. Если у вас 20 000 пользователей - это довольно мало по нагрузке на расчеты/запросы, но до такой цифры малореально дорасти просто по рынку. Т.е. можно делать как удобно и не думать о нагрузке.
А оповещения посылать через кастом модуль по крону? Тут какие мысли? Это каждые 6 часов проверять ~1000+ нод с полями датами.
да, это немного, он обойдет все за минуту-другую на слабой машинке, даже если будет куча inner join и все по разным полям набросано. Формируй очередь и запускай разбор через ultimate_cron, чтоб для порядка, не уткнуться в php таймаут.
Это, в общем не история "нагрузки", это так, пшик)
какая минута?) mysql запрос любой сложности по тысяче нод замёт микросекунду)
Ну надо же ещё письмицо отправить)