Database First! О распространённых ошибках использования РСУБД / Николай Самохвалов (Postila) 

Этот коммент информативнее чем сам доклад😂, Добавлю ещё что докладчик предложил использовать адрес эл.почты в качестве первичного ключа, я с этим категорично не согласен, не учитывается возможный процесс где пользователь может свою эл.почту поменять. Первичные ключи всётаки должны быть абстрагированны от сущностей. Автору надо было сделать больший упор на 3нф и прочее

@@Ipat639 так же не понял любви автора к вещественным праймери ключам, ведь то что сегодня уникально завтра уже нет, прогнозировать развитие продукта наперед мы не можем

да, не очень вышло местами. вот слайды: www.dropbox.com/s/y0h6toonhpbd11h/DatabaseFirst_RIT_HLj_Samokhvalov.pdf?dl=0

Благодарю. Если можно, то задам вопрос: Вы в докладе несколько раз упоминаете хранимки, и, насколько я понял вашу философию отношения к БД и СУБД, хранимки это хорошо, это нужно юзать. Но ведь с ними столько проблем: от разделения логики между приложением и БД до версионирования и тестирования. Может быть посоветуете какие-то best practice как готовить хранимки? (Постгрес в приоритете)

Конечно. Xранимки - НЕ ЗЛО. Злом их принято считать традиционно, потому что они в некоторых популярных опенсорсных СУБД работали очень плохо. По вашим вопросам. Я пока вижу два пункта, про разделение логики и про «готовку» (версионировение, тестирование) 1) дело в том, что часть логики давно «перетащил» на себя фронтэнд (клиент стал толстым - мобилки, реакт и т.д.). Выходит, что всё равно приходится «париться» и разделять бизнес-логику. Толстого апп-слоя в архитектуре давно уже не существует как класса, это всё осталось в девяностых и нулевых. Так вот, мой тезис в том, что если вы заберёте всё, что можно забрать из так называемой «бизнес-логики» на фронт, то очень большой кусок из того, что остаётся, - это типичные задачи для СУБД. Валидация данных, поддержка их в согласованном виде и тд. В некоторых случаях можно пойти дальше и прибить (или почти прибить) app layer, раздербанив бизнес-логику на две части. Одна ушла во фронт (тут и спорить нечего, т.к. все так уже делают и кучу всего напридумывали, чтобы UX был лучше), а другую можно смело делать в самом Постгресе. SQL превосходен для работы с данными! Реально, в некоторых случаях вместо команды рубистов можно обойтись силами одного инженера с хорошим знанием SQL -- ставите PostgREST и всё делаете на хранимках, выходит быстро и качественно. API готов, можно сосредоточиться на приложении. Об этом я рассказывал на РИТ 2016, кстати. 2) Версионирование (принято называть "миграциями схемы БД"). Этому много уделено внимания было на наших встречах #RuPostgres. Посмотрите видео в канале RuPostgres, там была встреча в ЛАНИТ про liquibase и в Яндексе про их систему миграций. Сам использую sqitch.org и очень рекомендую. Легко встроить в любой стек. У рельсов ок использовать встроенную систему, с некоторыми оговорками. Насчёт тестирования. В sqitch встроены базовые возможности (verify-скрипты, см. доки на сайте, есть примеры). Я обычно делаю кучу тестов с помощью анонимных plpgsql-конструкций (do $$ blabla $$ language plpgsql;). Ещё есть целый фреймворк pgTap, автор тот же, что и у sqitch. Есть ещё куча вариантов писать миграции для БД. На хранимках уже тыщу лет работает скайп (мы авторов, кстати, привозили ещё году в 2008 на Highload, можно поискать материалы), и Яндекс.Почта мигрировала с Оракла на Постгрес очень успешно (см. доклады на #RuPostgres и PgCon), опять же во многом благодаря хранимкам и pl/proxy.

Благодарю за столь развернутый ответ.

