У вас картинки маленькие и некликабельные. Не разобрать.
А если бы через консоль все настройки делались, ошибок бы не было, правильно?
Тут только вопрос качества проработки интерфейса?
А как жить, если нужны prepared statements, но при этом session mode не вариант?
Пример: есть большое кол-во воркеров, которые берут задачу, открывают коннект к базе, длительное время выполняются, а затем коннект закрывают.
Непосредственно выполнение запросов к postgresql занимает малую часть времени, но на каждый запрос заново переоткрывать коннект так себе затея.
В случае session mode будет много коннектов к pgbouncer, которые переиспользовать не получится.
Например, в postgresql лимит 100 коннектов, в pgbouncer 10000. В session mode больше 100 задач одновременно не будут выполняться, если я правильно понял из документации pgbouncer, т.к. один коннект к pgbouncer мапится на один коннект к postgresql и они связаны на все время жизни воркера.
В случае transaction mode эти 100 коннектов будут распределены между всеми коннектами к pgbouncer.
А чем плохо отключение JS? Понятно, что fingerprinting тут вас сразу рассекретит, т.к. почти никто JS не выключает. С другой стороны, если есть задача скрываться, то с отключенным JS, за VPN другой страны, с отдельным браузером специально для подобного серфинга, где вы не используете свои личные аккаунты и включаете JS только для нужных сайтов, чем плох такой подход?
В multi-tenant db (db per client) это позволит анализировать нагрузку отдельно по каждой базе?
Например, найти какие клиенты создают наибольшую нагрузку.
Возможно, глупый вопрос.
Предположим, сервис меняет данные в БД.
Есть два варианта:
1. Сервис принимает модель объекта (которую из get_object() во view получили) и ее меняет. Попутно меняются данные в связанных записях. Ненадежно даже в рамках транзакции, т.к. при приеме двух идентичных запросов есть риск дублирования.
2. Сервис принимает id объекта, делает select_for_update() для надежности. Таким образом избегаем ошибок с дублями запросов. Но это доп. запрос уже после того, как get_object() объект вернул. Проще говоря, лучше бы просто id объекта сразу получить во view, но там могут быть проверки permissions, которые на конкретный объект завязаны.
Какой из подходов можно считать общепринятым в django/drf?
А данные о location поезда возможно сфальфицировать? Как они диспетчеру передаются? Может ли он увидеть поезд не там, где тот находится, а за 10 км до того местаб например, и на основе этого решение принять о переключении стрелок?
Т.е. он не использовал некие недокументированные API?
Можно раскрыть подробнее про "позволяло пользователям быстро и просто указать детали поездки, чтобы вставить их на веб-сайт IRCTC"?
Подскажите, а новые версии приложения раскатывать, это совсем не про terraform?
Правильно понимаю, что нужно сделать AMI, который готов, скажем, делать docker pull при помощи CI/CD системы? И далее он просто живет и Jenkins туда катит новые версии.
Или есть способы, при которых можно через terraform apply раскатывать новые версии приложения?
Можно пример исключений? Может исключения пока что есть, но все равно утекут?
А если бы через консоль все настройки делались, ошибок бы не было, правильно?
Тут только вопрос качества проработки интерфейса?
Пример: есть большое кол-во воркеров, которые берут задачу, открывают коннект к базе, длительное время выполняются, а затем коннект закрывают.
Непосредственно выполнение запросов к postgresql занимает малую часть времени, но на каждый запрос заново переоткрывать коннект так себе затея.
В случае session mode будет много коннектов к pgbouncer, которые переиспользовать не получится.
Например, в postgresql лимит 100 коннектов, в pgbouncer 10000. В session mode больше 100 задач одновременно не будут выполняться, если я правильно понял из документации pgbouncer, т.к. один коннект к pgbouncer мапится на один коннект к postgresql и они связаны на все время жизни воркера.
В случае transaction mode эти 100 коннектов будут распределены между всеми коннектами к pgbouncer.
Например, найти какие клиенты создают наибольшую нагрузку.
Предположим, сервис меняет данные в БД.
Есть два варианта:
1. Сервис принимает модель объекта (которую из get_object() во view получили) и ее меняет. Попутно меняются данные в связанных записях. Ненадежно даже в рамках транзакции, т.к. при приеме двух идентичных запросов есть риск дублирования.
2. Сервис принимает id объекта, делает select_for_update() для надежности. Таким образом избегаем ошибок с дублями запросов. Но это доп. запрос уже после того, как get_object() объект вернул. Проще говоря, лучше бы просто id объекта сразу получить во view, но там могут быть проверки permissions, которые на конкретный объект завязаны.
Какой из подходов можно считать общепринятым в django/drf?
Концептуальная проблема с plain text password, а не с Sequelize.
Так эти коллеги его и слили?
И каким образом он "украл" сертификаты? Он имел доступ к базе с кодами активации из сертификатов?
Т.е. он не использовал некие недокументированные API?
Можно раскрыть подробнее про "позволяло пользователям быстро и просто указать детали поездки, чтобы вставить их на веб-сайт IRCTC"?
Что значит "начала разрушаться"? Работала, но не совсем?
Подскажите, а новые версии приложения раскатывать, это совсем не про terraform?
Правильно понимаю, что нужно сделать AMI, который готов, скажем, делать docker pull при помощи CI/CD системы? И далее он просто живет и Jenkins туда катит новые версии.
Или есть способы, при которых можно через terraform apply раскатывать новые версии приложения?