В какой?
https://www.youtube.com/watch?v=Fuac__g928E
🐴
🐴
вот тут чувак об этом говорит
🐴
примерно с 11 минуты
🐴
be one with the coupling
🐴
https://youtu.be/Fuac__g928E?t=740
TTT
ну в любом случае, я не смогу заставить сервисы использующие поле money не использовать его
🐴
ну в любом случае, я не смогу заставить сервисы использующие поле money не использовать его
вот вот там как раз об этом)
Denis
Denis
я только хотел написать то что ты как-то не так делаешь микросервисную архитектуру
TTT
Да тут вопрос в том, что я езжу на побитой лошади
TTT
Проекту 3 года. Начинал он как проект с функционалом одного текущего микросервиса
TTT
И все это время он разрабатывается, ибо заказчик постоянно меняет требования
TTT
или переделывать старое или делать новое)
TTT
Первоначально тут никакой архитектурой микросервисов и не пахло
TTT
Вводить я её начал только сейчас
TTT
Там даже параллельность не пахло в начале)
Denis
а зачем?
TTT
Затем что нагрузка планируется большая
Denis
задачи какие эта архитектура решать собиралась
Denis
ага
TTT
В первую очередь нагрузка на интернет соединение.
Во вторую очередь нагрузка на цп
Denis
ну
🐴
просто щас микросервисы - модно. и все используют это название, поэтому понятие размывается насколько, что становится бесполезным
🐴
как "аджайл". все аджайл. если ты не аджайл, на тебя будут пальцем показывать и девочки в классе засмеют
Denis
>нагрузка на цп
повытаскивай cpu intensive операции в микросервисы, задай очередь
Denis
у тебя же как я понимаю что-то считается определяется ещё до того как дернуть дб надо?
TTT
Ну я думаю ты понимаешь, что даже какой-то 64 ядерный сервак на последнем зеоне не выдержит нагрузки элементарно изза скорости интернет соединения, пользователи будут ждать ответа очень долго.
🐴
В первую очередь нагрузка на интернет соединение.
Во вторую очередь нагрузка на цп
нагрузка на сеть между сервисами?
TTT
у тебя же как я понимаю что-то считается определяется ещё до того как дернуть дб надо?
Очень много данных считается прямо в БД. Поэтому они и попадают в редис, а не дергаются напрямую
TTT
так же и с монго
TTT
так что редис тут как раз как слейв)
Denis
бизнес логика в бд?
TTT
Нет
TTT
Ну если вкратце, в БД считаются сумма которую просрал игрок, которую он выиграл в играх с другими пользователями, так же считается количество билетов, количество активных билетов, сколько вывел из системы, сколько пополнил
TTT
И НЕОЖИДАННО, эти данные нужны практически везде
🐴
TTT
А точно, ты предлагаешь из базы тащить все билеты, а потом считать их циклом?)
🐴
прям каноническая, дичайшая бизнес-логика
🐴
я ж говорю, я не знаю как правильно
TTT
Передавать овер 1 мб билетов вместо 64 бит)
TTT
интересній подход)
TTT
С каких пор использовать COUNT(1) запрещено в бд?
TTT
просвети)
🐴
тут такое дело
🐴
смотря в каком контексте
TTT
ну вот у меня задача, посчитать билеты
TTT
мне ничего не нужно кроме их числа
TTT
мне нужны для этого все билеты или их количество?
🐴
я так понимаю, если каунт используется для формирования отчетов для бухгалтерии - то все ок. а если эта сумма - часть доменной области, то ее хорошо бы выразить в бизнес-правиле на языке кода.
🐴
БД умные, велик соблазн нагрузить их тем, о чем они знать не должны
TTT
Если вкратце, это выглядит примерно так: req.body.countMoney - transfer_request.price / (user.tickets / 1000)
TTT
Обязан ли я для этого грузить все билеты в память ноды и считать их нодой?)
TTT
Вопрос риторический
🐴
Обязан ли я для этого грузить все билеты в память ноды и считать их нодой?)
откуда следует, что надо их грузить и считать КАЖДЫЙ раз?
Anonymous
Есть девопсы нормальные? Разрешите похантить. Пишу именно сюда, чтобы найти человека близкого к стеку команды.
TTT
Ты же понимаешь что скорость работы передачи 1 мб данных из БД будет в 1000 раз уже превышать скорость подсчета в БД и передачи числа?
TTT
Уже не говоря про подсчет и сохранение этого в кэше
TTT
А эти данные к примеру нужны при авторизации
TTT
Должен ли человек ждать даже пол секунды ради этого? Ответ нет
TTT
🐴
Ты же понимаешь что скорость работы передачи 1 мб данных из БД будет в 1000 раз уже превышать скорость подсчета в БД и передачи числа?
и... важное бизнес-правило утекло в бд
Anonymous
Чёт вы гоните. Оптимизация нужна тогда, когда она нужна. Если оптимизация не нужна, вся БЛ должна быть в приложении.
Anonymous
Чёт вы гоните. Оптимизация нужна тогда, когда она нужна. Если оптимизация не нужна, вся БЛ должна быть в приложении.
Если оптимизация нужна, эта необходимость должна быть обоснована соответствующей проблемой в производительности. Желательно, не гипотетической.
🐴
короче, делать правильно - сложно. делать правильно, когда уже сделано неправильно - дофига как сложно
Anonymous
И ваще, железо дешёвое же. Т.е. проблема должна быть огого какая.
🐴
Ты же понимаешь что скорость работы передачи 1 мб данных из БД будет в 1000 раз уже превышать скорость подсчета в БД и передачи числа?
я говорю о том, если сумма это доменная логика, то операция сложения должна быть выражена там же, где и остальные знания из доменной области. а когда все доменные модели написаны на js, а операция сложения неявно выражена как COUNT() в sql запросе, это признак протечки логики в бд
🐴
что может быть оправдано в каких-то ситуациях, но надо понимать последствия
TTT
Чёт вы гоните. Оптимизация нужна тогда, когда она нужна. Если оптимизация не нужна, вся БЛ должна быть в приложении.
Ну вот смотри. К примеру. Есть пользователь с миллионом билетов, вполне это может быть, ибо стоимость билета 0.02 цента.
За счет того что комиссия зависит от кол-ва купленных билетов, то пользователи могут использовать один и тот же аккаунт вместе.
Те билетов у одного пользователя вполне может быть и миллион.
Миллион билетов как долго будут передаваться базой? Думаю достаточно таки долго, а еще создаваться в ноде, ммм.
length получить не вариант, придется же считать активные и не активные, таким образом нужно будет пройтись по миллиону элементов массива и посчитать их в две переменные.
Почистить память от массива.
Где-то в процессе этого отправить запрос за остальными данными пользователя, ведь они необходимы для авторизации. Практически все данные отображаются на странице пользователя, на которую он переходит сразу же после авторизации.
Словить окончание промиса и добавить эти значения в обьект с пользователем.
И слава богу, наконец-то мы свободны от этого
TTT
И это только подсчет билетов
TTT
А теперь еще подсчет игр, которых может быть вообще нереально количество
TTT
возьмем то же КНБ
TTT
в него могут сыграть хрен знает сколько раз
TTT
Уже не говоря про другие игры
TTT
Нужно посчитать их количество, количество выигранных, количество проигранных, количество потраченных денег, количество выигранных денег, их сумму, те оборот, количество ничьих
TTT
Ну да, наверное так и нужно делать при авторизации
Anonymous
Ну вот смотри. К примеру. Есть пользователь с миллионом билетов, вполне это может быть, ибо стоимость билета 0.02 цента.
За счет того что комиссия зависит от кол-ва купленных билетов, то пользователи могут использовать один и тот же аккаунт вместе.
Те билетов у одного пользователя вполне может быть и миллион.
Миллион билетов как долго будут передаваться базой? Думаю достаточно таки долго, а еще создаваться в ноде, ммм.
length получить не вариант, придется же считать активные и не активные, таким образом нужно будет пройтись по миллиону элементов массива и посчитать их в две переменные.
Почистить память от массива.
Где-то в процессе этого отправить запрос за остальными данными пользователя, ведь они необходимы для авторизации. Практически все данные отображаются на странице пользователя, на которую он переходит сразу же после авторизации.
Словить окончание промиса и добавить эти значения в обьект с пользователем.
И слава богу, наконец-то мы свободны от этого
Сколько стоят риски падения сервиса из-за размазывания БЛ между СУБД и приложением? Дополнительно, сколько стоит время разработчика, необходимое на поиск бага и фикс? И сколько стоит железо, которое необходимо, чтобы покрыть просадку в производительности? Стоимость аренды дополнительного железа считай своим страховым взносом. Но БЛ не должна быть в БД.