Upd: docs.google.com/presentation/d/1rlNNFy-p-mlbJr3NJcFLMmJ0C81VE99kA_SZvJNFq5s/edit

Спасибо за отзыв! По пунктам. С первым согласен - да, оконными функциями в данном случае получается лаконичнее, чем плясками с массивами! Со вторым - ну что тут скажешь, основную мысль доклада, выходит, не полностью донёс. "Триггера нельзя применять(ибо это одно из самых больших бед в БД)" - это заблуждение. Расскажите это тем, кто пишет какие-нибудь серьёзные вещи. Например, АБСки (банковские системы).

Николай, благодарю за ответ! Мне кажется, что я писал достаточно серьезные вещи (работал с базами крупнейшего сотового оператора СНГ и крупнейшего ритейлера России), в высоконагруженной среде и достаточно большими объемами данных(100 Тб+). Как-то я занимался детальным анализом производительности системы, в которой на ключевой сущности, состоящей из мастер таблицы и таблицы деталей(100+ млд строк), сумарно было создано около 50 триггеров, некоторые из которых по 1500+ строк кода. Помимо анализа кода, профилировки, трассировки, я делал различные эксперементы замеряя на сколько меняется производительность типовых операций с таблицами от наличия индесков, контрейнтов и триггеров. Триггеры - вне конкуренции по влиянию на производительность. На низком уровне, даже идеально написанные построчные Триггера вынуждены проводить для каждой строки некоторое перключение контекста выполнения(проверял на Оракле, но я не представляю как эту особенность обойти), это значительно сокращает производительность batch обработки(наподобие INSERT SELECT, UPDATE многих строк, MERGE, DELETE многих строк). Ситуация становиться хуже, если триггера не идеально написаны. Я вкусил триггерный ад по полной и, думаю, что представляю, о чем говорю. Некоторые мои коллеги пришли из банкоской сферы(разрабатывали АБС) и их мнение полностью совпадало с моим по поводу триггеров. Я всецело поддерживаю наличие слоя храннимых процедур, где идеально размещать логику работы с (большими) масивами данных, и инкапулировать обращения к БД, скрывая детали реализации. Я полностью "за" наличие как можно большего числа ограничений целостноти на БД (они не только данные выверяют, но и помогают оптимизатору), но вот с триггерами ни как не могу подружиться. Извиняюсь, за дискуссию. Но именно в ней, вроде как, должна зарождаться истина. :) Еще раз спасибо за выступление!

Алексей Свитин «Как-то я занимался детальным анализом производительности системы...» А как именно вы оценивали вклад триггеров? Интересно, что с чем сравнивали

1. Трассировка. По трейсам видно сколько времени уходит на выполнение тех или иных запросов в рамках триггеров, а сколько на саму операцию модификации строки. Анализировал трейсы через OraSRP. 2. Профилировка. По ней можно понять сколько времени каждая строка PL/SQL кода выполнялась. Имея итоговое время выполнения запроса можно посчитать влияние триггера. Использовал самописные запросы для анализа HProfiler таблиц. Ничего нормального в сети на тот момент не нашел. 3. Созавал много копий идентичных структур с одинаковым набором данных. Затем накидывал FK, индексы, констренты, триггера в разных комбинациях на эти копии. И проводил тесты построчной вставки (с включенной и выключенной FOR оптимизацией), BULK вставки, обновлений и удалений. Но основной упор был на вставку, так как там основная логика. Разница с триггерами и без была настолько огромной, что сама операция размещения стоки в таблице составляла ничтожную долю процента относительно общего времени выполнения. Если бы вместо триггеров использовалась пакетная обработка(вставка идет именно блоками данных) через хранимки( у того же Оракла с этим все очень хорошо), и логика была бы разделена( а не смешана в триггеры на все случаи жизни) то по моему скромному мнению, производительность была значительно выше. Но уйти от триггеров, когда их много и основная логика в них , это очень сложная задача.

