Как стать автором
Обновить

Энтерпрайз-домино. 0x13 вредных советов для ниндзя-разработчика

Время на прочтение6 мин
Количество просмотров8.2K
Всего голосов 21: ↑21 и ↓0+21
Комментарии5

Комментарии 5

А как жить, если нужны prepared statements, но при этом session mode не вариант?
Пример: есть большое кол-во воркеров, которые берут задачу, открывают коннект к базе, длительное время выполняются, а затем коннект закрывают.
Непосредственно выполнение запросов к postgresql занимает малую часть времени, но на каждый запрос заново переоткрывать коннект так себе затея.
В случае session mode будет много коннектов к pgbouncer, которые переиспользовать не получится.
Например, в postgresql лимит 100 коннектов, в pgbouncer 10000. В session mode больше 100 задач одновременно не будут выполняться, если я правильно понял из документации pgbouncer, т.к. один коннект к pgbouncer мапится на один коннект к postgresql и они связаны на все время жизни воркера.
В случае transaction mode эти 100 коннектов будут распределены между всеми коннектами к pgbouncer.
Очень похоже, что хранимые процедуры будут наиболее оптимальным решением подобной задачи — репарсить большой текст запроса каждый раз не придется, а план запроса будет закэширован (с определенными допусками).

А интеграционные тесты на отключенных репликах ваши ниндзя по результатам blameless incident investigation не пишут, что ли?
Ну и еще канареечные релизы, вот-это-всё...

"классической трехзвенки:


клиент, он же браузер
сервер, он же бизнес-логика, он же БЛ
база, она же… база"


где-то меня здесь обманывают… Клиент в трехзвенке это не браузер, а слой отвечающий за взаимодействие с браузером или мобильным телефоном или десктоп приложения (АРМ) ещё чем-то. Сервер это не бизнеса логика, а сервер. Бизнес логика это такой же слой приложения как и клиентский слой.


Вчитайтесь в строчку из Википедии, которую Вы приложили, пожалуйста: Трёху́ровневая архитекту́ра (трёхзве́нная архитекту́ра, англ. three-tier) — архитектурная модель программного комплекса… ПРОГРММНОГО. Это не про железо.

Читаем определение:
Клиент (слой клиента) — это интерфейсный (обычно графический) компонент комплекса, предоставляемый конечному пользователю. Этот уровень не должен иметь прямых связей с базой данных (по требованиям безопасности и масштабируемости), быть нагруженным основной бизнес-логикой (по требованиям масштабируемости) и хранить состояние приложения (по требованиям надёжности). На этот уровень обычно выносится только простейшая бизнес-логика: интерфейс авторизации, алгоритмы шифрования, проверка вводимых значений на допустимость и соответствие формату, несложные операции с данными (сортировка, группировка, подсчёт значений), уже загруженными на терминал.

Сервер приложений (средний слой, связующий слой) располагается на втором уровне, на нём сосредоточена бо́льшая часть бизнес-логики. Вне его остаются только фрагменты, экспортируемые на клиента (терминалы), а также элементы логики, погруженные в базу данных (хранимые процедуры и триггеры).
Почему же «графический элемент комплекса» не может быть представлен браузером? Точнее, реализацией внутри него этой самой «простейшей бизнес-логики».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий