Why foreign keys are Evil. Append-Only and Soft-Delete - Peter Ibragimov | ITAM: BACKEND MEETUP
Vložit
- čas přidán 14. 05. 2024
- Append-only, Soft-Delete, and other reasons why Foreign Keys are evil in databases
Presented by Peter Ibragimov (Whoosh)
Timestamps:
00:00 Opening Remarks / Peter Ibragimov (Whoosh)
01:02 DELETE query to the database
04:12 Should data even be deleted from the DB? (No)
05:30 Soft-Delete approach
06:27 Append-only approach
09:18 Foreign key and its purpose
12:11 Conclusions
IT AT MISIS:
Telegram: itatmisis
VK: itatmisis
Web: itatmisis.ru
#itatmisis #itam #misis #database #backend #whoosh #meetup
Постоянно используется каскадное удаление и проверка целостности при вставке.
Иногда когда система только разрабатывается - разработчики косячат и вставляют кривые несуществующие данные.
Когда система отточена FK обычно убирают, чтобы снизить нагрузку на БД.
FK - это констрейнт, нужен констрейнт - юзаем, не нужен - не юзаем
В смысле данные не удаляем? А что насчет 152-ФЗ, по которому любой пользователь может обратиться к любому оператору персональных данных и попросит удалить его данные. Пометим deleted: true? Не получится. В Европе и США законы еще строже, и данные должны быть физически удаленны с серверов даже без запроса, например когда пользователь больше не оплачивает подписку на вашем сервисе, то есть данные не нужны больше для тех целей, ради которых были созданы.
Доклад как будто из реалий 2000 года. Пахнуло ностальгией :)
По ФЗ-152, GDPR и тд можно просто анонизировать имя, почту и телефон. ВСЁ. Вы не обязаны удалять историю платежей, историю покупок и все остальное
Я даже больше скажу. В РФ, да и в других странах, правоохранительные органы/менты часто просят дать информацию по тем или иным пользователям, даже если они удалились
@@peteribragimov5071 понял принял
Обычно данные анонимизируют, а не удаляют. Так как в противном случае данные станут несогласованными в связанных таблицах. А удалять их еще и в связанных таблицах может быть весьма проблематичным. Например, эти данные могут участвовать в отчете по кассе или еще где-то. То есть такие данные мы просто не можем удалить. И тогда что делать? Просто глупо заводить какую-то анонимную запись и заменять на её идентификатор во всех таблицах. Значительно проще просто обновить персональные данные пользователя (клиента), затерев их каким-то специальным набором символов, шаблоном и так далее.
@@user-mz6xs3eq7w в таком случае главно понимать, что одним изменением таблицы users/accounts можно не обойтись, клиент мог "наследить" своими данными где угодно, например в чате с поддержкой и тд. Получается, что потребуется точно такая же процедура как по удалению, найти все активности юзера и затереть.
Про "из базы данных никогда ничего не нужно удалять" расскажите DBA. Они любят когда у них место на дисках заканчивается, а в базе лежит гора непонятно чего, которое уже несколько лет как не используется (а может и вообще никогда не использовалось).
мдэ..... похоже в универе предложили плюшки за доклад. бред полный
Вау, спасибо!
гит как успешный пример аппенд онли :D
Append-only и Soft-Delete ни как не конфликтует с Foreign-Key.
Прямого ответа почему Foreign-Key в базе - зло нет.
Спич оторван от реальности. Как часто нужно обновлять данные, как часто удалять. Стоит ли забивать канал БД лишними запросами или как можно больше работы выполнить в базе.
В общем то Append-only и Soft-Delete хорошие практики, а про Foreign-Key похоже на вброс какахи.
FK замедляют работу СУБД, при этом гарантируют консистентность только в том случае, если кто-то залезает в базу и нарушает консистеность, либо не проверяет ее вручную на беке (что и так делать надо)
@@peteribragimov5071 а проверка вручную не замедляет работу? если вы пытаетесь влепить id пользователя которого нет, то без связи по ключам перед вставкой нужно делать выборку что займет больше времени. вообще в таких спичах нужны замеры, тем более что товарищ озвучил разные субд...
@@peteribragimov5071 то что делать проверки на бэке надо, это понятно. Но здесь у тебя есть хотя бы запасной парашют ввиде БД, а тут получается ты сам, без страховки. Как по мне, риск появления неконсистентного стейта в системе на порядки выше. В команде работают люди разной компетенции, хотя и синьоры много ошибаются.
Эту идею можно развить, сказав, что и тесты тоже зло и не нужны, ведь они так же не гарантируют отсутствие багов.
@@peteribragimov5071 бэкендов много, в базу лезут и вручную, данные подкачиваются со сторонних источников. Проверить целостность данных на беке можно только лишь выкачав из базы связанные данные, что излишне. Зачем изобретать велосипед у себя в бэкенде, если согласованность данных можно обеспечить за счет готового универсального решения?
@@peteribragimov5071 Так у вас есть FK для проверки, ну то есть звучит в докладе как - мы просто напишем свой FK (реализуем все проверки которые он делает) и будем иметь больше гибкости так как это наше решение. Возможно в каких-то исключительных случаях написание кастомных проверок на беке вместо использования готового решения и норм, но в общем случае лучше использовать уже готовое универсальное решение поставляемое БД
интересно почему FK тогда создавались и так долго остаются в использовании? Инерция? ))
Инерция, плюс нужно иметь очень высокие нагрузки, чтобы FK давал заметную нагрузки
Когда в таблице появятся заказы, которые ссылаются на несуществующих юзеров я на него посмотрю)
Иногда ты не можешь проверять наличие строки в связанной таблице так как часто приходится делать батч инсерты или апсерты
Ну или кто-то как всегда залезет руками в базу и сотворит херню
В общем, если по производительности ничего не проседает, я все таки рекомендую внешние ключи для согласованности данных
1. Если кто-то залезает в БД руками - эти руки надо оторвать:).
2. Нарушить консистентность бизнес-процессов через обход бекенд можно вне зависимости от того, есть FK или нет. Скажем можно зайти в БД и понизить стоимость заказа. Или, например, накинуть себе баланса.
3. Проверять корректность инпутов в любом случае надо. Если, скажем, мы создаем заказ на 100 человек на 1000 позиций, то нам в любом случае надо проверить, что все эти 100 человек есть, они имеют право получить заказать указанные товары и тд. При этом менять айдишники - плохая практика, поэтому мы можем быть уверены, что значения будут корректными
@@peteribragimov5071
1. В базу лезут все всегда. Даже те кто обещает, что не залезет. Это просто факт, с которым надо смириться и учитывать. Ну конечно в финтехе каком-нибудь с этим построже, но в большенстве компаний думаю всем насрать.
2. Да, можно, но это не повод давать еще больше возможностей все сломать.
3. Проверять то нужно и все проверяют весь ввод пользователя и все такое. Но вот скрипты, которые запускаются по крону и делают сложные штуки не будут проверять так как это долго. Какая нибудь статистика не будет проверять. Какая-нибудь джоба чтобы быстрее выполниться не будет проверять. Какой-нибудь джун накосячит. Сам случайно накосячишь. А потом в коде вызываешь order->user->id и получаешь в лоб исключение, что юзера нет)
@@peteribragimov5071
1. В базу лезут все всегда. Даже те кто обещает, что не залезет. Это просто факт, с которым надо смириться и учитывать. Ну конечно в финтехе каком-нибудь с этим построже, но в большенстве компаний думаю всем насрать.
2. Да, можно, но это не повод давать еще больше возможностей все сломать.
3. Проверять то нужно и все проверяют весь ввод пользователя и все такое. Но вот скрипты, которые запускаются по крону и делают сложные штуки не будут проверять так как это долго. Какая нибудь статистика не будет проверять. Какая-нибудь джоба чтобы быстрее выполниться не будет проверять. Какой-нибудь джун накосячит. Сам случайно накосячишь. А потом в коде вызываешь order->user->id и получаешь в лоб исключение, что юзера нет)
@@peteribragimov5071 если в бд через триггеры везде стоят запреты, то фиг ты поменяешь стоимость заказа. Если достаточно плотно обложить всё ограничениями и проверками, то испортить данные можно будет только имея высокие привилегии в бд.
@@peteribragimov5071 Отрывание рук никак не поможет решит уже существующую проблему с удалёнными данными. Нужно максимально заботиться о целостности данных. Всегда. Наивно думать, что никто не сделает "плохо" или "неправильно". Обязательно сделает. И вы потеряете данные. А вот кому после этого руки отрывать - это тоже вопрос. Возможно тем, кто отказывается от fk, потому что они "медленные" или "устаревшие".
Если идновременно ведет разработку продукта 30 человек, и связи достаточно сложные, то с таким подходом контролировать состояние становится очень сложно и появляется энтропия. Fk же начинает давать гарантии. Автор приводит пример crud, в которых это избыточно. Но в сложных системах где нет хайлоада, но есть сложная модель данных, гарантии очень важны. Там же где база не может запуститься без кешей, и запуск идет по повышению процентов от трафика, постепенный запуск, в таких системах fk конечно не подойдет, т.к. 5-6% нагрузки который дает fk это слишком дорого.
Бред полный видео, человек делал совсем не погрузившись в тему и матчасть.
Докладчик путает физическую и логическую модель данных. Append-only и soft-delete - это паттерны логические. FK же физическая.
FK используется для гарантирования логической модели, мой тезис был в том, что FK не достаточен для большинства ситуаций, а также в том, что он и не нужен для гарантий.
Про "связи" полный бред и совсем не обоснован! Садитесь 2!