Про "из базы данных никогда ничего не нужно удалять" расскажите DBA. Они любят когда у них место на дисках заканчивается, а в базе лежит гора непонятно чего, которое уже несколько лет как не используется (а может и вообще никогда не использовалось).
@ruzarh11 күн бұрын
Если идновременно ведет разработку продукта 30 человек, и связи достаточно сложные, то с таким подходом контролировать состояние становится очень сложно и появляется энтропия. Fk же начинает давать гарантии. Автор приводит пример crud, в которых это избыточно. Но в сложных системах где нет хайлоада, но есть сложная модель данных, гарантии очень важны. Там же где база не может запуститься без кешей, и запуск идет по повышению процентов от трафика, постепенный запуск, в таких системах fk конечно не подойдет, т.к. 5-6% нагрузки который дает fk это слишком дорого. Бред полный видео, человек делал совсем не погрузившись в тему и матчасть.
@matthewdubrovin12 күн бұрын
Постоянно используется каскадное удаление и проверка целостности при вставке. Иногда когда система только разрабатывается - разработчики косячат и вставляют кривые несуществующие данные. Когда система отточена FK обычно убирают, чтобы снизить нагрузку на БД.
@moshpi737513 күн бұрын
мдэ..... похоже в универе предложили плюшки за доклад. бред полный
@user-mz6xs3eq7w13 күн бұрын
Ужасный доклад. Масса "э...", "а...", сглатываний. Очень много воды и совершенно очевидной информации, которая для тех, кто хочет услышать что-то полезное, явно хорошо известная, а потому не требующая разжевывания. Доклад можно было бы сократить раза в 4, как минимум. Ну и в целом тема доклада осталась нераскрытой. Просто перечислены некоторые свойства системы, описание терминов, а о чем доклад-то был, собственно?
@andrewshilov419714 күн бұрын
Подача храмает
@VyveVern14 күн бұрын
вообще ничего не понял) я думал суть доклада в том, как именно решать какие-то сложные аналитические задачи) а получилась просто презентация кликхаус)
@user-xd1su3sk3i10 күн бұрын
Добро пожаловать в современный ИТ. 1 инженер на 15 долбо... будущих менеджеров.
@user-zl1zv9wi3m14 күн бұрын
Прикольно! Тинькофф узнал, что есть Clickhouse =) Доклад, честно говоря, вообще ни о чем. Зайти в документацию на 15 минут и прочитать вводное - весь доклад. Причем в доке больше будет написано. Рассказанный паттерн - уже лет 10 применяется в BigData. В чем восторг - пока непонятно =(
@user-ly8tk8gt9t14 күн бұрын
спасибо за доклад!
@pawsdev15 күн бұрын
FK - это констрейнт, нужен констрейнт - юзаем, не нужен - не юзаем
@bigmouseToto16 күн бұрын
Докладчик путает физическую и логическую модель данных. Append-only и soft-delete - это паттерны логические. FK же физическая.
@peteribragimov507112 күн бұрын
FK используется для гарантирования логической модели, мой тезис был в том, что FK не достаточен для большинства ситуаций, а также в том, что он и не нужен для гарантий.
@alexeykalyanov58819 күн бұрын
Про "связи" полный бред и совсем не обоснован! Садитесь 2!
@QazaqCode19 күн бұрын
5 минут о том какая postgre плохая, а потом, ну мы юзаем postgre
@Cfk47FsvfujGr5d420 күн бұрын
Хоть бы пару примеров привели. Запретили похоже, боятся 😂, очень очень поверхностно получилось.
@user-gi4qu9do2v21 күн бұрын
Послушал 10 мин - спикер не особо понимает, о чем говорит. Доклад - копирка первой попавшейся статьи из интернета
@jonkarmok184021 күн бұрын
Согласен
@lostinthewhitesea15 күн бұрын
а в чем проблема? я просто не в теме) это не для начинающих была конфа?)
@user-gi4qu9do2v15 күн бұрын
@@lostinthewhitesea не важно для кого конфа. Спикер читает по методичке евангелистов микросервисов, которая давно устарела (и все поняли, что она во многом врет). При этом монолит рассматривается как нечто мертвое как концепция и не понимает, что он тоже может горизонтально масштабироваться.
@ivormacky507822 күн бұрын
Какие выводы, Тинькофф - говно, докладчик - ламер, изучайте академический курс проектирования БД, а не хватайте по верхушкам и будете без проблем создавать сложные архитектуры!
@pucyhok22 күн бұрын
Так, а что такое кликхаус? Аутсорс за который надо платить?
@user-pv8dx4kb6n22 күн бұрын
Опенсорс база данных
@pucyhok22 күн бұрын
Короче её не надо покупать? Надо свои бд из столбчатых в строковые перевести или начать строить?
@DAJakaRedAries20 күн бұрын
@@pucyhok покупать не надо, можно из своих БД закинуть данные в Clickhouse
@qweone12319 күн бұрын
@@pucyhok Гугл и чатгпт в бане
@user-gh3tx2jv7b23 күн бұрын
Никогда не видел подобного айтишника, чтобы выступал прям так на легке и все так классно рассказывал)
@MaruiInfantry21 күн бұрын
Вчера райзнули до 700к на руки. Вот и веселый.
@evgeniy_toropchin24 күн бұрын
гит как успешный пример аппенд онли :D
@kinso185724 күн бұрын
когда уже монолит МИСИС перепишут на микросервисы, ждем всем селом....
@denis.pershin26 күн бұрын
В смысле данные не удаляем? А что насчет 152-ФЗ, по которому любой пользователь может обратиться к любому оператору персональных данных и попросит удалить его данные. Пометим deleted: true? Не получится. В Европе и США законы еще строже, и данные должны быть физически удаленны с серверов даже без запроса, например когда пользователь больше не оплачивает подписку на вашем сервисе, то есть данные не нужны больше для тех целей, ради которых были созданы. Доклад как будто из реалий 2000 года. Пахнуло ностальгией :)
@peteribragimov507125 күн бұрын
По ФЗ-152, GDPR и тд можно просто анонизировать имя, почту и телефон. ВСЁ. Вы не обязаны удалять историю платежей, историю покупок и все остальное
@peteribragimov507125 күн бұрын
Я даже больше скажу. В РФ, да и в других странах, правоохранительные органы/менты часто просят дать информацию по тем или иным пользователям, даже если они удалились
@denis.pershin22 күн бұрын
@@peteribragimov5071 понял принял
@user-mz6xs3eq7w19 күн бұрын
Обычно данные анонимизируют, а не удаляют. Так как в противном случае данные станут несогласованными в связанных таблицах. А удалять их еще и в связанных таблицах может быть весьма проблематичным. Например, эти данные могут участвовать в отчете по кассе или еще где-то. То есть такие данные мы просто не можем удалить. И тогда что делать? Просто глупо заводить какую-то анонимную запись и заменять на её идентификатор во всех таблицах. Значительно проще просто обновить персональные данные пользователя (клиента), затерев их каким-то специальным набором символов, шаблоном и так далее.
@denis.pershin19 күн бұрын
@@user-mz6xs3eq7w в таком случае главно понимать, что одним изменением таблицы users/accounts можно не обойтись, клиент мог "наследить" своими данными где угодно, например в чате с поддержкой и тд. Получается, что потребуется точно такая же процедура как по удалению, найти все активности юзера и затереть.
@_dzen_tv_27 күн бұрын
Append-only и Soft-Delete ни как не конфликтует с Foreign-Key. Прямого ответа почему Foreign-Key в базе - зло нет. Спич оторван от реальности. Как часто нужно обновлять данные, как часто удалять. Стоит ли забивать канал БД лишними запросами или как можно больше работы выполнить в базе. В общем то Append-only и Soft-Delete хорошие практики, а про Foreign-Key похоже на вброс какахи.
@peteribragimov507127 күн бұрын
FK замедляют работу СУБД, при этом гарантируют консистентность только в том случае, если кто-то залезает в базу и нарушает консистеность, либо не проверяет ее вручную на беке (что и так делать надо)
@alexeykalyanov58819 күн бұрын
@@peteribragimov5071 а проверка вручную не замедляет работу? если вы пытаетесь влепить id пользователя которого нет, то без связи по ключам перед вставкой нужно делать выборку что займет больше времени. вообще в таких спичах нужны замеры, тем более что товарищ озвучил разные субд...
@igor821918 күн бұрын
@@peteribragimov5071 то что делать проверки на бэке надо, это понятно. Но здесь у тебя есть хотя бы запасной парашют ввиде БД, а тут получается ты сам, без страховки. Как по мне, риск появления неконсистентного стейта в системе на порядки выше. В команде работают люди разной компетенции, хотя и синьоры много ошибаются. Эту идею можно развить, сказав, что и тесты тоже зло и не нужны, ведь они так же не гарантируют отсутствие багов.
@dmitryduzhinsky273916 күн бұрын
@@peteribragimov5071 бэкендов много, в базу лезут и вручную, данные подкачиваются со сторонних источников. Проверить целостность данных на беке можно только лишь выкачав из базы связанные данные, что излишне. Зачем изобретать велосипед у себя в бэкенде, если согласованность данных можно обеспечить за счет готового универсального решения?
@user-be2jl4wm2n16 күн бұрын
@@peteribragimov5071 Так у вас есть FK для проверки, ну то есть звучит в докладе как - мы просто напишем свой FK (реализуем все проверки которые он делает) и будем иметь больше гибкости так как это наше решение. Возможно в каких-то исключительных случаях написание кастомных проверок на беке вместо использования готового решения и норм, но в общем случае лучше использовать уже готовое универсальное решение поставляемое БД
@senior_of_cs28 күн бұрын
интересно почему FK тогда создавались и так долго остаются в использовании? Инерция? ))
@peteribragimov507127 күн бұрын
Инерция, плюс нужно иметь очень высокие нагрузки, чтобы FK давал заметную нагрузки
@TechBusinessDev29 күн бұрын
Когда в таблице появятся заказы, которые ссылаются на несуществующих юзеров я на него посмотрю) Иногда ты не можешь проверять наличие строки в связанной таблице так как часто приходится делать батч инсерты или апсерты Ну или кто-то как всегда залезет руками в базу и сотворит херню В общем, если по производительности ничего не проседает, я все таки рекомендую внешние ключи для согласованности данных
@peteribragimov507127 күн бұрын
1. Если кто-то залезает в БД руками - эти руки надо оторвать:). 2. Нарушить консистентность бизнес-процессов через обход бекенд можно вне зависимости от того, есть FK или нет. Скажем можно зайти в БД и понизить стоимость заказа. Или, например, накинуть себе баланса. 3. Проверять корректность инпутов в любом случае надо. Если, скажем, мы создаем заказ на 100 человек на 1000 позиций, то нам в любом случае надо проверить, что все эти 100 человек есть, они имеют право получить заказать указанные товары и тд. При этом менять айдишники - плохая практика, поэтому мы можем быть уверены, что значения будут корректными
@TechBusinessDev25 күн бұрын
@@peteribragimov5071 1. В базу лезут все всегда. Даже те кто обещает, что не залезет. Это просто факт, с которым надо смириться и учитывать. Ну конечно в финтехе каком-нибудь с этим построже, но в большенстве компаний думаю всем насрать. 2. Да, можно, но это не повод давать еще больше возможностей все сломать. 3. Проверять то нужно и все проверяют весь ввод пользователя и все такое. Но вот скрипты, которые запускаются по крону и делают сложные штуки не будут проверять так как это долго. Какая нибудь статистика не будет проверять. Какая-нибудь джоба чтобы быстрее выполниться не будет проверять. Какой-нибудь джун накосячит. Сам случайно накосячишь. А потом в коде вызываешь order->user->id и получаешь в лоб исключение, что юзера нет)
@TechBusinessDev25 күн бұрын
@@peteribragimov5071 1. В базу лезут все всегда. Даже те кто обещает, что не залезет. Это просто факт, с которым надо смириться и учитывать. Ну конечно в финтехе каком-нибудь с этим построже, но в большенстве компаний думаю всем насрать. 2. Да, можно, но это не повод давать еще больше возможностей все сломать. 3. Проверять то нужно и все проверяют весь ввод пользователя и все такое. Но вот скрипты, которые запускаются по крону и делают сложные штуки не будут проверять так как это долго. Какая нибудь статистика не будет проверять. Какая-нибудь джоба чтобы быстрее выполниться не будет проверять. Какой-нибудь джун накосячит. Сам случайно накосячишь. А потом в коде вызываешь order->user->id и получаешь в лоб исключение, что юзера нет)
@doctorw25 күн бұрын
@@peteribragimov5071 если в бд через триггеры везде стоят запреты, то фиг ты поменяешь стоимость заказа. Если достаточно плотно обложить всё ограничениями и проверками, то испортить данные можно будет только имея высокие привилегии в бд.
@bigmouseToto16 күн бұрын
@@peteribragimov5071 Отрывание рук никак не поможет решит уже существующую проблему с удалёнными данными. Нужно максимально заботиться о целостности данных. Всегда. Наивно думать, что никто не сделает "плохо" или "неправильно". Обязательно сделает. И вы потеряете данные. А вот кому после этого руки отрывать - это тоже вопрос. Возможно тем, кто отказывается от fk, потому что они "медленные" или "устаревшие".
Пікірлер
ни о чем
Про "из базы данных никогда ничего не нужно удалять" расскажите DBA. Они любят когда у них место на дисках заканчивается, а в базе лежит гора непонятно чего, которое уже несколько лет как не используется (а может и вообще никогда не использовалось).
Если идновременно ведет разработку продукта 30 человек, и связи достаточно сложные, то с таким подходом контролировать состояние становится очень сложно и появляется энтропия. Fk же начинает давать гарантии. Автор приводит пример crud, в которых это избыточно. Но в сложных системах где нет хайлоада, но есть сложная модель данных, гарантии очень важны. Там же где база не может запуститься без кешей, и запуск идет по повышению процентов от трафика, постепенный запуск, в таких системах fk конечно не подойдет, т.к. 5-6% нагрузки который дает fk это слишком дорого. Бред полный видео, человек делал совсем не погрузившись в тему и матчасть.
Постоянно используется каскадное удаление и проверка целостности при вставке. Иногда когда система только разрабатывается - разработчики косячат и вставляют кривые несуществующие данные. Когда система отточена FK обычно убирают, чтобы снизить нагрузку на БД.
мдэ..... похоже в универе предложили плюшки за доклад. бред полный
Ужасный доклад. Масса "э...", "а...", сглатываний. Очень много воды и совершенно очевидной информации, которая для тех, кто хочет услышать что-то полезное, явно хорошо известная, а потому не требующая разжевывания. Доклад можно было бы сократить раза в 4, как минимум. Ну и в целом тема доклада осталась нераскрытой. Просто перечислены некоторые свойства системы, описание терминов, а о чем доклад-то был, собственно?
Подача храмает
вообще ничего не понял) я думал суть доклада в том, как именно решать какие-то сложные аналитические задачи) а получилась просто презентация кликхаус)
Добро пожаловать в современный ИТ. 1 инженер на 15 долбо... будущих менеджеров.
Прикольно! Тинькофф узнал, что есть Clickhouse =) Доклад, честно говоря, вообще ни о чем. Зайти в документацию на 15 минут и прочитать вводное - весь доклад. Причем в доке больше будет написано. Рассказанный паттерн - уже лет 10 применяется в BigData. В чем восторг - пока непонятно =(
спасибо за доклад!
FK - это констрейнт, нужен констрейнт - юзаем, не нужен - не юзаем
Докладчик путает физическую и логическую модель данных. Append-only и soft-delete - это паттерны логические. FK же физическая.
FK используется для гарантирования логической модели, мой тезис был в том, что FK не достаточен для большинства ситуаций, а также в том, что он и не нужен для гарантий.
Про "связи" полный бред и совсем не обоснован! Садитесь 2!
5 минут о том какая postgre плохая, а потом, ну мы юзаем postgre
Хоть бы пару примеров привели. Запретили похоже, боятся 😂, очень очень поверхностно получилось.
Послушал 10 мин - спикер не особо понимает, о чем говорит. Доклад - копирка первой попавшейся статьи из интернета
Согласен
а в чем проблема? я просто не в теме) это не для начинающих была конфа?)
@@lostinthewhitesea не важно для кого конфа. Спикер читает по методичке евангелистов микросервисов, которая давно устарела (и все поняли, что она во многом врет). При этом монолит рассматривается как нечто мертвое как концепция и не понимает, что он тоже может горизонтально масштабироваться.
Какие выводы, Тинькофф - говно, докладчик - ламер, изучайте академический курс проектирования БД, а не хватайте по верхушкам и будете без проблем создавать сложные архитектуры!
Так, а что такое кликхаус? Аутсорс за который надо платить?
Опенсорс база данных
Короче её не надо покупать? Надо свои бд из столбчатых в строковые перевести или начать строить?
@@pucyhok покупать не надо, можно из своих БД закинуть данные в Clickhouse
@@pucyhok Гугл и чатгпт в бане
Никогда не видел подобного айтишника, чтобы выступал прям так на легке и все так классно рассказывал)
Вчера райзнули до 700к на руки. Вот и веселый.
гит как успешный пример аппенд онли :D
когда уже монолит МИСИС перепишут на микросервисы, ждем всем селом....
В смысле данные не удаляем? А что насчет 152-ФЗ, по которому любой пользователь может обратиться к любому оператору персональных данных и попросит удалить его данные. Пометим deleted: true? Не получится. В Европе и США законы еще строже, и данные должны быть физически удаленны с серверов даже без запроса, например когда пользователь больше не оплачивает подписку на вашем сервисе, то есть данные не нужны больше для тех целей, ради которых были созданы. Доклад как будто из реалий 2000 года. Пахнуло ностальгией :)
По ФЗ-152, GDPR и тд можно просто анонизировать имя, почту и телефон. ВСЁ. Вы не обязаны удалять историю платежей, историю покупок и все остальное
Я даже больше скажу. В РФ, да и в других странах, правоохранительные органы/менты часто просят дать информацию по тем или иным пользователям, даже если они удалились
@@peteribragimov5071 понял принял
Обычно данные анонимизируют, а не удаляют. Так как в противном случае данные станут несогласованными в связанных таблицах. А удалять их еще и в связанных таблицах может быть весьма проблематичным. Например, эти данные могут участвовать в отчете по кассе или еще где-то. То есть такие данные мы просто не можем удалить. И тогда что делать? Просто глупо заводить какую-то анонимную запись и заменять на её идентификатор во всех таблицах. Значительно проще просто обновить персональные данные пользователя (клиента), затерев их каким-то специальным набором символов, шаблоном и так далее.
@@user-mz6xs3eq7w в таком случае главно понимать, что одним изменением таблицы users/accounts можно не обойтись, клиент мог "наследить" своими данными где угодно, например в чате с поддержкой и тд. Получается, что потребуется точно такая же процедура как по удалению, найти все активности юзера и затереть.
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, потому что они "медленные" или "устаревшие".
Вау, спасибо!
Красавчик!
Доклад пушка)
Очень круто!