UUID

Yoskaldyr

"Спамер"
Партнер клуба
Так у перконы давно был мануал как оптимизировать uuid, но даже после оптимизаций сильно жирное поле для примари ключа. и можно даже короче чем после этой функции (можно оптимизировать, ведь начало uuid на одном компе всегда одинаковое). А задача стоит как раз для одного компа :)
А вообще я бы задал вопрос о целесообразности использования мыскля :D
ну тут "маемо, що маемо"...
 

AmdY

Пью пиво
Команда форума
Всё понимается в сравнении. Табличка slag to uuid будет у тебя занимать 1% от остальных данных, на которые этот самый uuid ссылается. Если у тебя проблемы с ней, то что будет с остальной частью системы?
 

Yoskaldyr

"Спамер"
Партнер клуба
@AmdY Когда нибудь приходилось обновлять большие btree индексы на мускуле?

Особенно вставка или удаление больших пачек, особенно если удаляемые данные по которым ключ разрежены. И памяти дофига и свободных ядер дофига, а загрузка 100% на одном ядре и запрос выполняется 20-30 минут с практически полным локом таблицы.
Не всегда кривую архитектуру базы можно пофиксить серверными мощностями. Все прелести вылазят на списках больше пары миллионов. Да если железо мощнее типа ксеонов голд и т.п., то вылезет на 5 лямах, но все равно вылезет.

Конечно разовые вставки и селекты по индексу работают норм и на слабом железе. Но вот любой альтер затрагивающий индексы или большая пакетная вставка или удаление - это жопа. И не забываем о копии примари в каждый доп индекс, т.е. каждый новый индекс будет увеличивать время перестройки индексов раза в 2 при жирном примари. Самое смешное что при таких объемах фултекст индекс работает даже быстрее b-tree (при условии автоинкремент примари)

И это мускуль какой он есть при использовании обычных b-tree индексов.
 

fixxxer

К.О.
Партнер клуба
Так у перконы давно был мануал как оптимизировать uuid, но даже после оптимизаций сильно жирное поле для примари ключа. и можно даже короче чем после этой функции (можно оптимизировать, ведь начало uuid на одном компе всегда одинаковое). А задача стоит как раз для одного компа :)
Нет :)

uuid прекрасен как раз тем, что его можно запросто генерировать на клиенте.
 

Yoskaldyr

"Спамер"
Партнер клуба
да, ошибся, не начало, а конец (и да если используется таймстамп генерация), но суть не меняет.
как пример
если так хранить то почти то же что обычный автоинкремент бигинта с точки зрения времени запросов.
после оптимизации (выкидываем перманентную часть, т.к. сервер один) можно добить почти до производительности до обычного инта.
Единственное что в этой статье странно, что сравнивают таблицы где единичные примари индексы по uuid (2 вида) с таблицей где примари бигинт и вспомогательный uuid.

uuid прекрасен как раз тем, что его можно запросто генерировать на клиенте.
Если под клиентом подразумевается пхп, то да - можно, т.к. мы контролируем генерацию. если подразумевается именно клиент, то только когда мобильное приложение, но если обычный веб, то сгенериванному uuid-у просто нельзя доверять.
 

fixxxer

К.О.
Партнер клуба
Если под клиентом подразумевается пхп, то да - можно, т.к. мы контролируем генерацию. если подразумевается именно клиент, то только когда мобильное приложение, но если обычный веб, то сгенериванному uuid-у просто нельзя доверять.
Это еще почему? Тебе в API заведомо может прилететь что угодно, какая разница? Нельзя доверять в той же мере, в какой нельзя доверять любым входным данным.

С генерацией UUIDv4 в браузере все нормально. Web Crypto API отлично работает даже в IE11. Никто же не предлагает через Math.random.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
Это уже религиозное неприятие UUID.
Во-первых, UUID не разряжены, во-вторых, alter таблиц с парой миллионов записей выполняется нормально.
Делаешь SELECT INTO в новую таблицу, ставишь триггер, ночью переименовываешь. Или https://www.percona.com/doc/percona-toolkit/3.0/pt-online-schema-change.html
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
В тему альтернативы UUID.
Я у себя вместо UUID переделываю autoincrement на "$userId.$timestamp", и вместо binary храню в decimal(20,10).
Просто, наглядно, тот же UUID, только в профиль, валидируется по is_numeric(), меньше индекс. URI мне не нужен, но вспомнил про эту тему. Первые "15" из timestamp можно спокойно выкинуть.
 

