UUID

[fixxxer]

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

 

[Yoskaldyr]

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

 

[Вурдалак]

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

Обычно не делают пакетные UPDATE'ы. Делают много маленьких. Это дольше, но в больших системах никто не гарантирует strong consistency, всё к сводится к eventual.

 

[Yoskaldyr]

Делают много маленьких.

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

 

[Вурдалак]

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

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

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

 

[Yoskaldyr]

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

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

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

 

[Adelf]

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

 

[Yoskaldyr]

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

 

[Adelf]

Вон Вурдалак советовал когда-то иметь обычный автоинкрементный примарный, а 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]

и заставит переносить все на постгре вместо мускуля

По-моему, ты себе проблему упорно выдумываешь.
Сделать в MySQL

`uuid` CHAR(36) NOT NULL CHARACTER SET ascii

невеликая проблема.

 

[fixxxer]

Char как раз не стоит. binary(16) + uuid_to_bin

 

[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