Меню
Что нового?

UUID

Yoskaldyr

Yoskaldyr

"Спамер"
Партнер клуба
fixxxer написал(а):

MySQL :: MySQL 8.0 Reference Manual :: 14.23 Miscellaneous Functions

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

AmdY

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

Yoskaldyr

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

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

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

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

fixxxer

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

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

Yoskaldyr

"Спамер"
Партнер клуба
да, ошибся, не начало, а конец (и да если используется таймстамп генерация), но суть не меняет.
как пример
www.percona.com

Storing UUID Values in MySQL

Karthik Appigatla revisits a post Peter Zaitsev wrote on UUIDs (Universal Unique IDs), rearranging the timestamp and talks about storing UUID Values.
www.percona.com www.percona.com
если так хранить то почти то же что обычный автоинкремент бигинта с точки зрения времени запросов.
после оптимизации (выкидываем перманентную часть, т.к. сервер один) можно добить почти до производительности до обычного инта.
Единственное что в этой статье странно, что сравнивают таблицы где единичные примари индексы по uuid (2 вида) с таблицей где примари бигинт и вспомогательный uuid.

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

fixxxer

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

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

grigori

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

grigori

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

Вурдалак

Продвинутый новичок
grigori написал(а):
В тему альтернативы 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

grigori

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

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

fixxxer

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

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

fixxxer

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

Вурдалак

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

fixxxer

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

Вурдалак

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

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

grigori

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

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

Yoskaldyr

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

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