2 ай бұрын
2 ай бұрын
2 ай бұрын
Пікірлер
@Alexander-ws6wl 6 күн бұрын
Я не разработчик, но волею Ютуба тут оказался. Кто-нибудь может объяснить, почему для тех, кто хранит (открывает) БД в Docker-контейнере, заготовлено отдельное место в аду? :)
@user-cc8lf6lc4s 17 күн бұрын
ни о чем
@user-cu4ez6hf5e 20 күн бұрын
Про "из базы данных никогда ничего не нужно удалять" расскажите DBA. Они любят когда у них место на дисках заканчивается, а в базе лежит гора непонятно чего, которое уже несколько лет как не используется (а может и вообще никогда не использовалось).
@ruzarh 24 күн бұрын
Если идновременно ведет разработку продукта 30 человек, и связи достаточно сложные, то с таким подходом контролировать состояние становится очень сложно и появляется энтропия. Fk же начинает давать гарантии. Автор приводит пример crud, в которых это избыточно. Но в сложных системах где нет хайлоада, но есть сложная модель данных, гарантии очень важны. Там же где база не может запуститься без кешей, и запуск идет по повышению процентов от трафика, постепенный запуск, в таких системах fk конечно не подойдет, т.к. 5-6% нагрузки который дает fk это слишком дорого. Бред полный видео, человек делал совсем не погрузившись в тему и матчасть.
@matthewdubrovin 25 күн бұрын
Постоянно используется каскадное удаление и проверка целостности при вставке. Иногда когда система только разрабатывается - разработчики косячат и вставляют кривые несуществующие данные. Когда система отточена FK обычно убирают, чтобы снизить нагрузку на БД.
@moshpi7375 25 күн бұрын
мдэ..... похоже в универе предложили плюшки за доклад. бред полный
@user-mz6xs3eq7w 25 күн бұрын
Ужасный доклад. Масса "э...", "а...", сглатываний. Очень много воды и совершенно очевидной информации, которая для тех, кто хочет услышать что-то полезное, явно хорошо известная, а потому не требующая разжевывания. Доклад можно было бы сократить раза в 4, как минимум. Ну и в целом тема доклада осталась нераскрытой. Просто перечислены некоторые свойства системы, описание терминов, а о чем доклад-то был, собственно?
@andrewshilov4197 26 күн бұрын
Подача храмает
@VyveVern 27 күн бұрын
вообще ничего не понял) я думал суть доклада в том, как именно решать какие-то сложные аналитические задачи) а получилась просто презентация кликхаус)
@user-xd1su3sk3i 22 күн бұрын
Добро пожаловать в современный ИТ. 1 инженер на 15 долбо... будущих менеджеров.
@user-zl1zv9wi3m 27 күн бұрын
Прикольно! Тинькофф узнал, что есть Clickhouse =) Доклад, честно говоря, вообще ни о чем. Зайти в документацию на 15 минут и прочитать вводное - весь доклад. Причем в доке больше будет написано. Рассказанный паттерн - уже лет 10 применяется в BigData. В чем восторг - пока непонятно =(
@user-ly8tk8gt9t 27 күн бұрын
спасибо за доклад!
@pawsdev 28 күн бұрын
FK - это констрейнт, нужен констрейнт - юзаем, не нужен - не юзаем
@bigmouseToto 28 күн бұрын
Докладчик путает физическую и логическую модель данных. Append-only и soft-delete - это паттерны логические. FK же физическая.
@peteribragimov5071 24 күн бұрын
FK используется для гарантирования логической модели, мой тезис был в том, что FK не достаточен для большинства ситуаций, а также в том, что он и не нужен для гарантий.
@alexeykalyanov588 Ай бұрын
Про "связи" полный бред и совсем не обоснован! Садитесь 2!
@QazaqCode Ай бұрын
5 минут о том какая postgre плохая, а потом, ну мы юзаем postgre
@Cfk47FsvfujGr5d4 Ай бұрын
Хоть бы пару примеров привели. Запретили похоже, боятся 😂, очень очень поверхностно получилось.
@user-gi4qu9do2v Ай бұрын
Послушал 10 мин - спикер не особо понимает, о чем говорит. Доклад - копирка первой попавшейся статьи из интернета
@jonkarmok1840 Ай бұрын
Согласен
@lostinthewhitesea 27 күн бұрын
а в чем проблема? я просто не в теме) это не для начинающих была конфа?)
@user-gi4qu9do2v 27 күн бұрын
@@lostinthewhitesea не важно для кого конфа. Спикер читает по методичке евангелистов микросервисов, которая давно устарела (и все поняли, что она во многом врет). При этом монолит рассматривается как нечто мертвое как концепция и не понимает, что он тоже может горизонтально масштабироваться.
@ivormacky5078 Ай бұрын
Какие выводы, Тинькофф - говно, докладчик - ламер, изучайте академический курс проектирования БД, а не хватайте по верхушкам и будете без проблем создавать сложные архитектуры!
@pucyhok Ай бұрын
Так, а что такое кликхаус? Аутсорс за который надо платить?
@user-pv8dx4kb6n Ай бұрын
Опенсорс база данных
@pucyhok Ай бұрын
Короче её не надо покупать? Надо свои бд из столбчатых в строковые перевести или начать строить?
@DAJakaRedAries Ай бұрын
@@pucyhok покупать не надо, можно из своих БД закинуть данные в Clickhouse
@qweone123 Ай бұрын
@@pucyhok Гугл и чатгпт в бане
@user-gh3tx2jv7b Ай бұрын
Никогда не видел подобного айтишника, чтобы выступал прям так на легке и все так классно рассказывал)
@MaruiInfantry Ай бұрын
Вчера райзнули до 700к на руки. Вот и веселый.
@evgeniy_toropchin Ай бұрын
гит как успешный пример аппенд онли :D
@kinso1857 Ай бұрын
когда уже монолит МИСИС перепишут на микросервисы, ждем всем селом....
@denis.pershin Ай бұрын
В смысле данные не удаляем? А что насчет 152-ФЗ, по которому любой пользователь может обратиться к любому оператору персональных данных и попросит удалить его данные. Пометим deleted: true? Не получится. В Европе и США законы еще строже, и данные должны быть физически удаленны с серверов даже без запроса, например когда пользователь больше не оплачивает подписку на вашем сервисе, то есть данные не нужны больше для тех целей, ради которых были созданы. Доклад как будто из реалий 2000 года. Пахнуло ностальгией :)
@peteribragimov5071 Ай бұрын
По ФЗ-152, GDPR и тд можно просто анонизировать имя, почту и телефон. ВСЁ. Вы не обязаны удалять историю платежей, историю покупок и все остальное
@peteribragimov5071 Ай бұрын
Я даже больше скажу. В РФ, да и в других странах, правоохранительные органы/менты часто просят дать информацию по тем или иным пользователям, даже если они удалились
@denis.pershin Ай бұрын
@@peteribragimov5071 понял принял
@user-mz6xs3eq7w Ай бұрын
Обычно данные анонимизируют, а не удаляют. Так как в противном случае данные станут несогласованными в связанных таблицах. А удалять их еще и в связанных таблицах может быть весьма проблематичным. Например, эти данные могут участвовать в отчете по кассе или еще где-то. То есть такие данные мы просто не можем удалить. И тогда что делать? Просто глупо заводить какую-то анонимную запись и заменять на её идентификатор во всех таблицах. Значительно проще просто обновить персональные данные пользователя (клиента), затерев их каким-то специальным набором символов, шаблоном и так далее.
@denis.pershin Ай бұрын
@@user-mz6xs3eq7w в таком случае главно понимать, что одним изменением таблицы users/accounts можно не обойтись, клиент мог "наследить" своими данными где угодно, например в чате с поддержкой и тд. Получается, что потребуется точно такая же процедура как по удалению, найти все активности юзера и затереть.
@_dzen_tv_ Ай бұрын
Append-only и Soft-Delete ни как не конфликтует с Foreign-Key. Прямого ответа почему Foreign-Key в базе - зло нет. Спич оторван от реальности. Как часто нужно обновлять данные, как часто удалять. Стоит ли забивать канал БД лишними запросами или как можно больше работы выполнить в базе. В общем то Append-only и Soft-Delete хорошие практики, а про Foreign-Key похоже на вброс какахи.
@peteribragimov5071 Ай бұрын
FK замедляют работу СУБД, при этом гарантируют консистентность только в том случае, если кто-то залезает в базу и нарушает консистеность, либо не проверяет ее вручную на беке (что и так делать надо)
@alexeykalyanov588 Ай бұрын
@@peteribragimov5071 а проверка вручную не замедляет работу? если вы пытаетесь влепить id пользователя которого нет, то без связи по ключам перед вставкой нужно делать выборку что займет больше времени. вообще в таких спичах нужны замеры, тем более что товарищ озвучил разные субд...
@igor8219 Ай бұрын
@@peteribragimov5071 то что делать проверки на бэке надо, это понятно. Но здесь у тебя есть хотя бы запасной парашют ввиде БД, а тут получается ты сам, без страховки. Как по мне, риск появления неконсистентного стейта в системе на порядки выше. В команде работают люди разной компетенции, хотя и синьоры много ошибаются. Эту идею можно развить, сказав, что и тесты тоже зло и не нужны, ведь они так же не гарантируют отсутствие багов.
@dmitryduzhinsky2739 29 күн бұрын
@@peteribragimov5071 бэкендов много, в базу лезут и вручную, данные подкачиваются со сторонних источников. Проверить целостность данных на беке можно только лишь выкачав из базы связанные данные, что излишне. Зачем изобретать велосипед у себя в бэкенде, если согласованность данных можно обеспечить за счет готового универсального решения?
@user-be2jl4wm2n 28 күн бұрын
@@peteribragimov5071 Так у вас есть FK для проверки, ну то есть звучит в докладе как - мы просто напишем свой FK (реализуем все проверки которые он делает) и будем иметь больше гибкости так как это наше решение. Возможно в каких-то исключительных случаях написание кастомных проверок на беке вместо использования готового решения и норм, но в общем случае лучше использовать уже готовое универсальное решение поставляемое БД
@senior_of_cs Ай бұрын
интересно почему FK тогда создавались и так долго остаются в использовании? Инерция? ))
@peteribragimov5071 Ай бұрын
Инерция, плюс нужно иметь очень высокие нагрузки, чтобы FK давал заметную нагрузки
@TechBusinessDev Ай бұрын
Когда в таблице появятся заказы, которые ссылаются на несуществующих юзеров я на него посмотрю) Иногда ты не можешь проверять наличие строки в связанной таблице так как часто приходится делать батч инсерты или апсерты Ну или кто-то как всегда залезет руками в базу и сотворит херню В общем, если по производительности ничего не проседает, я все таки рекомендую внешние ключи для согласованности данных
@peteribragimov5071 Ай бұрын
1. Если кто-то залезает в БД руками - эти руки надо оторвать:). 2. Нарушить консистентность бизнес-процессов через обход бекенд можно вне зависимости от того, есть FK или нет. Скажем можно зайти в БД и понизить стоимость заказа. Или, например, накинуть себе баланса. 3. Проверять корректность инпутов в любом случае надо. Если, скажем, мы создаем заказ на 100 человек на 1000 позиций, то нам в любом случае надо проверить, что все эти 100 человек есть, они имеют право получить заказать указанные товары и тд. При этом менять айдишники - плохая практика, поэтому мы можем быть уверены, что значения будут корректными
@TechBusinessDev Ай бұрын
@@peteribragimov5071 1. В базу лезут все всегда. Даже те кто обещает, что не залезет. Это просто факт, с которым надо смириться и учитывать. Ну конечно в финтехе каком-нибудь с этим построже, но в большенстве компаний думаю всем насрать. 2. Да, можно, но это не повод давать еще больше возможностей все сломать. 3. Проверять то нужно и все проверяют весь ввод пользователя и все такое. Но вот скрипты, которые запускаются по крону и делают сложные штуки не будут проверять так как это долго. Какая нибудь статистика не будет проверять. Какая-нибудь джоба чтобы быстрее выполниться не будет проверять. Какой-нибудь джун накосячит. Сам случайно накосячишь. А потом в коде вызываешь order->user->id и получаешь в лоб исключение, что юзера нет)
@TechBusinessDev Ай бұрын
@@peteribragimov5071 1. В базу лезут все всегда. Даже те кто обещает, что не залезет. Это просто факт, с которым надо смириться и учитывать. Ну конечно в финтехе каком-нибудь с этим построже, но в большенстве компаний думаю всем насрать. 2. Да, можно, но это не повод давать еще больше возможностей все сломать. 3. Проверять то нужно и все проверяют весь ввод пользователя и все такое. Но вот скрипты, которые запускаются по крону и делают сложные штуки не будут проверять так как это долго. Какая нибудь статистика не будет проверять. Какая-нибудь джоба чтобы быстрее выполниться не будет проверять. Какой-нибудь джун накосячит. Сам случайно накосячишь. А потом в коде вызываешь order->user->id и получаешь в лоб исключение, что юзера нет)
@doctorw Ай бұрын
@@peteribragimov5071 если в бд через триггеры везде стоят запреты, то фиг ты поменяешь стоимость заказа. Если достаточно плотно обложить всё ограничениями и проверками, то испортить данные можно будет только имея высокие привилегии в бд.
@bigmouseToto 28 күн бұрын
@@peteribragimov5071 Отрывание рук никак не поможет решит уже существующую проблему с удалёнными данными. Нужно максимально заботиться о целостности данных. Всегда. Наивно думать, что никто не сделает "плохо" или "неправильно". Обязательно сделает. И вы потеряете данные. А вот кому после этого руки отрывать - это тоже вопрос. Возможно тем, кто отказывается от fk, потому что они "медленные" или "устаревшие".
@user-ly8tk8gt9t Ай бұрын
Вау, спасибо!
@alexanderpliskin1875 Ай бұрын
Красавчик!
@denissin2067 Ай бұрын
Доклад пушка)
@DaniilKim-is2oh Ай бұрын
Очень круто!