небольшая поправка.
вам нет смысла выносить наружу контейнера порты 3306
ports:
- "3306:3306"
лучше всего настроить
networks:
- mysql
на самом деле достаточно только 80/443 порта , которые смотрят наружу, далее только через нетворкс, это и в разы быстрее, ибо через внутренние сокеты, и даже если на 80 порту ломанут nginx/апач злоумышленник не сможет получить доступ к базе.
7 параметров. половина как-то воздействуют на всех.
например. сущность в каком то статусе. если это статус < 3, то можно рассчитать коэфициент. но если статус 5 6 или 7, то это рассчитывать не нужно. но если у нас меняется, например, привязка сущности к категории, то надо рассчитать для этой и для новой категории. так же стоит учесть переход из одного статуса в другой. и сверху прибиваем привязками к пользователям
согласен. помню себя на его месте. я без практики никак не мог разобраться в больших опенсорсах, понимать их контекст и одновременно мыслить в паттернах.
Господа, разрешите уточню. Не я постановщик задачи. Передо мной задача посчитать эффективность. Решение принимать уже руководству. А им пока нужна цифра какая-то ) вот я и ищу как ее получить, цифру эту
Я лишь программист )
ThunderCat, про вынос согласен. но и такие объемы в теории не есть хорошо переносить да и просто дублировать в отдельных таблицах. ибо все данные уже есть в одной общей. (в одном лишь счетчике считается с привлечением иннер джоина и лефтджоина)
в данный момент пришел к тому. что
1. пересчитываю все счетчики всех пользователей, которые участвуют в задаче
2. раз в 15 минут пересчет всех счетчиков, которые по дедлайну.
Lander, раньше, до меня была инкрементная система. на удивление, оооочень часто случались моменты, когда рассинхрон происходил.
я переделал на пересобирать счетчики запросом на хите и кешировать
и опять идет какой то рассинхрон, хотя его можно раз в пару часов синхронизировать.
но в эту схему не ложится уже по группам. это +11 сложных запросов получается.
Смотрите, есть клиенты, у которых 2 тыс пользователей и порядка 100 тыс задач. 5 типов счетчиков.
+ возможность делать срез по группе задач.
итого представьте как мне пересчитывать каждый час два эти 100тыс задач и писать данные на 2 тыс пользователей.
вообще я понимаю, что пытаюсь из бутылки сделать ракету и улететь домой на марс... но все же надеюсь на какое то нестандартное решение.
вам нет смысла выносить наружу контейнера порты 3306
ports:
- "3306:3306"
лучше всего настроить
networks:
- mysql
на самом деле достаточно только 80/443 порта , которые смотрят наружу, далее только через нетворкс, это и в разы быстрее, ибо через внутренние сокеты, и даже если на 80 порту ломанут nginx/апач злоумышленник не сможет получить доступ к базе.