Вурдалак

Продвинутый новичок
В тему альтернативы UUID.
Я у себя вместо UUID переделываю autoincrement на "$userId.$timestamp", и вместо binary храню в decimal(20,10).
Просто, наглядно, тот же UUID, только в профиль, валидируется по is_numeric(), меньше индекс. URI мне не нужен, но вспомнил про эту тему. Первые "15" из timestamp можно спокойно выкинуть.
Даже с microtime высока вероятность коллизии в общем случае. А в UUID, который первой версии и который можно упорядочить для оптимизации, там microtime (если точнее, там десятая доля microtime даже, но в PHP такую точность не получить, поэтому последний разряд обычно 0) + 8 байт рандома.

UPD: а, userId не заметил. Но тоже ситуационно.
 
Последнее редактирование:

grigori

( ͡° ͜ʖ ͡°)
Команда форума
да, я это для upload файлов делаю - юзер больше одного файла в секунду не зальет, а если это бот, то пошел он, файл просто перепишется

я ограничен по api - в id надо отдавать int, десктопный клиент написан на С и ждет целое, а переделывать его - out of scope для моей задачи
 

fixxxer

К.О.
Партнер клуба
я ограничен по api - в id надо отдавать int, десктопный клиент написан на С и ждет целое
Это вынужденная альтернатива. Я тоже много где вынужденные костыли клепаю, но зачем про это рассказывать? :)

Не вижу вообще никаких проблем с UUID, вот вообще. Все эти performance issues надуманные, современные СУБД на современном железе позволяют об этом вообще не думать. Затраты на суппорт плохо спроектированного кода на порядок превышают затраты на железо. Если не на два.
 

fixxxer

К.О.
Партнер клуба
v4, поскольку на клиенте тоже могут генерироваться. Вероятность коллизий считаю пренебрежимо малой.
 

Вурдалак

Продвинутый новичок
Так и с v1 коллизий будет пренебрежительно мало, зато будет timestamp, иногда полезный.
 

fixxxer

К.О.
Партнер клуба
С v1 надо думать, как корректно реализовать все это в браузере: что сунуть в node id, корректно ли локальное время, ревьюить существующие реалиации, - мне лень это все делать, а в v4 тупо рандом, все просто.
 

Вурдалак

Продвинутый новичок
Ну как бы не тупо рандом. В смысле, там как минимум есть несколько бит под версию и несколько зарезервированных бит. Если ты тупо делаешь 128 бит рандома, то лучше это называть GUID.

А как хранишь (если речь про MySQL)?
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
Это вынужденная альтернатива. Я тоже много где вынужденные костыли клепаю, но зачем про это рассказывать? :)

Не вижу вообще никаких проблем с UUID, вот вообще. Все эти performance issues надуманные, современные СУБД на современном железе позволяют об этом вообще не думать. Затраты на суппорт плохо спроектированного кода на порядок превышают затраты на железо. Если не на два.
предлагаешь не рассказывать о ситуативных решениях? 🤷‍♂️ это не костыль, это легаси
человек жаловался на длину значения
 

Yoskaldyr

"Спамер"
Партнер клуба
Все эти performance issues надуманные, современные СУБД на современном железе позволяют об этом вообще не думать.
Вот это самая большая ошибка многих даже высококвалифицированных программистов. Надо знать как оно храниться на стороне базы. И вот у мускуля на Innodb при лямах строк и доп индексах с этим могут возникнуть проблемы при определенных сценариях. И тут железо не сильно помогает, т.к. проблема single core bound. Сейчас в основном увеличивают производительность за счет увеличения количества ядер, а не за счет увеличения скорости ядра и проблемы сильного изменения очень жирных б-три индексов есть во всех базах, но вот иннобд с его клонированием примари во все вторичные индексы наверное впереди всех остальных.

Ничего не могу сказать насчет скорости постгре, так что явно вопрос не о нем, а именно об мускуле.
 
Сверху