uuid замедляет ваши приложения и сайты
Вставка
- Опубліковано 26 вер 2024
- Использование чисел для создания ключей и индексов в базах данных считается не безопасным. Самым популярным вариантом сегодня является использование uuid4. И не смотря на то, что у них большое количество плюсов, такие идентификаторы данных могут очень сильно замедлять работу приложений, и программисты во время разработки этого не заметят.
НЕТ ВОЙНЕ!
Выразить благодарность
ko-fi.com/larc...
boosty.to/larc...
yoomoney.ru/to...
BTC: 127J5x79L9bb7T4jiYJ2U7jHNDLXEx4kT3
USDT (TRC20): TWRQit8o1JJGWjAph3DZFysygUxSwqiq9Q
TON: UQBDiFGDTLpp1zWLefv0LnH9TbEeUIcPSoO5uDNwhzktKP33
Как я стал программистом
• КАК Я СТАЛ ПРОГРАММИСТОМ
Как я переехал в Европу
• Как я переехал в Европу
Стрим: Карьера программиста
• Карьера программиста: ...
VPN, который я использую
get.surfshark....
➡️ Сайт: i.mobila.name/xT
➡️ Instagram: i.mobila.name/yp
➡️ Twitter: i.mobila.name/Ua
➡️ Telegram: i.mobila.name/b7d
👉🏻 Больше влогов здесь:
#larchankavlog #larchanka
👉🏻 Ежедневные влоги:
#larchankadaily
👉🏻 Чем я снимаю:
➡️ iPhone 14 Pro
➡️ Еще одна камера: DJi Osmo Action
➡️ Еще одна камера: Sony DSC-WX500
Музыка:
Summer's Hot (Clean Version) - Katori Walker
Echoes of Eternity - Tellsonic
- Папа, я просто хотел поиграть в машинки...
А потом он создаст ai и заставит сына бороться за первенство
А папа матерится, и говорит что автоинкремент в его базе данных не безопастный
Хоть не авиомоделирование, а то там бы автопилот начал бы делать и все
Пока не выйдет стабильная альфа приложухи - никаких машинок!!
@@ThePamidor пока на приложухе не будет ляма скачиваний - никаких машинок
uuid нужен не для безопасности, а чтобы гарантировать что в распределенных системах данные можно будет склеить без спецэффектов, особенно всё что связано с "оффлайн" режимом (например генерировать связанные по uuid данные в разных таблицах на клиентах, а потом синхронизировать в общую базу, например в iot это повсеместно или например в ритейле, где касса может пробивать чеки в оффлайне, а потом синхронизироваться с сервером)
вот правильно, снимает какую-то чушь
Про data enumeration не слышали? Ну вот и не пишите тогда комментарии не разобравшись
@@CuriousSpy без вас разберусь, что и где мне писать )
БОКС!
опять все переделывать
По-моему автоинкремент не безопасен только в случаях, когда нужно избежать возможности перебора. Например пользователей. Если же данные по кругам и заездам являются полностью открытой информацией, то не вижу ничего плохого в автоинкременте.
Он не удобен
@@eugenefedoryachenko8793чем?
А с хера ли автоинкремент небезопасен? Если контроля доступа нет, то это и есть опасность. А если вместо контроля доступа прятать данные за случайным айдишником, то это тупость. Права поменялись, а доступ остался? Ссылка утекла и заходи кто хочет?
@@IgorYegorkin Можно начать с того, что злоумышленник просто поймет столько у тебя юзеров в базе и это использовать в своих целях. Например в переборе юзернеймов. Но это так, минор. Это в видео и сказали, он предсказуем.
Еще он вызывает гонку за ресурсами при большом большом количестве вставки данных в базу.
Автоинкримент имеет свойство заканчиваться, так же с ним нужны бубны в случае если часть данных будет утеряна и при восстановлении последовательность нарушится.
И ты вообще пробовал хоть раз делать запрос с автоинкриментами? Особенно когда у тебя куча джоинов и в качестве id ты используешь какие-то непонятные циферки, которые зачастую одинаковые.
@eugenefedoryachenko8793 если использовать один и тот же sequence для таблицы юзеров и любой другой таблицы, то это сразу закроет путь к определению количества юзеров. Если логины можно перебирать, то это не проблема хранения записей.
Не понимаю, о какой гонке с ресурсами речь, если СУБД десятилетиями работали с автоинкремент нами полями и всё было нормально.
Автоинкремент не может закончиться, если он типа long (64 бита).
Просто замечательный аргумент, чтобы вместо более-менее коротких цифровых идентификаторов использовать длиннющие случайные строки - так, конечно, понятнее будет))
Всю жизнь работал с автоинкрементными полями и со смесью даты с автоинкрементом. Никаких проблем с написанием запросов.
Замените, пожалуйста, заголовок на "UUIDv4 замедляет ваши приложения и сайты", чтобы не вводить людей в заблуждение, так как это всё не имеет никакого отношения к UUIDv7😡
Не упомянули про uuid v7, его как раз удобно использовать для шардирования
Заметил, что часто за завтраком смотрю ваши видео. По времени идеально подходят и не перегружено информацией
@@МаксимРудин-р3м так у него же нет видео на канале 😂
Так это как раз вариация с временой и рандомной частью. Как функция, показанная в ролике. Это вдруг резко стало небезопасно 🤷♂
@@Dmittry ютуб решил отправить мне уведомление о том, что вы оставили этот комментарий. Наверно он что-то очень важное несёт для меня
@@widny31 Судя по тому, что вас нет в этой ветке, ваш комментарий заблокировали.
ожидал бенчмарка, а тут какая-то демагогия
І так з усіма останніми відео.
Випуск відео заради викладання відео
Для начала нужно опреоелиться, какой опасности вы пытаетесь избежать. Если вам нужно избежать несанкционированного доступа к объекту, то uuid для айдишников тут не поможет. Не надо безбумно применять модные паттерны.
4:25 о какой базе данных речь? Реляционные базы не будут ничего "перекластеризовывать" при добавлении, да и при удалении и редактировании тоже. Каждой записи в таблице базой в любом случае будет выдан скрытый целочисленный идентификатор, который иногда может совпадать с видимым.
Видимо, он говорит про индексирование
А если айди генерируется на клиенте? А если я хочу гарантировать отсутствия совпадений и коллизий? а если я не хочу думать о том что я переполню когданибудь счетчик?)
На клиенте его генерить будто небезопасно. Так же можно что угодно отправить в БД.
@@Владимир.П-е9о без ID тоже можно что угодно отправить. Разница будет только в том, что ID могут дублироваться, но это тоже не проблема, можно либо игнорировать либо перезаписывать зависит от ситуации.
В свое время Михаил Задорнов сказал следующее - "Никогда не говори со сцены то, за что тебе было бы стыдно перед твоей матерью!" Рядом с этой надписью можно поместить высказывание Михаила Ларченко - "Никогда не пиши код, который тебе было бы стыдно выложить на Гитхаб!" 😀
о интересную тему затронули, действительно проблеммы с uuid начинаются на таблицах с миллионнами строк, а еще индексы с uuid тоже довольно много места занимают...
Никто не запрещает вам использовать то и другое одновременно, внутри сервиса обычный bigint выставляя данные наружу с uuid aka external id
Плюсы uuid в том, что можно создать инстанс доменного объекта сразу с известным Id, не завися от базы данных или её отсутствия.
ролик ниочем. экономия на спичках.
У него 99% роликов ни о чем
Смотрю вы голубчик тот еще мазохист раз смотрите то что вам не заходит
@@котток-г6й что кому заходит это по твоему заднеприводному профилю
Ну как ни о чём. В этой серии узнали, что гонки будут.
@@MsTim159 обоснуй
5:39 а как же индексация? вместо автоинкрементируемого id можно использовать timestamp условный "created_at" они тоже по очереди идут
интересно приолжение с машинками посмотреть теперь) как сделал чтоб камера счиытвала цвет??
Миша, чем обрабатывал видео и анализировал цвет машинки?
Opencv скорее всего
Можно решить медленный поиск индексом. Время записи пострадает чутка, а вот поиск будет довольно быстрым
UUID - глобально уникальный идентификатор, и единственный минус атоинкремента перед uuid это в том, что нет этой самой глобальной уникальности. То есть, если вы не планируете шардинг, чтобы масштабировать свои данные на несколько баз данный, то вам такая уникальность не нужна. В рамках одной БД счетчик автоинкремента свою работу выполняет на 100%, и во всех прочих аспектах с интами работать проще чем с uuid.
У нас как раз оптимизаторы убрали ууид в одном проекте , все хорошо но по логам стало бегать невозможно , откудаттам замедление не знаю, это только если счет идет на микросекунды , генерация без оптимизации занимала 100us если память не изменяет.
@@balabolrustam507 предполагаю, у вас был какой-то локальный побочный эффект, не связанный напрямую с заменой uuid на int. Единственное несущественное замедление при использовании автоинкремента возможно только на этапе insert, когда нужно обеспечить блокировку при генерации нового id.
типа данные о заездах это пример супер конфиденциальных данных?
и они ну никак не уживутся с обычными целочисленными ключами?
Типу набити руку роблячи канонічно на іграшковому проекті, щоб на потім реальному зробити як слід.
@@TishSerg "як слид" это без оверинжиниринга, конкретно здесь UUID не нужен. Набивать руку здесь негде - сменить тип ключа можно в любой момент.
UUID не обязательно должны быть полностью случайными. В качестве примера, часто предлагается брать часть первых битов (те же самые, например, первые 32 бита) от текущего временного штампа, а остальное - генерировать случайно. Таким образом, БД сможет сравнивать и упорядочивать записи по времени. А новые записи всегда будут добавляться в конец.
Не использовать 128-битные числа вместо 32-битных, в то время как в большинстве БД основную часть места занимают всякие строки, где каждый символ уже будет занимать 16 бит - это уже экономия на спичках. Современные БД позволяют сравнивать 128-битные числа аппаратно между собой без дополнительных программных преобразований.
UUID это все еще числа, но они не увеличиваются на +1, и их не надо парсить.
Может быть, UUID в каких-то определенных БД и проигрывают по производительности простым целым инкрементирующимся числам, однако в результате 10-минутного гугления я не нашел убедительного сравнения на этот счет. Сравнивались методы построения UUID (и полученные производительности), или говорилось опять же что "ну знаете, у нас вот тут случайные UUID, они занимают больше места, а еще вставляются в случайный кластер", но вот именно сравнение производительности обычного инкремента и хорошо построенного UUID - я сходу не нашел.
Прикольно, не знал таких нюансов 👍
2:25 говорит, что автоинкремент считается небезопасным. Просто считается и все, а потом кто-нибудь скажет, что считается кем-то из этого видео. В качестве индексируемого поля GUID плох тем, что индекс вынужден из-за него быстро фрагментироваться, а особенно, если кто-то хочет генерировать его не на стороне базы данных, а самостоятельно.
Для того, чтобы выбрать между автоинкременом и GUID нужно четко понимать, для чего производится выбор, универсального решения в данном случае нет.
2:52 "uniqid" две ошибки в одном названии вместо "uniqueId".
Лайк в поддержку канала
купи ребенку компик и скачайте фолыч с рутрекера
У автоинкремента есть проблема - ты не можешь её сгенерить на стороны аппы, особенно, если у тебя кластерное приложение. Id ты узнаешь только после вставки строки (кстати, я даже не интересовался как в mysql эта семантика работает в случае с батчами, например). Ещё автоинкремент не подходит для шардированных данных.
хз,даже для POS приложения оставляю пока bigint (в PG) поле (если точнее то bigserial) а вот для транзакций уже использую время ориентированный уид (самописный уид в7,когда он еще был РС) он также хорошо индексируется
Где проект, дайте сдать пул реквест!
Не приходилось вам ебстись со сбитыми последовательностями и сформированными наборами данных в таблицах.
Но в целом подход правильный - если система локальная для одного разраба, а то и одного пользователя, то uuid - избыточен. А генерация уникального идентификатора на клиенте очень помоагет в некоторых случаях работы с данными на бэке.
Можно код считалки гонки?
Чё то я не особо понял почему автоинкремент это не безопасно, тип из-за перебора так а почему нельзя ограничить вывод информации из бд даже для перебора и настроить несколько уровней доступа, что бы условный перебор не работал? Может кто в кратце пояснить?
Допустим магазин, и сделав заказ в начале и конце дня, можно понять сколько было заказов в день, есть сферы где конкуренты могут понять сколько заказов или чего то другого проходит в день, неделю или, и может дать какое либо преимущество. Это не большой объем, но в некоторых случаях может быть важно его скрыть. Примерно такая ситуация. В партнёрках обычно пытаются скрыть эти цифры.
ты забыл упомянуть почему считается не безопасным - только в том случае, если у вас есть публичный api по этим ID. например есть профиль юзера который по ID показывается. Но есть другие способы решать эту проблему. UUID нужен для распределенных систем да и только :)
для твоего кейса будто монго подходит, ведь у тебя толком реляционности нет, скорее куча документов - записей кругов, как история
А в чем проблема, если ID в апи используется?
@@TalkerTube можешь просто инкрементируя стянуть всех юзеров
Ого , не сложное приложение 😅
Звучик классно
А зачем внешняя база данных для машинок, если можно хранить записи локально в браузерной IndexedDB?
чтобы не быть привязанным к браузеру
Так у него всё равно же браузерное приложение. Ну можно сделать экспорт/импорт, если хочется переносимости.
@@ОнуфрийНечепуренкотогда все будет привязано к одному браузеру (даже к одному профилю в браузере)
Если испоьзовать 4 версию, то да, замедляеся, и так же нормально ни в индекс не ляжет испльзуйте 6 или 7 версию как написали выше. А так же хранить данные строкой странно, бинарными данными хранить, то будет всего 16 бит, отличие от bigint всего в 2 раза.
- uuid замедляет ваше приложение
*пишет код на JS*
Я не буду обьяснять насколько дурная чуш в видео - просто скажу, что не увидел ни одного перфоманс теста на озвученные предположения.
Мне точно так же в начале карьеры пытались доказать что "SQL джойны медленные". Если у вас тормозит база - значит вы не умеете её готовить.
Там разве проблема не с записью? Когда БД приходится смещать данные на файлах страниц физического носителя, чтобы вставить запись в рандомное место.
100% должны быть uuid которые monotonically increase чтобы решить проблему database index
Конкретному инструменту конкретное применение. В иных случаях при планировании бэка и бд волосы дыбом встают от мысли использовать в качестве ключа автоинкрементный счетчик)
Недавно писал приложение с возможностью работы как в онлайн, так и оффлайн режимах. Создание сущности на клиенте в оффлайне приводит к необходимости проверки коллизий при синхронизации и коррекции ключевых значений (ужас ужасный). Uuid явно более применим.
Я правильно понял, если приложение пользователя создаст записи без подключения к интернету при помощи итерации чисел, то это может привести к тому что и в бд будут такие же id, и такая проблема называется коллизией, а если всегда генерируется уникальное значение то коллизии не будет? 😮
А что если, на стороне клиента, если нет интернета, то генерировать временные Id, но при синхронизации с бд, в бд создавать новые id, это может решить проблему? Или есть что то
@@СултанАбдрахманов-ц2ю я бы скорее сказал, что при uuid коллизии маловероятны, но с автоинкрементным числовым счетчиком они гарантированы)
@@СултанАбдрахманов-ц2ю об этом я написал в «необходимость проверки коллизий при синхронизации». Если 4 пользователя с последним id=1000 из сетевой бд отвалятся и создадут по 2 сущности, то сущностей станет на 8 больше, необходимо будет гарантированно провести n*(m-1) коррекций (условно у 3 из 4 пользователей отредактировать каждую оффлайн-сущность). Вероятность же совпадения хотя бы двух uuid из 8 весьма низка.
@@СултанАбдрахманов-ц2ю Менять ID у существующей записи - это всегда гемор, который хочется избежать... Потому что недостаточно поменять ID только у одной этой записи. У всех записей, которые ссылаются на изменяемую надо тоже обновить ссылки
Ну можно предсказать и что? Безопасность надо делать на другом
Утекает на сторону бизнес метрика - кол-во заказов или пользователей
Бла бла бла,
Никаких доказательств. Использую uuid во всех проектах. Никакий проблем не замечено.
что-то не очень понял логику типа функционал определения цветов неидеален, но пойдёт, тк для домашних целей, а простой инкремент в бд не устроил, тк уже небезопасно 🤔
загрузил = лайк получи
может ребенок не может найти фаллаут 3 из-за того, что эта игра старше него...
но предыдущие купил!))
Какая тебе нафиг безопасность нужна в этом приложении, зачем переусложнять все. А если нужна безопасность, поверх внутренних ID можно навертеть логику публичных ID. UUID нужны не для этого. А для того чтобы можно было генерировать их отдельно от базы. Если это не требуется, то и UUID не нужны.
generate time based UUIDs
Что??? UUID уже не хэшируются? Их уже нельзя использовать в хэш-таблицах? Нельзя быстрый поиск там, сортировку по ним делать? В сегодняшнем 64-битном мире 128 бит UUID это очень тяжелая структура? Накладно ее в базе данных хранить, где нужны абсолютно уникальные идентификаторы? Серьезно? Машинки будут медленнее регистрироваться и база данных домашних гонок распухнет до террабайтов из-за UUID?
Ююид тоже много что показывает - идентифицирует "источник" - часть юида ни когда не меняется в конкретной системе, часть просьо инкрементируется. Так что ююид это вообще не про безопасность а про шардинг.
о вы наверное не в курсе, но есть разные версии uuid и как раз uuid версии 4 - наверное самой популярной версии, рандомно генерируемый и не содержит ни информации о времени создания ни о машине которая его сгенерировала...
UUID7 (7-й версии) спасет отца голландской демократии!
uuid только для внешнего взаимодействия
А в чём не безопасность цифрового детерминанта? Какая проблема сделать SQL запрос select max(id), и в ручную увеличивать на единицу? Опять же uuid, штуковина которая нужна для распределительных систем, если один и тот же сайт висит на 50-ти серверах, и INSERT запрос может случиться на любом из них. При числовом id, при синхронизации будут коллизии. Можно вообще вычислять по sha256, абсолютно уникальный hash на 64 символа. Но ещё раз возникает вопрос, зачем оно нужно, если система не распределённая?
Sha256 вычисление затратное, а uuid нужен чтоб сразу получить идентификатор в асинхронном режиме и уже с ним работать,
При автоинкременте id не будет коллизий, вы же не в приложении его генерируете, субд сама возвращает следующее число
_"Какая проблема сделать SQL запрос select max(id), и в ручную увеличивать на единицу?"_ в том что на таблицу нужно навесить блокировку на чтение и запись, за такое в банке отведут в комнату без окон, где доступно объяснят что так делать не надо.
@@xyzw777 Может объясните доступно в чём проблема то? Если id не уникальный в таблице, на уровне СУБД запись не будет добавлена в таблицу. Только и всего. Какая разница автоинкрементом вы id увеличиваете или в ручную?
@@tolb1517 Это большая проблема, что записи не будут добавлены из-за существующей id. Представьте, что приложению одновременно нужно добавить 100 записей, пользуясь описанным вами методом, все 100 потоков запрашивают select max(id) и получают одно и то же число, и только один поток сможет добавить запись. Остальным 99 потокам придется проходить этот цикл заново. Автоинкремент отличается от этого тем, что он использует генераторы последовательности (sequence), гарантирующие уникальность каждого выдаваемого числа.
Более менее современный код, это код который 99% всего времени делает какую то хрень вместо полезной работы.
очередной наркоман в своём делирии нашёл ответ на вопрос жизни, вселенной и всего
6-ти минутное видео, укладывающиеся в два слова "uuidv4 медленный". Можно ещё двух часовое видео "почему fgets - опасно"?
зачем..?
Все это очень сомнительно по поводу скорости. Когда база данных будет делить на кучки при создании индексов, то разница между делением числа (id) или строки (uuid) будет не такая большая как мне кажется. В любом случае проще забить миллион другой записей в базу и потестить. Но судя по этому ролику у вас весьма скромные познания в базах данных.
uuid - это 128-битное целое, а не строка. Просто имеет представление в в шестнатеричном виде, но БД его хранит как целое.
Кто видел Кисо, ставь лайк! 😂
с ююд4 можно получить время, уже не безопасно
с uuid4 нельзя получить время
Миша, на тебе свитер висит как на вешалке.. 😮 Тебе мешок картошки из Беларусии прислать?
Ну и балабол! Дядя ты тесты и цифры предъяви! На таблицах до 1М разница не более 5% по моим расчетам.
Что за бред он несет?
та всі випадкові числа, які генерує комп'ютер не є випадковими на 100%.
быстрее удаляйте этот ролик. Такое ощущение что вы отец одиночка с грудным ребенком, от недосыпа кукухой поехали.
Монолитные решения не используют uid. Там слой сохранения всем всё присваивает. Для DDD решений uid обязателен. Не во всех агрегатах та же структура вложенности сущностей. Потому связывать их событиями не так то просто без uid, нужно тогда организовывать функции проекции айдишника в событии из одного аггрегата на другие. А это засорение логики домена, раздувание исходного кода и куча багов. За такие ролики вас могли бы и уволить в нормальной компании. да и при вложенности сущностей в структуру аггрегата скажем тремя слоями полный ид нижней сущности без использования uid будет уже не 32 бита а 3х32
сочувствую
Что такое DDD решения?
То что кого-то уволят это ваша шиза?
🤡🤡🤡
@@АлександрМамзиков-х1у domain driven design, в некоторых источниках его называют microcore
"автоинкрементные id небезопасны для домашней поделки для учета гонок машинок". Дальше можно не смотреть.
const getUID = ((count, last_time, last_uid) => () => {
const time = (new Date).getTime();
if(time === last_time) {
return last_uid + '-' + (count++);
}
count = 0;
last_time = time;
return last_uid = time.toString(36);
})(0);
а еще можно немножко подумать и прийти к просветлению что:
1) не обязательно и текущий онлайн гонки и статистику по прошлым гонкам хранить в одной структуре
2) структура данных и тип таблиц для статистики и текущего онлайна не обязательно должна быть одна и таже. я даже больше скажу - єто совершенно разные задачи.
и т.д. и т.п.
Автор или тот, чью статью он пересказывает, не понимают, зачем нужен UUID, и критикуют использование ID. Если у вас много систем и хотя бы две базы данных, правильно использовать уникальный ключ. Данные могут храниться в разных местах, но утверждение о том, что обычный инкремент небезопасен, является необоснованным без конкретных примеров.
Если система работает медленно, можно улучшить её производительность различными способами: добавить индексы, обновить оборудование или выбрать другую базу данных, которая лучше подходит для быстрого ввода и хранения данных с последующей обработкой. Использование UUID в проекте может показаться излишним, особенно если не ясна цель его применения. Важно чётко понимать, зачем нужно то или иное решение, а не просто добавлять функции без необходимости.
Что мешает шифровать числовой индекс? Будет сохранено уникальное 32 битное число, но со скрытием его исходного значения (если надо было скрыть количество или порядок).
Авто инкремент безопасен, просто не отправляй его на фронт а используй слаг
А в чём смысл? Всё равно потом придётся искать по слагу, который будет тем же uuid
Главное uuid как key не использовать в React приложениях ))
Nano UUID можно на меньшее кол-во знаков