UUID

fixxxer

К.О.
Партнер клуба
Read models это отдельный вопрос, и я не думаю, что я стал бы этот вопрос решать запросами к таблице на лямы строк.
 

Yoskaldyr

"Спамер"
Партнер клуба
хотя даже при таких объемах и таких индексах селекты вообще не проблема, но вот пакетные апдейты, которые хоть как-то затрагивают один из индексов или пакетные удаления/вставки - жопа, а если изменение схемы затрагивающее индексы, то еще большая жопа :(
 

Вурдалак

Продвинутый новичок
хотя даже при таких объемах и таких индексах селекты вообще не проблема, но вот пакетные апдейты, которые хоть как-то затрагивают один из индексов или пакетные удаления/вставки - жопа, а если изменение схемы затрагивающее индексы, то еще большая жопа :(
Обычно не делают пакетные UPDATE'ы. Делают много маленьких. Это дольше, но в больших системах никто не гарантирует strong consistency, всё к сводится к eventual.
 

Yoskaldyr

"Спамер"
Партнер клуба
Делают много маленьких.
Пакетные я понимал в общем смысле. Много маленьких в одной транзакции сразу, один апдейт на много записей или много мелких в разных транзакциях, но за короткий промежуток времени. Проблема в том что мускуль не успевает перестраивать слишком жирный индекс, если сильно изменился, т.к. задача только для одного ядра и не параллелится. Т.е. технически все работает очень неплохо большую часть времени, но если нет никакого контроля над равномерностью вставок/апдейтов/удалений может случится нежданчик во время таких пиков что вся база становится раком если это часто используемая таблица и для селектов :(
 

Вурдалак

Продвинутый новичок
Я боюсь, что здесь проблема не в MySQL. Ну да, MySQL во многих аспектах очень неприятная СУБД, но явно не по этой причине.

Не бывает быстро, дешево и качественно. Нужно в лучшем случае выбирать какие-то 2 качества.

Тут у людей на форуме в голове сразу масса вопросов возникает («а какие у него индексы?», «а характер данных на вставку?», «а про шардинг он в курсе?», «а про очереди он слышал?», ...). Если у тебя реально проблема, которую ты хочешь решить — спроси тут, наверняка кто-то подскажет. А если ты просто ищешь одобрительные кивки на тему какой плохой MySQL, то я боюсь это не прокатит.
 

Yoskaldyr

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

Очень часто здесь на форуме любят переиначивать слова собеседников.

P.S. Насчет UUID я понял что при моих нагрузках UUID облегчит в одних местах, но усложнит в других и заставит переносить все на постгре вместо мускуля. Значит не вариант. Если будет новый проект то может буду сразу uuid на постгре.
 

Adelf

Administrator
Команда форума
Я сложно себе представляю пакетные апдейты, где ты массово изменяешь UUID :) эта колонка обычно (insert and read)-only
 

Yoskaldyr

"Спамер"
Партнер клуба
@Adelf Еще раз повторюсь - проблема в том как хранятся индексы в InnoDB. Проблема в том что примари индекс неявно копируется во все вторичные индексы. Из-за этого все проблемы. Обновление любого вторичного индекса значительно тяжелее при жирном примари, чем при простом примари. Это технические особенности хранения индексов в Innodb и все. Я нигде не писал что собираюсь обновлять UUID.
 

Adelf

Administrator
Команда форума
Вон Вурдалак советовал когда-то иметь обычный автоинкрементный примарный, а uuid - вторичный.
 

Yoskaldyr

"Спамер"
Партнер клуба
Вон Вурдалак советовал когда-то иметь обычный автоинкрементный примарный, а uuid - вторичный.
Так об этом я и писал
Самый минимальный вариант это примари индекс как число, а второй индекс по uuid.
И вопрос был
Генерировать цифровой id в добавок к uuid - тогда зачем вообще uuid для данных типов сущностей?
Я то уже уже понял что там где хотел применить не совсем получится учитывая специфику - минусы перевешивают плюсы, для нового где можно юзать постгре или где не планируются большие объемы можно будет использовать UUID (т.к. плюсы очень приятны)
 

fixxxer

К.О.
Партнер клуба
Вон Вурдалак советовал когда-то иметь обычный автоинкрементный примарный, а uuid - вторичный.
А, если при этом автоинкрементный вообще никак не использовать - то получится что-то похожее на оракловский rowid или постгресовский with oids. Если проблема исключительно в длинных дополнительных индексах, то, да, вариант
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
@Yoskaldyr основная проблема в том, что тебя невозможно понять - то uuid портит эстетическое удовольствие от чтения url, потом медленно отрабатывает alter table, теперь что uuid в PK тормозит массовые update. Да. uuid не просто втыкается как drop-in replacement на место автоинкремента, он меняет архитектуру приложения, делает алгоритмы проще. Много чего надо поменять под него, и клиентов тоже.
 

AnrDaemon

Продвинутый новичок
Можно и так.
Просто не у всех 8-й мускуль.

Вообще, могли бы уже тип UUID добавить, с автоматической конверсией to/from BINARY.
 

fixxxer

К.О.
Партнер клуба
Можно полифилл сделать через хранимку. А вообще любая нормальная ORM умеет это делать со стороны клиента.
 

Крот

Новичок
В свое время Twitter очень не хотел использовать UUID и они придумали Twitter ID (snowflakes). Это обычный unsigned int64, который генерируется алгоритмически (т.е. можно генерировать id объекта до вставки). Про особенности алгоритма можно почитать тут (Baidu переняла опыт Twitter): https://github.com/baidu/uid-generator

Для PHP тоже куча генераторов snowflake'ов на github имеется.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
я на днях наткнулся на шедевр: https://bugreports.qt.io/browse/QTBUG-28560
в QT REST-клиент не разрешает получать от сервера числа за пределами 32 бит - выдает ошибку парсинга
пришлось делать int32 с автоинкрементом
 

fixxxer

К.О.
Партнер клуба
С банальным JS тоже могут быть проблемы - когда не влезает в Number.MAX_SAFE_INTEGER
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
@fixxxer в JS хотя бы float, я даже рассчитывал на это и сделал число с точкой, а в QT только int, и только 32
 
Сверху