Но если данный подход под микросервис, под которым БД на 3 таблицы в сотню строк - да пофиг, там и sql нафиг. Но "когда у тебя в руках молоток, весь мир - гвозди".
Для промышленного применения, когда у тебя БД нагрузкой, каждый запрос умножается на число его вызовов. Исправить ошибки проектирования сложнее чем ошибку в днк проектировщика. На заре появления реляционных БД инженеры думали головой. Например, static(embedded) sql и никаких инъекций, и сервер не занимается компиляциями однотипных запросов, стоимость которых на порядок выше цены их исполнения, и никаких вопросов "кто написал этот скуль?! Сервер лег!", и безопам счастье, никаких юзеров, одни спузы.
Автогенераторы кода для БД давно существуют для компенсации скиллов разработчиков. Прототипировать годиться. Но когда такой продукт идет в бой, наступает прозрение. Но переписывать уже работающий код...
Если бы еще инженеры в далеком 2000 не сдались с SQL SP, то не было бы антипаттерна про бизнес-логику в БД... :)
Все банки подключены к ГИС ГМП. Это коммуналка, штрафы, судебные и тп. Получить из госсистемы начисления можно по ИНН, который банк знает. И банк обязан проверить наличие и статус в ГИС ГМП, если в платежке есть поле УИД (22, и, кто бы мог подумать, оно же теперь для ЭДО с ФНС после перехода на ЕНС, чтоб ИТ не скучали) - чтобы избежать ситуации, когда два банка (авто)платеж сделают по одному начислению.
Так почему бы не помочь клиенту комфортно потратить деньги на неприятные вещи типа штрафа, предзаполнив за него правильно все поля?
Любая нештатная ситуация сначала возникает первый раз. Например, скорость мониторинга могла не успеть за метрикой или создание такой ситуации самой системой мониторинга. Но больше вероятность человеческого фактора, в том числе из лучших побуждений, например при невозможности воспроизвести ошибку на тесте приходиться рисковать на бою - сам так делал :)
Япония - работает, сильно упрощая процесс перевода. Потому что перекинуть деньги иным способом - это обязательный поход в Банк по предварительной записи с доказательными бумажками и 2-3 недели на сам перевод, у Примсоц чуть быстрее в пару банков.
Идея класс! Но, как пользователь со стажем, задам вопрос - колебания монитора на столь длинном рычаге при движении как-то решены? При долгом сидении, даже в сверхудобном положении,что-то затекает и организм начинает это компенсировать - мы меняем положение, трясем ногой и пр. Просто при работе с клавиатурой есть колебания весьма монолитного стола. Я был вынужден был заменить кронштейн для монитора, который крепился к столу, на настенный вариант. В данной конструкции, как я вижу, колебания будут напрямую передаваться на монитор. Какой был кошмар в свое время из-за колебания решетки на тринитронах...
Как погруженный в тему - не всегда можно предвидеть. Имея весьма нескромный опыт в кровавом энтерпрайзе и построив эшелонированную оборону от разработки до деплоя на прод, несколько раз ловил epic fail.
В качестве примера - была задача по ограничению доступной инфы на экране признаку VIP. VIP'ов было пара сотен, что на фоне миллионов клиентов даже в пределы погрешности не укладывалось. Задачку примитивная, скинули джуну, по феншую фичу даже протестировали на паре офисов и забыли до отмашки заказчиком. Через пару месяцев вместе с глобальным обновлением включили в релиз - как крыжик в настройках...
Джун, ему простительно, реализовал прекрасно: на каждый (ты вдруг VIP'ом стал внезапно) got/lost focus элемента формы проверка через select * from vip, дальше поиск по массиву уже на клиенте...
В форме, центральной, было несколько десятков закладок, пара сотен статических и, в зависимости от, еще минимум сотня динамических элементов. А в момент открытия формы, как мы потом узнали, каждый (!) элемент генерил эти 2 события. И в понедельник утром > 5 тыс. ничего не подозревающих пользователей пришли на работу. И не могли открыть форму, приложение "висело", они его срубали и открывали заново. Восточные регионы успели, а следующие часовые пояса уже нет, что внесло свои коррективы в понимание проблемы. Мы докидывали сервера приложений, которые принимались переваривать все новые сессии пользователей, а старые никуда не девались, пока не дорабатывали до конца или мы не перегружали сервак. Между БД и серверами приложений гнался немеренный траффик. К БД было подключено несколько десятков и других приложений, и там тоже началась деградация.
Тем, кто не очень в теме БД, простой select из базы в таком виде грубо: declare stmt/open cursor/fetch 200+ rows/close cursor, каждое действие это несколько пакетов, каждый фетч страница в 4Кб, умноженное на число строк в таблице - 200+ и умноженное на 2*300 раз за контрол на форме на каждого пользователя=5000 и каждую зависшую сессию - умножить еще на 2. И все это в единицу времени. "Ватага зайцев мочит льва."
Мы ddos-или собственную инфру. И самое главное, не понимали причину, поднимали новые сервера => создавали все новую нагрузку, положили сеть. Снять дампы или включить детальный мониторинг было нереально. А причину, без инструмента и исходных данных, искали, как вы понимаете, теоретически, в последних-предпоследних-предпредпоследних изменениях. Судорожные откаты к результату не приводили, управлять пользователям мы в тот момент не умели. А про крыж в настройках никто не подумал, потому что дата файла с этими настройками из репозитория (феншуй епрст!) оказалась, как можно догадаться, 2-х месячной давности.
Как DBA отвечу:
И разработка и ревью изменений БД - было. И на деве, тесте, предпроде и, частично на проде, были настроены мониторинги - кривые запросы к БД отлавливались автоматом по целому сету условий. Но на экранах радаров эту мелочь не заметили, от пары юзверей пусть даже несколько тысяч запросов, из кеша в пару тестовых записей, которые относительно нескольких сотен транзакций в секунду, не попали в top-100 ни по одному показателю.
Графики нагрузки на продуктивные БД имели историю, анализ, с указанием причин изменений ключевых показателей, объяснения динамики и "красные линии", с историчностью в несколько лет и разбирались на еженедельной основе вместе с разрабами. И с точки зрения написанного кода, и бизнес-показателей, внедрения новых фич и тп. Не говоря уже про даш-борды и алерты для группы онлайн-мониторинга 24х7.
"Можно придумать защиту от дурака, но только неизобретательного" ИТ-шная мудрость
Конечно, нет. Неужели можно предположить, что перед тем, как добраться до расширенных настроек биоса, старый админ не проверил все порты, режимы/настройки системы, не перелопатил реестр и тп :) Дошел до инженеров вендора - увы.
А про виртуальные карты месье не слышал и копирование номера из банковского приложения? И чем плохи менеджеры паролей, которые не хранят данные неизвестно где "в облаке" и доступа в сеть не имеют?
Боль! Года 3-4 назад победил, тоже был тот еще квест, через расширенные настройки биоса и правкой реестра.
Но осталась одна нерешенная - USB порт не отключается никак, кроме как при shutdown. А на это было завязан сетап с отключением питания периферии (подставки/монитора и тп). Максимум достигнутого, порт отключается при отсутствии внешнего питания. И это "by design".
Институт Проблем Управления (ИПУ) был одним из тех, кто считал зарплату для других, и гуляла байка. Привозили списки особые люди с чемоданчиками на браслетах, и, как правило, накануне 5-го и 20-го, сразу все. Множество теток-машинисток забивало все это на УПД, потом программеры переносили на ЭВМ. Один из сотрудников лабы подготовки данных попросил одних таких привести в следующий раз не распечатку, которую сразу было видно, а записать на носитель - хотя бы перфорленту, если магнитных лент нет. И в следующий раз привезли. Сколько потребовалось солдат, чтобы переписать текст на перфоленту никто не знает, а того, кто это увидел, потом долго отпаивали спиртом.
Шпаргалка вещь хорошая, но многим из поколения ЕГЭ нужны готовые примеры. Могу порекомендовать по SQL книжку с хорошими примерами, проверенную веками :), http://db2-sql-cookbook.org/, особенности синтаксиса db2 можно спокойно пропустить.
Т.е. через 100 мс откат по таймауту? Или все же Deadlock_timeout — ну если читать как написано, должен лишь означать период для запуска процесса проверки и разрешения deadlock'ов? Процесс этот весьма затратный по ресурсам при большом числе соединений и транзакций, только на период стабилизации выставляем его в минимум. И deadlock не может развязаться сам по себе — менеджер принудительно откатывает одну из блокирующих транзакций. И как раз чтобы понять, как транзакции сумели войти в клинч, нужна история во времени со всеми стейтментами и, по созданным блокировкам, снапшот на момент обнаружения.
Я не понимаю как можно «снимать состояние блокировок в базе» для oltp-системы, где locklist в десятки тысяч записей, который меняется с каждым стейтмент'ом…
тема требует объяснений очень издалека. Классические БД автоматизировали ручной процесс и мы с вами пользуемся «аналоговыми» базами в повседневной жизни. Попытайтесь сначала представить процесс не автоматизированным — как норвеги, например, проверили IP на голубях. В качестве примера те же носки — купил упаковку в 10 пар в m&s — они черные, положил в ящик = таблица, единственный аттрибут — цвет. Выборка будет — жена, дай пару черного цвета — select… where color=black… fetch 2. Да? Или по номеру? Тут еще подолью масла в огонь, любимый всеми STATUS — «and status=0». Это значит, что чистые и грязные носки у вас лежат в одном ящике и команда жене расшириться на предикат «понюхай каждый»…
Если у Вас все носки пронумерованы, тут крыть нечем. Это особый случай — для этого обычно применяются key value db.
Изначальный посыл статьи — боль сопровождения, как последствия неудачного проектирования.
А как все просто в мире кровавого энтерпрайза -для deadlock/locktimeout события с полной хистори валятся в файл, для нужд мониторинга счетчики автоматом собираются и на уровне менеджера, базы и отдельного коннекта, для расследования — create event monitor for locking и вся картина есть… А ловить в онлайне на oltp базе прода с тысячами транзакций в сек — я не представляю. У нас lock_timeout большинства приложений 1 сек., у привилегированных 5. Конечно, далеко не все просто — бывает сложно разобраться, когда встречаются больше 2 транзакций. Плюс нужно понимать, не было ли эскалаций, с каким уровнем изоляции выполнялось и тд. А если это для olapa — там, обычно, проще по стейтментам пройтись.
Реализация счетчика для БД, в конкурентной среде, задача нетривиальная. При реализация с полной блокировкой возможен только один поток. Вынужденно каждому соединению сервер выделяет блок значений от сиквенса, в результате счетчик перестает быть счетчиком как таковым. Последовательность получения значений и реальный порядок попадания записей в БД нарушается, образуются дыры. При кластерной конфигурации наступает катастрофа, т.к. мастером по сиквенсу может выступать только один сервер и другие вынуждены обращаться к нему — при операциях даже в 1с сетевые задержки уже существенны. Представьте слегка нагруженную oltp базу с 1000 коннектов и 20 тыс транзакций (не операций) в сек. и хотя бы 0.01% из них вдруг замедлиться на 100 ms.
Все вышеописанное, как и статья, относится к промышленным системам. Хотя проблема может выстрелить и при относительно примитивном сценарии — система А передает события с ID типа счетчик в систему Б, система Б по данному ID обеспечивает идемпотентность, счетчик рестартовали…
При этом никто не будет бить по голове разраба, если он использует сиквенс для справочника в сотню строк, который дополняется раз неделю. Хотя и тут возможны проблемы — когда у вас несколько сред, например, тестирования…
Могут. Но «носок номер 5 и 12 составляют пару» как-то в жизни не используем…
А как только разработчик использует rowid — он не понимает БД от слова совсем.
А типовая ситуация, когда две базы связаны через ключи-счетчики и одну откатили — и начались танцы с бубном по синхронизации.
В DB2 с доисторических времен для генерации ключей рекомендовалось generate_unique() основанное на времени и номера сервера для кластерных конфигураций. При этом метка времени не является бессмысленным суррогатом и может, например, ограничивать выборку как предикат или использоваться для шардирования таблицы.
При проектировании БД нужно придерживаться естественных ключей.
Страшный сон для DBA.
Но если данный подход под микросервис, под которым БД на 3 таблицы в сотню строк - да пофиг, там и sql нафиг. Но "когда у тебя в руках молоток, весь мир - гвозди".
Для промышленного применения, когда у тебя БД нагрузкой, каждый запрос умножается на число его вызовов. Исправить ошибки проектирования сложнее чем ошибку в днк проектировщика. На заре появления реляционных БД инженеры думали головой. Например, static(embedded) sql и никаких инъекций, и сервер не занимается компиляциями однотипных запросов, стоимость которых на порядок выше цены их исполнения, и никаких вопросов "кто написал этот скуль?! Сервер лег!", и безопам счастье, никаких юзеров, одни спузы.
Автогенераторы кода для БД давно существуют для компенсации скиллов разработчиков. Прототипировать годиться. Но когда такой продукт идет в бой, наступает прозрение. Но переписывать уже работающий код...
Если бы еще инженеры в далеком 2000 не сдались с SQL SP, то не было бы антипаттерна про бизнес-логику в БД... :)
Все банки подключены к ГИС ГМП. Это коммуналка, штрафы, судебные и тп. Получить из госсистемы начисления можно по ИНН, который банк знает. И банк обязан проверить наличие и статус в ГИС ГМП, если в платежке есть поле УИД (22, и, кто бы мог подумать, оно же теперь для ЭДО с ФНС после перехода на ЕНС, чтоб ИТ не скучали) - чтобы избежать ситуации, когда два банка (авто)платеж сделают по одному начислению.
Так почему бы не помочь клиенту комфортно потратить деньги на неприятные вещи типа штрафа, предзаполнив за него правильно все поля?
И 152-ФЗ это не про госорганы.
Любая нештатная ситуация сначала возникает первый раз. Например, скорость мониторинга могла не успеть за метрикой или создание такой ситуации самой системой мониторинга. Но больше вероятность человеческого фактора, в том числе из лучших побуждений, например при невозможности воспроизвести ошибку на тесте приходиться рисковать на бою - сам так делал :)
Япония - работает, сильно упрощая процесс перевода. Потому что перекинуть деньги иным способом - это обязательный поход в Банк по предварительной записи с доказательными бумажками и 2-3 недели на сам перевод, у Примсоц чуть быстрее в пару банков.
Идея класс! Но, как пользователь со стажем, задам вопрос - колебания монитора на столь длинном рычаге при движении как-то решены? При долгом сидении, даже в сверхудобном положении,что-то затекает и организм начинает это компенсировать - мы меняем положение, трясем ногой и пр. Просто при работе с клавиатурой есть колебания весьма монолитного стола. Я был вынужден был заменить кронштейн для монитора, который крепился к столу, на настенный вариант. В данной конструкции, как я вижу, колебания будут напрямую передаваться на монитор. Какой был кошмар в свое время из-за колебания решетки на тринитронах...
" в команде нет DBA"
Зацепило.
Как погруженный в тему - не всегда можно предвидеть. Имея весьма нескромный опыт в кровавом энтерпрайзе и построив эшелонированную оборону от разработки до деплоя на прод, несколько раз ловил epic fail.
В качестве примера - была задача по ограничению доступной инфы на экране признаку VIP. VIP'ов было пара сотен, что на фоне миллионов клиентов даже в пределы погрешности не укладывалось. Задачку примитивная, скинули джуну, по феншую фичу даже протестировали на паре офисов и забыли до отмашки заказчиком. Через пару месяцев вместе с глобальным обновлением включили в релиз - как крыжик в настройках...
Джун, ему простительно, реализовал прекрасно: на каждый (ты вдруг VIP'ом стал внезапно) got/lost focus элемента формы проверка через select * from vip, дальше поиск по массиву уже на клиенте...
В форме, центральной, было несколько десятков закладок, пара сотен статических и, в зависимости от, еще минимум сотня динамических элементов. А в момент открытия формы, как мы потом узнали, каждый (!) элемент генерил эти 2 события. И в понедельник утром > 5 тыс. ничего не подозревающих пользователей пришли на работу. И не могли открыть форму, приложение "висело", они его срубали и открывали заново. Восточные регионы успели, а следующие часовые пояса уже нет, что внесло свои коррективы в понимание проблемы. Мы докидывали сервера приложений, которые принимались переваривать все новые сессии пользователей, а старые никуда не девались, пока не дорабатывали до конца или мы не перегружали сервак. Между БД и серверами приложений гнался немеренный траффик. К БД было подключено несколько десятков и других приложений, и там тоже началась деградация.
Тем, кто не очень в теме БД, простой select из базы в таком виде грубо: declare stmt/open cursor/fetch 200+ rows/close cursor, каждое действие это несколько пакетов, каждый фетч страница в 4Кб, умноженное на число строк в таблице - 200+ и умноженное на 2*300 раз за контрол на форме на каждого пользователя=5000 и каждую зависшую сессию - умножить еще на 2. И все это в единицу времени. "Ватага зайцев мочит льва."
Мы ddos-или собственную инфру. И самое главное, не понимали причину, поднимали новые сервера => создавали все новую нагрузку, положили сеть. Снять дампы или включить детальный мониторинг было нереально. А причину, без инструмента и исходных данных, искали, как вы понимаете, теоретически, в последних-предпоследних-предпредпоследних изменениях. Судорожные откаты к результату не приводили, управлять пользователям мы в тот момент не умели. А про крыж в настройках никто не подумал, потому что дата файла с этими настройками из репозитория (феншуй епрст!) оказалась, как можно догадаться, 2-х месячной давности.
Как DBA отвечу:
И разработка и ревью изменений БД - было. И на деве, тесте, предпроде и, частично на проде, были настроены мониторинги - кривые запросы к БД отлавливались автоматом по целому сету условий. Но на экранах радаров эту мелочь не заметили, от пары юзверей пусть даже несколько тысяч запросов, из кеша в пару тестовых записей, которые относительно нескольких сотен транзакций в секунду, не попали в top-100 ни по одному показателю.
Графики нагрузки на продуктивные БД имели историю, анализ, с указанием причин изменений ключевых показателей, объяснения динамики и "красные линии", с историчностью в несколько лет и разбирались на еженедельной основе вместе с разрабами. И с точки зрения написанного кода, и бизнес-показателей, внедрения новых фич и тп. Не говоря уже про даш-борды и алерты для группы онлайн-мониторинга 24х7.
"Можно придумать защиту от дурака, но только неизобретательного" ИТ-шная мудрость
Конечно, нет. Неужели можно предположить, что перед тем, как добраться до расширенных настроек биоса, старый админ не проверил все порты, режимы/настройки системы, не перелопатил реестр и тп :) Дошел до инженеров вендора - увы.
А про виртуальные карты месье не слышал и копирование номера из банковского приложения? И чем плохи менеджеры паролей, которые не хранят данные неизвестно где "в облаке" и доступа в сеть не имеют?
Боль! Года 3-4 назад победил, тоже был тот еще квест, через расширенные настройки биоса и правкой реестра.
Но осталась одна нерешенная - USB порт не отключается никак, кроме как при shutdown. А на это было завязан сетап с отключением питания периферии (подставки/монитора и тп). Максимум достигнутого, порт отключается при отсутствии внешнего питания. И это "by design".
Институт Проблем Управления (ИПУ) был одним из тех, кто считал зарплату для других, и гуляла байка. Привозили списки особые люди с чемоданчиками на браслетах, и, как правило, накануне 5-го и 20-го, сразу все. Множество теток-машинисток забивало все это на УПД, потом программеры переносили на ЭВМ. Один из сотрудников лабы подготовки данных попросил одних таких привести в следующий раз не распечатку, которую сразу было видно, а записать на носитель - хотя бы перфорленту, если магнитных лент нет. И в следующий раз привезли. Сколько потребовалось солдат, чтобы переписать текст на перфоленту никто не знает, а того, кто это увидел, потом долго отпаивали спиртом.
Шпаргалка вещь хорошая, но многим из поколения ЕГЭ нужны готовые примеры. Могу порекомендовать по SQL книжку с хорошими примерами, проверенную веками :), http://db2-sql-cookbook.org/, особенности синтаксиса db2 можно спокойно пропустить.
А Pirates! от гения Сида, какую карту мы рисовали. Да и вообще шедевры от Microprose — F19,Civ, Covert Action, Darklands, MoO, MoM, X-Com!
Warlords. «за два хода не дойду» — эту фразу разбуженного приятеля в ответ на предложение пойти на кухню я не забуду :)
А EoB? А Sierra — King/Police/Space Quest и Larry, те, ламповые — cut erotic sculpture?
Пойду сушить клавиатуру залитую ностальгией.
Я не понимаю как можно «снимать состояние блокировок в базе» для oltp-системы, где locklist в десятки тысяч записей, который меняется с каждым стейтмент'ом…
Если у Вас все носки пронумерованы, тут крыть нечем. Это особый случай — для этого обычно применяются key value db.
Изначальный посыл статьи — боль сопровождения, как последствия неудачного проектирования.
Вы совершенно не понимаете, что такое БД.
2. Программисты привыкли к массивам и меткам.
Реализация счетчика для БД, в конкурентной среде, задача нетривиальная. При реализация с полной блокировкой возможен только один поток. Вынужденно каждому соединению сервер выделяет блок значений от сиквенса, в результате счетчик перестает быть счетчиком как таковым. Последовательность получения значений и реальный порядок попадания записей в БД нарушается, образуются дыры. При кластерной конфигурации наступает катастрофа, т.к. мастером по сиквенсу может выступать только один сервер и другие вынуждены обращаться к нему — при операциях даже в 1с сетевые задержки уже существенны. Представьте слегка нагруженную oltp базу с 1000 коннектов и 20 тыс транзакций (не операций) в сек. и хотя бы 0.01% из них вдруг замедлиться на 100 ms.
Все вышеописанное, как и статья, относится к промышленным системам. Хотя проблема может выстрелить и при относительно примитивном сценарии — система А передает события с ID типа счетчик в систему Б, система Б по данному ID обеспечивает идемпотентность, счетчик рестартовали…
При этом никто не будет бить по голове разраба, если он использует сиквенс для справочника в сотню строк, который дополняется раз неделю. Хотя и тут возможны проблемы — когда у вас несколько сред, например, тестирования…
А как только разработчик использует rowid — он не понимает БД от слова совсем.
В DB2 с доисторических времен для генерации ключей рекомендовалось generate_unique() основанное на времени и номера сервера для кластерных конфигураций. При этом метка времени не является бессмысленным суррогатом и может, например, ограничивать выборку как предикат или использоваться для шардирования таблицы.
При проектировании БД нужно придерживаться естественных ключей.