А производитель антивируса будет нести (и какую) финансовую ответственность в случае сбоев прикладной системы организации (таймаутов и отказа в обслуживании) по вине его софта? :-)
Да уж... Сколько по времени лет Oracle "отлаживал" ASM Tuning? И только в последних версиях (начиная с 19) он стал работать более менее адекватно... Какой "самонастраивающийся механизм" знает что завтра у вас будет обновление прикладного приложения с введением нового функционала и измененным "профилем нагрузки", или что "завтра" вы будете делать upgrade версии DB с "улучшенным функционалом"? Может "самонастраивающийся механизм" (до запуска пользователем "тяжелой для БД" прикладной процедуры) распределить ресурсы/нагрузку между множеством пользователей/процессов в БД "по желанию" администратора ("сегодня так а завтра по другому"), поскольку общая нагрузка не постоянна "по времени"? Может "самонастраивающаяся БД" знать, что завтра у вас количество пользователей или клиентов прикладного приложения увеличиться на 30% (поскольку с завтрашнего дня у вас новый клиент или договоры)? Просто "посмотрите" на "самонастраивающиеся" виртуальные сервера, у которых "регуляторов" по сути менее 20 (причем всего 4 типов CPU, RAM, IO диск и сеть), и сравните с современными БД (регуляторы которых "в прямую" зависят от ресурсов OS)...
Ну как бы конкретную DB в любом случае нужно подстраивать/оптимизировать под специфику прикладного приложения (с учетом доступных ресурсов и профиля нагрузки на нее) и это задача DBA... Другой вопрос что прикладное приложение должно "учитывать особенности реализации конкретной DB", а это сейчас большая проблема для современных прикладных разработчиков которые "по факту" только сторонними фреймворками и умеют пользоваться...
:-) Если в прикладной обработке на Oracle использовались множественные SELECT + UPDATE (и это "прокатывало", причем это конечно "скрыто" внутри GetObject(a) + SetObjectProperty(b) ), то на PG получаем "проблемы производительности"....
Полностью согласен... Принципы реализации многих "базовых" функций БД в Oracle и PG различные. Если прикладной софт, прикладные разработчики это "не учитывают" - при миграции приложения получите "как минимум" значительное падение прикладной производительности. Особенно на OLTP прикладных системах...
:-) Если пользователь четко не определил что он "хочет" (хоть на определенном этапе работы, хоть на весь финальный "заказ") - объем "бесполезной" работы исполнителя будет абсолютно одинаковый....
"Скрам нужен, когда вы понимаете что хотите, но не понимаете как достичь. И тут с помощью инкремента вы ищите свой путь " - а "потом" "вдруг" выясняется что ваше "понимание" (и проделанная вами работа) скажем так - не совпадает с пониманием целей и "хотелок" заказчика... :-)
:-) Я бы добавил так... У них в голове "объекты"... Ну понятно что для объекта проще всего сделать GetObject(i) -> SetObjectProperties(j) -> WriteObject(i).... А то что "за этим" стоит в БД им как бы "фиолетово"... И "получается" что вместо "update table set prop=x where id=i" в БД "получаем" select * from table where id=i (и это еще хорошо что в одной таблице, а могут выбирать все "свойства объекта" и из 10 по разным связкам + штук 5 "справочников") + зачастую могут выбирать и с блокировкой строк эксклюзивной и "подождать" реакции пользователя или удаленного сервиса с минуту + update (и хорошо если в одной таблице), а то могут обновить данные в нескольких связанных (ну вот такая у них "модель данных хранения").... И все это у них называется "объектное программирование".... :-)
:-) Забудем на минуту "тонкие и сложные нанометры" и вспомним "добрым словом" "отечественный" легковой автопром... Как там соотношение между "хорошо и дорого"? :-) А вроде и технологии все не заоблачно сложные....
Про "выглядит" ничего не могу сказать... Могу прокомментировать только про "звучит"... Железо соответствует минимально необходимому на текущий момент для подобных устройств (процессор и оперативка). Разнообразные китайские аналоги в рознице с подобными характеристиками CPU и флеш (но 4GB RAM что предпочтительней, т.к. работа приставки будет более "живой") дешевле на 1000 рублей (20%)... Так чем же хочет привлечь покупателей поставщик такого устройства? Жесткой привязкой к своей "экосистеме"? :-)
Это полная чушь... Невозможно отключить то что не имеет доступа в сеть... Ну а если вы его предоставили - значит не читали описание и условия взлома лицензии.
:-) У каждого свой реальный опыт и кругозор... Отказ "сайта банка" несет "немного" другие последствия, чем отказ центрального процессинга целой страны или платежной системы банка с 50 млн. активных клиентов и гигантской эквайринговой сети...
"Появлись много noSQL решений, которые в обмен на рпотерю "крутой" транзакционности дали скорострельность, гибкость и все такое." - именно "все такое" но не ACID.... Тут "главный критерий", а кто будет "расплачиваться" при "потере" нескольких млн. $ + репутации, когда "замечательные" решения "потеряют" финансовые транзакции? :-) Опять видны "уши" agile - "будем решать проблемы по мере их поступления" У людей постоянно занимающихся тестами на производительность и устойчивость высокопроизводительных технологических OLTP решений (включая кластеризацию, виртуализацию, контейнеризацию, шардирование баз на разных уровнях) - "есть другое мнение", чем у "теоретиков" начитавшихся маркетинговой чуши.
"Я думаю, очевидно, что крутится в контейнере, а что - нет." - я тоже... :-) И не очень понял как контейнеры относятся к нашему предмету обсуждения - "работы OLTP БД".... Что касается "нарезать" сразу - то пару раз в году (на праздники) нагрузка на БД и приложение раза в 3 выше чем остальные 360 дней. Будете "резать" с этим учетом? А под StandBy и DRS еще "нарезать" (с учетом что StandBy без нагрузки раза в 2-3 требует меньше ресурсов)? Очень экономно... А под пару периодических нагрузочных тестовых систем (плюс с десяток под функциональные тесты) - еще ресурсов "заранее нарезать"? Я уж про межкластерные сетевые требования и задержки (при отсутствии специализированных шин обмена) и не говорю... :-)
Да-уж... DML транзакции БД выполняются всегда "последовательно" (см. SCN). :-) "Набирайте" сколько хотите пока не случится такое - https://habr.com/ru/news/800851/ У вас в контейнере БД работает? :-) "Я не настолько богатый, чтобы покупать дешевые решения..." :-)
1) "Проверка 3DS может является частью этого шага" - не является... 3DS проверка это опциональный шаг выполняемый до авторизации. 2) "между которыми 10 может быть до 10 секунд" - именно может, а не всегда проходит (по факту "в среднем" 1,5 секунды отдельные пики до 2, 2-10 только штучные на периоде в сутки). 3) "иногда не только" - всегда поскольку это принцип работы OS с памятью на любых платформах. 4) На LPAR вы динамически (и даже автоматически на уровне виртуализации) можете "распределить" все ресурсы (и CPU и память и IO). На других платформах "в ручную" так же (HP,Oracle). Но только IBM это делает без "фриза" всей OS (и ее процессов) под нагрузкой на момент изменения количества CPU и RAM. Тесты были на всем (включая Exadata, HP UX и т.п. решениях). Если есть у вас возможность проверить - можете убедиться. :-) Что касаемо Exadata то для прикладных OLTP систем она "особо" не лучше любых навороченных Enterprise систем. Единственное ее неоспоримое преимущество - один вендор при использовании Oracle DB.
Еще раз... 3DS проверка - отдельная процедура и не имеет отношения к обработке карточной операции. Точнее имеет (поскольку использует параметры карточной) но выполняется "независимо" и завершается до процесса авторизации (а вот он уже использует ее данные). Если в транзакции вы используете select for update то - блокировка длится до commit/rollback. Причем тут 10 секунд? 10 секунд это допустимый максимум ответа, а не постоянная величина.... Лочится не "строка" - а "блок данных" (там и N строк м.б.) причем в памяти... Впрочем от IBM и ее технологий мы уже "ушли далеко". Но... Только на IBM P тот же Oracle без "пауз в работе БД" ("провалов" TPS) позволял менять количество доступных OS виртуальных ядер (ни одна платформа этого не позволяет) и только IBM динамически может перераспределять общие/единые ресурсы между виртуальными машинами.
3DS - это не про финансы... Это тупо проверка что "клиент реально твой" и идет "на стороне издателя". Ее результат тупо "пристегивается" к запросу операции. :-) Если все "в одной транзакции" - БД рулит корректным состоянием данных. На 2 шаге проверяется что текущий баланс минус сумма самой операции более 0. И поскольку последовательный "порядок" операций контролируется БД (а "по другому" ни одна ACID БД не работает), то все будет OK нужная сумма "будет всегда" и "отрицательный" ответ авторизации не изменит баланс. Учите теорию баз. "Проблемы" возникают только с блокировками в данном случае. А вот вариант "уменьшить" блокировки путем "деления" на две транзакции - и приводит к описанным вами "проблемам" - через 10 секунд "порядок" исполнения меняется (баланс м.б. не таким как при первой транзакции проверки баланса). И вот тут реально и начинается "отдельная песня". С дополнительными "искусственными" транзакциями/операциями отмены/корректировки и т.п. Читайте свои "тонны книг", но согласно математике 2+2 равно 4, а не "5 если продаем и 3 если покупаем" - как вы предлагаете. :-) Любые "авторизации" + "подтверждения" еще более нагружают и усложняют систему. Любые взаимодействия с "внешними" сервисами/"прокладками" увеличивают время "блокировки" или меняют "исходный" порядок операций. И мы пока еще даже "не касались" "проблем устойчивости и надежности" всей системы "в целом"... :-)
А производитель антивируса будет нести (и какую) финансовую ответственность в случае сбоев прикладной системы организации (таймаутов и отказа в обслуживании) по вине его софта? :-)
Да уж... Сколько по времени лет Oracle "отлаживал" ASM Tuning? И только в последних версиях (начиная с 19) он стал работать более менее адекватно...
Какой "самонастраивающийся механизм" знает что завтра у вас будет обновление прикладного приложения с введением нового функционала и измененным "профилем нагрузки", или что "завтра" вы будете делать upgrade версии DB с "улучшенным функционалом"?
Может "самонастраивающийся механизм" (до запуска пользователем "тяжелой для БД" прикладной процедуры) распределить ресурсы/нагрузку между множеством пользователей/процессов в БД "по желанию" администратора ("сегодня так а завтра по другому"), поскольку общая нагрузка не постоянна "по времени"?
Может "самонастраивающаяся БД" знать, что завтра у вас количество пользователей или клиентов прикладного приложения увеличиться на 30% (поскольку с завтрашнего дня у вас новый клиент или договоры)?
Просто "посмотрите" на "самонастраивающиеся" виртуальные сервера, у которых "регуляторов" по сути менее 20 (причем всего 4 типов CPU, RAM, IO диск и сеть), и сравните с современными БД (регуляторы которых "в прямую" зависят от ресурсов OS)...
Ну как бы конкретную DB в любом случае нужно подстраивать/оптимизировать под специфику прикладного приложения (с учетом доступных ресурсов и профиля нагрузки на нее) и это задача DBA... Другой вопрос что прикладное приложение должно "учитывать особенности реализации конкретной DB", а это сейчас большая проблема для современных прикладных разработчиков которые "по факту" только сторонними фреймворками и умеют пользоваться...
:-) Если в прикладной обработке на Oracle использовались множественные SELECT + UPDATE (и это "прокатывало", причем это конечно "скрыто" внутри GetObject(a) + SetObjectProperty(b) ), то на PG получаем "проблемы производительности"....
Полностью согласен... Принципы реализации многих "базовых" функций БД в Oracle и PG различные. Если прикладной софт, прикладные разработчики это "не учитывают" - при миграции приложения получите "как минимум" значительное падение прикладной производительности. Особенно на OLTP прикладных системах...
:-) Если пользователь четко не определил что он "хочет" (хоть на определенном этапе работы, хоть на весь финальный "заказ") - объем "бесполезной" работы исполнителя будет абсолютно одинаковый....
"Скрам нужен, когда вы понимаете что хотите, но не понимаете как достичь. И тут с помощью инкремента вы ищите свой путь " - а "потом" "вдруг" выясняется что ваше "понимание" (и проделанная вами работа) скажем так - не совпадает с пониманием целей и "хотелок" заказчика... :-)
А вот это - правильный вопрос! :-) Ни одному государству в мире умные граждане не нужны. Они ведь могут думать и задавать "неудобные вопросы"...
:-) Я бы добавил так... У них в голове "объекты"... Ну понятно что для объекта проще всего сделать GetObject(i) -> SetObjectProperties(j) -> WriteObject(i)....
А то что "за этим" стоит в БД им как бы "фиолетово"... И "получается" что вместо "update table set prop=x where id=i" в БД "получаем" select * from table where id=i (и это еще хорошо что в одной таблице, а могут выбирать все "свойства объекта" и из 10 по разным связкам + штук 5 "справочников") + зачастую могут выбирать и с блокировкой строк эксклюзивной и "подождать" реакции пользователя или удаленного сервиса с минуту + update (и хорошо если в одной таблице), а то могут обновить данные в нескольких связанных (ну вот такая у них "модель данных хранения")....
И все это у них называется "объектное программирование".... :-)
:-) Забудем на минуту "тонкие и сложные нанометры" и вспомним "добрым словом" "отечественный" легковой автопром... Как там соотношение между "хорошо и дорого"? :-) А вроде и технологии все не заоблачно сложные....
Про "выглядит" ничего не могу сказать... Могу прокомментировать только про "звучит"...
Железо соответствует минимально необходимому на текущий момент для подобных устройств (процессор и оперативка). Разнообразные китайские аналоги в рознице с подобными характеристиками CPU и флеш (но 4GB RAM что предпочтительней, т.к. работа приставки будет более "живой") дешевле на 1000 рублей (20%)... Так чем же хочет привлечь покупателей поставщик такого устройства? Жесткой привязкой к своей "экосистеме"? :-)
Почему так дорого то? :-)
Брал - UIG NF7840HS Ноутбук 16", AMD Ryzen 7 7840HS, RAM 16 ГБ, SSD 1024 ГБ, AMD Radeon 780M, Windows Pro, (7840), серый, Русская раскладка - менее 470$ на озон..... А это ноут с нормальным экраном...
Это полная чушь... Невозможно отключить то что не имеет доступа в сеть... Ну а если вы его предоставили - значит не читали описание и условия взлома лицензии.
:-) У каждого свой реальный опыт и кругозор... Отказ "сайта банка" несет "немного" другие последствия, чем отказ центрального процессинга целой страны или платежной системы банка с 50 млн. активных клиентов и гигантской эквайринговой сети...
"Появлись много noSQL решений, которые в обмен на рпотерю "крутой" транзакционности дали скорострельность, гибкость и все такое." - именно "все такое" но не ACID....
Тут "главный критерий", а кто будет "расплачиваться" при "потере" нескольких млн. $ + репутации, когда "замечательные" решения "потеряют" финансовые транзакции? :-) Опять видны "уши" agile - "будем решать проблемы по мере их поступления"
У людей постоянно занимающихся тестами на производительность и устойчивость высокопроизводительных технологических OLTP решений (включая кластеризацию, виртуализацию, контейнеризацию, шардирование баз на разных уровнях) - "есть другое мнение", чем у "теоретиков" начитавшихся маркетинговой чуши.
"Я думаю, очевидно, что крутится в контейнере, а что - нет." - я тоже... :-)
И не очень понял как контейнеры относятся к нашему предмету обсуждения - "работы OLTP БД"....
Что касается "нарезать" сразу - то пару раз в году (на праздники) нагрузка на БД и приложение раза в 3 выше чем остальные 360 дней. Будете "резать" с этим учетом? А под StandBy и DRS еще "нарезать" (с учетом что StandBy без нагрузки раза в 2-3 требует меньше ресурсов)? Очень экономно... А под пару периодических нагрузочных тестовых систем (плюс с десяток под функциональные тесты) - еще ресурсов "заранее нарезать"? Я уж про межкластерные сетевые требования и задержки (при отсутствии специализированных шин обмена) и не говорю... :-)
Да-уж... DML транзакции БД выполняются всегда "последовательно" (см. SCN).
:-) "Набирайте" сколько хотите пока не случится такое - https://habr.com/ru/news/800851/
У вас в контейнере БД работает? :-)
"Я не настолько богатый, чтобы покупать дешевые решения..." :-)
1) "Проверка 3DS может является частью этого шага" - не является... 3DS проверка это опциональный шаг выполняемый до авторизации.
2) "между которыми 10 может быть до 10 секунд" - именно может, а не всегда проходит (по факту "в среднем" 1,5 секунды отдельные пики до 2, 2-10 только штучные на периоде в сутки).
3) "иногда не только" - всегда поскольку это принцип работы OS с памятью на любых платформах.
4) На LPAR вы динамически (и даже автоматически на уровне виртуализации) можете "распределить" все ресурсы (и CPU и память и IO). На других платформах "в ручную" так же (HP,Oracle). Но только IBM это делает без "фриза" всей OS (и ее процессов) под нагрузкой на момент изменения количества CPU и RAM. Тесты были на всем (включая Exadata, HP UX и т.п. решениях). Если есть у вас возможность проверить - можете убедиться. :-)
Что касаемо Exadata то для прикладных OLTP систем она "особо" не лучше любых навороченных Enterprise систем. Единственное ее неоспоримое преимущество - один вендор при использовании Oracle DB.
Еще раз... 3DS проверка - отдельная процедура и не имеет отношения к обработке карточной операции. Точнее имеет (поскольку использует параметры карточной) но выполняется "независимо" и завершается до процесса авторизации (а вот он уже использует ее данные).
Если в транзакции вы используете select for update то - блокировка длится до commit/rollback. Причем тут 10 секунд? 10 секунд это допустимый максимум ответа, а не постоянная величина....
Лочится не "строка" - а "блок данных" (там и N строк м.б.) причем в памяти...
Впрочем от IBM и ее технологий мы уже "ушли далеко". Но... Только на IBM P тот же Oracle без "пауз в работе БД" ("провалов" TPS) позволял менять количество доступных OS виртуальных ядер (ни одна платформа этого не позволяет) и только IBM динамически может перераспределять общие/единые ресурсы между виртуальными машинами.
3DS - это не про финансы... Это тупо проверка что "клиент реально твой" и идет "на стороне издателя". Ее результат тупо "пристегивается" к запросу операции.
:-) Если все "в одной транзакции" - БД рулит корректным состоянием данных. На 2 шаге проверяется что текущий баланс минус сумма самой операции более 0. И поскольку последовательный "порядок" операций контролируется БД (а "по другому" ни одна ACID БД не работает), то все будет OK нужная сумма "будет всегда" и "отрицательный" ответ авторизации не изменит баланс. Учите теорию баз. "Проблемы" возникают только с блокировками в данном случае.
А вот вариант "уменьшить" блокировки путем "деления" на две транзакции - и приводит к описанным вами "проблемам" - через 10 секунд "порядок" исполнения меняется (баланс м.б. не таким как при первой транзакции проверки баланса). И вот тут реально и начинается "отдельная песня". С дополнительными "искусственными" транзакциями/операциями отмены/корректировки и т.п.
Читайте свои "тонны книг", но согласно математике 2+2 равно 4, а не "5 если продаем и 3 если покупаем" - как вы предлагаете. :-) Любые "авторизации" + "подтверждения" еще более нагружают и усложняют систему. Любые взаимодействия с "внешними" сервисами/"прокладками" увеличивают время "блокировки" или меняют "исходный" порядок операций.
И мы пока еще даже "не касались" "проблем устойчивости и надежности" всей системы "в целом"... :-)