Ну надо смотреть, конечно, что конкретно в тех триггерах было. На мой взгляд, метка «триггеры=зло» это то же самое, что и «транзакции=зло». Давайте переформулируем. «Длинные транзакции - зло» и «долгие триггеры - зло». Интересно, конечно, какой оверхед на инсёрт даёт триггер-пустышка в Оракле. Для постгреса я по-быстрому проверил, вышло в районе 6%: Ок, у нас есть некоторый триггер, который что-то делает с данными. 6% оверхед на то, что он просто существует. Плюс какой-то (скорее всего бОльший) оверхед, если он что-то ещё и по правде делает. Конечно, особенно, если при этом участвуют другие таблицы. Теперь мысленно представим, что мы делаем то же самое, но на уровне приложения. Вот тут кроится забавное - очень часто разработчики делают операции с данными намного менее оптимально, чем если бы это было в триггере. СУБД относительно мало что стоит прогуляться за данными в какой-нибудь индекс. Или пересчитать данные у себя. В случае слоя приложения очего легко наступить на грабли сетевой сложности. Мой основной тезис в том, что надо сначала рассматривать работу ближе к данным. Нет, не всегда. Но ОЧЕНЬ часто. Нужно анализировать, конечно. Кроме того, если вам нужно быстро провести транзакцию, ну закиньте задание в отдельную таблицу и разгребайте её асинхронно (с помощью "select ... for update skip locked" это делается очень эффективно в несколько потоков). Асинхронные транзакции в Оракле тоже помогают такие схемы иметь, а сегодня вот в Постгрес 11 закоммитили (ура!) www.postgresql.org/message-id/E1edcRB-0004zs-B6@gemulon.postgresql.org И ещё. Вы правильно отмечаете, что часто нужно батчами работу вести для эффективности. Верно. Только это ж никак не конфликтует с работой на стороне СУБД и триггерами. Наоборот. Для этого есть statement-based triggers, правда, работать с ними можно стало нормально только недавно, с 10ки, когда добавили transition tables www.depesz.com/2017/06/02/waiting-for-postgresql-10-implement-syntax-for-transition-tables-in-after-triggers/ > Если бы вместо триггеров использовалась пакетная обработка похоже, на это ответил предыдущим абзацем > и логика была бы разделена( а не смешана в триггеры на все случаи жизни) а вот тут не очень понимаю. Наверное, речь про пакеты ? Это, конечно, очень многие просят - на юзервойсе тема номер 1 postgresql.uservoice.com/forums/21853-general

а не напомните контекст?

www.slideshare.net/samokhvalov/database-first, www.pgcon.org/2013/schedule/attachments/269_tour-of-postgresql-data-types.pdf andreas.scherbaum.la/writings/Tour_de_Data_Types_-_FOSDEM_2017.pdf

Всё смешалось. Написано почти без грамматических ошибок, но логика не прослеживается, какой-то клубок мыслей. Кто сказал, что между целостностью и микросервисами надо выбирать что-то одно? Смотрите на опыт Zalando, было много на Highload. Кстати, советовать всем подряд микросервисную архитектуру - медвежья услуга, послушайте внимательно тех же Zalando. Далее, кто сказал, что тестами не нужно покрывать хранимки? Sqitch, pgTap или же любой ваш любимый фреймворк + анонимный plpgsql-код (do $$ ... $$ language plpgsql) и всё уезжает в CI. Дебаг - есть дебаггер для pl/pgsql, но честно, когда вы последний раз пользовались именно дебаггером, а не принтлайнингом для вашего любимого python/ruby/java/php? Строгая схема (там, где есть возможность её задать), ограничения целостности и хранимки - не враги, а помощники для быстрорастущего проекта.

Как обычно, в CI. pgTap, sqitch / verify, анонимные конструкции do $$ ... $$ language plpgsql, в них используйте assert с продуманными сообщениями.