:-) Ну как бы "производительность БД" "по факту" не интересна никому... Всех "по факту" интересует "производительность прикладного приложения". Да есть связи между ними, но они "совсем не простые"... :-) К примеру БД нагружается (выразимся так) "различными прикладными задачами". И у прикладных "задач" есть различные "требования" по времени ответа (от БД в том числе). Если в БД нет "встроенных" средств "приотеризации" - это уже "не есть хорошо". Вот и получаем ситуацию когда один (для приложения не приоритетный) запрос в БД (который БД обрабатывает как бы быстро и оптимально) "убивает" производительность других приоритетных для приложения запросов. Для PG это достаточно актуально.
:-) Мой "стандартный" вопрос к разработчику: - Ты почему сделал так как сделал? Наверное ты понимаешь что у тебя был выбор из нескольких вариантов реализации? Вот такой, такой и такой. Так почему ты выбрал именно то как реализовал? Ответ хорошего/правильного разработчика: - Да рассматривал их все, но выбранный по сумме (перечисляет) критериев на мой взгляд наиболее оптимальный/эффективный (краткое описание причин выбора) . Наиболее частые ответы "плохого" разработчика: - Мне так просто захотелось и было проще, т.к. они же все решают поставленную задачу. - Мне так сказали (руководство). - А разве можно было "по другому"? - Я услышал про новую/перспективную технологию и решил попробовать ее использовать.
:-) История... Работаю в компании более 25 лет (с основания). "Прошел" различные "направления"/департаменты - разработка, поддержка и внедрение (у клиентов), ПМ, тестирование. "Воспитал" и обучил множество сотрудников (несколько сейчас на ключевых руководящих постах). В основном всегда быстро и эффективно решал "нестандартные и проблемные задачи" которые "непонятно как решать". Регулярно получал предложения "сменить" компанию/страну и т.п., но по различным причинам не менял. После 5 лет работы начал в своей компании регулярно получать "предложения поруководить каким либо направлением". Типовой диалог переговоров - - Ты у нас очень хороший специалист. А давай ты поруководишь <.....> - Ну вы же понимаете что у меня есть свои условия? - А какие? - Задачи и сроки их исполнения для подразделения ставятся мне. Ответственность за выполнение несу только я. Мои подчиненные будут исполнять только мои указания. Общий фонд оплаты полученный за выполненную работу между сотрудниками делю по своему усмотрению. И еще у меня недостаток есть - я врать не люблю, не умею и учиться этому не собираюсь. Вас это устроит? - Спасибо мы подумаем.... А вот есть проблема с <....> может сможешь решить ее? :-) Ну вот как то так... Моя "дурная привычка" называть вещи своими именами и "не любовь" к бюрократии, не нравится руководству, платят конечно нормально (мне хватает, хотя "по рынку" могу получать в два раза больше), но и решаю я задачи которые "мне интересны"....
:-) Ну видимо автор статьи мягко говоря "не очень в курсе" про различия в архитектуре mainframe и современных платформ.... Про "легкую смену языка" прикладного ПО ему уже написали... Плюс к этому "добавляется" "легкая смена БД" для хранения данных... :-)
Про выводы. В принципе ок - не считая 1. Именно из за первого вы имели отказы... Потому как проектируя и разрабатывая такую прикладную систему и не предусмотреть "connection storm" (от устройств) - нужно "постараться".... Ну а про "vendor lock" говорить представителям SberDevices - должно быть просто стыдно... :-)
:-) С автором статьи во многом согласен... Особенно в части - если производительности одной БД для вашего прикладного ПО с учетом масштабирования и развития достаточно - микросервисы вам точно не нужны.... Но если у вас нет общего понимания (на ближайшие 10 лет) как будет масштабироваться и развиваться ваш программный продукт - проблема не в архитектуре, а в архитекторе...
Плюсую... :-) - Давай сейчас проработаем наиболее перспективные и возможные в будущем варианты развития продукта? -- Зачем? Согласно постановки задачи архитектура выбрана оптимальна, а проработка возможных перспектив развития сейчас это + месяц аналитики (для 1 аналитика). А сроки "горят"! Пора программировать! <прошло 3 года> - Тут нужно добавить небольшую и востребованную функциональность к уже существующей в продукте, какие примерно сроки разработки? -- Ну, учитывая что это "не ложится" на базовую архитектуру приложения, не меньше чем полгода работы (для 3 аналитиков и 15 разработчиков)....
По факту, проще "щардировать" прикладную систему "в целом" (а не одну БД). Практические примеры - международные платежные системы. Больше общей "устойчивости" и масштабируемости...
Т.е. тупо обеспечить заявленную функциональность они не могут (без дополнительных "телодвижений" с моей стоны)? И это "хороший сервис"? С учетом что с моей стороны все работало и ничего не менялось...
Я бы так не заявлял.... Премиум подписку сделал на полгода, проработала месяц и.... Нет соединения до серверов ни по одному протоколу... И по сотовой и по наземной сети (провайдеры различные)....
Вы реально не понимаете? :-) Есть "бизнес правило" - "со всех банкоматов для всех клиентов не выдавать налички на сумму более X миллиардов рублей за сутки" - даже если у клиентов (у каждого в отдельности) средства на контрактах/счетах есть... Именно это правило должно проверять до того как проверять есть у клиента средства или нет... Все просто... :-) Но без блокировок и транзакций (в которых проверяется данное условие при 1000 рпс по проверке одной суммы) есть идеи как это реализовать?
:-) Ну как бы "производительность БД" "по факту" не интересна никому...
Всех "по факту" интересует "производительность прикладного приложения".
Да есть связи между ними, но они "совсем не простые"... :-)
К примеру БД нагружается (выразимся так) "различными прикладными задачами". И у прикладных "задач" есть различные "требования" по времени ответа (от БД в том числе). Если в БД нет "встроенных" средств "приотеризации" - это уже "не есть хорошо". Вот и получаем ситуацию когда один (для приложения не приоритетный) запрос в БД (который БД обрабатывает как бы быстро и оптимально) "убивает" производительность других приоритетных для приложения запросов. Для PG это достаточно актуально.
:-) Мой "стандартный" вопрос к разработчику:
- Ты почему сделал так как сделал? Наверное ты понимаешь что у тебя был выбор из нескольких вариантов реализации? Вот такой, такой и такой. Так почему ты выбрал именно то как реализовал?
Ответ хорошего/правильного разработчика:
- Да рассматривал их все, но выбранный по сумме (перечисляет) критериев на мой взгляд наиболее оптимальный/эффективный (краткое описание причин выбора) .
Наиболее частые ответы "плохого" разработчика:
- Мне так просто захотелось и было проще, т.к. они же все решают поставленную задачу.
- Мне так сказали (руководство).
- А разве можно было "по другому"?
- Я услышал про новую/перспективную технологию и решил попробовать ее использовать.
:-) История...
Работаю в компании более 25 лет (с основания). "Прошел" различные "направления"/департаменты - разработка, поддержка и внедрение (у клиентов), ПМ, тестирование. "Воспитал" и обучил множество сотрудников (несколько сейчас на ключевых руководящих постах). В основном всегда быстро и эффективно решал "нестандартные и проблемные задачи" которые "непонятно как решать". Регулярно получал предложения "сменить" компанию/страну и т.п., но по различным причинам не менял.
После 5 лет работы начал в своей компании регулярно получать "предложения поруководить каким либо направлением".
Типовой диалог переговоров -
- Ты у нас очень хороший специалист. А давай ты поруководишь <.....>
- Ну вы же понимаете что у меня есть свои условия?
- А какие?
- Задачи и сроки их исполнения для подразделения ставятся мне. Ответственность за выполнение несу только я. Мои подчиненные будут исполнять только мои указания. Общий фонд оплаты полученный за выполненную работу между сотрудниками делю по своему усмотрению. И еще у меня недостаток есть - я врать не люблю, не умею и учиться этому не собираюсь. Вас это устроит?
- Спасибо мы подумаем.... А вот есть проблема с <....> может сможешь решить ее?
:-) Ну вот как то так... Моя "дурная привычка" называть вещи своими именами и "не любовь" к бюрократии, не нравится руководству, платят конечно нормально (мне хватает, хотя "по рынку" могу получать в два раза больше), но и решаю я задачи которые "мне интересны"....
:-) Ну видимо автор статьи мягко говоря "не очень в курсе" про различия в архитектуре mainframe и современных платформ.... Про "легкую смену языка" прикладного ПО ему уже написали... Плюс к этому "добавляется" "легкая смена БД" для хранения данных... :-)
Про выводы. В принципе ок - не считая 1. Именно из за первого вы имели отказы... Потому как проектируя и разрабатывая такую прикладную систему и не предусмотреть "connection storm" (от устройств) - нужно "постараться"....
Ну а про "vendor lock" говорить представителям SberDevices - должно быть просто стыдно... :-)
:-) Да. Потратил я тогда на нее много, но и удовольствия/впечатления от игр на Voodoo 2 получил много...
:-) Сдельная или повременная оплата?
:-) С автором статьи во многом согласен...
Особенно в части - если производительности одной БД для вашего прикладного ПО с учетом масштабирования и развития достаточно - микросервисы вам точно не нужны....
Но если у вас нет общего понимания (на ближайшие 10 лет) как будет масштабироваться и развиваться ваш программный продукт - проблема не в архитектуре, а в архитекторе...
:-) Вопросы по эксплуатации у клиента ПО (связанные с ее стоимостью) видимо сознательно упущены? :-)
:-) В тему расчета инфляции - https://anekdotov.net/anekdot/all/dtsstdvmshkbrkv.htm
Так это раньше UX делался по логике и эргономике... :-)
А сейчас "по моде, но не как у всех"... :-)
Кто бы сомневался... :-)
"Ну что тут думать?! Прыгать нужно!!!"
:-)
- Нам хоть бревна кантовать! Лишь бы лежа!!!
Плюсую... :-)
- Давай сейчас проработаем наиболее перспективные и возможные в будущем варианты развития продукта?
-- Зачем? Согласно постановки задачи архитектура выбрана оптимальна, а проработка возможных перспектив развития сейчас это + месяц аналитики (для 1 аналитика). А сроки "горят"! Пора программировать!
<прошло 3 года>
- Тут нужно добавить небольшую и востребованную функциональность к уже существующей в продукте, какие примерно сроки разработки?
-- Ну, учитывая что это "не ложится" на базовую архитектуру приложения, не меньше чем полгода работы (для 3 аналитиков и 15 разработчиков)....
https://www.youtube.com/watch?v=AmlHnYbAJuU
По факту, проще "щардировать" прикладную систему "в целом" (а не одну БД). Практические примеры - международные платежные системы. Больше общей "устойчивости" и масштабируемости...
Т.е. тупо обеспечить заявленную функциональность они не могут (без дополнительных "телодвижений" с моей стоны)? И это "хороший сервис"? С учетом что с моей стороны все работало и ничего не менялось...
Я бы так не заявлял.... Премиум подписку сделал на полгода, проработала месяц и.... Нет соединения до серверов ни по одному протоколу... И по сотовой и по наземной сети (провайдеры различные)....
Проект замечательный. Но у меня на Big Sur и intel - падает регулярно при открытии архивов.... :-(
Вы реально не понимаете? :-)
Есть "бизнес правило" - "со всех банкоматов для всех клиентов не выдавать налички на сумму более X миллиардов рублей за сутки" - даже если у клиентов (у каждого в отдельности) средства на контрактах/счетах есть... Именно это правило должно проверять до того как проверять есть у клиента средства или нет...
Все просто... :-)
Но без блокировок и транзакций (в которых проверяется данное условие при 1000 рпс по проверке одной суммы) есть идеи как это реализовать?