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

UUID

Read models это отдельный вопрос, и я не думаю, что я стал бы этот вопрос решать запросами к таблице на лямы строк.
 
хотя даже при таких объемах и таких индексах селекты вообще не проблема, но вот пакетные апдейты, которые хоть как-то затрагивают один из индексов или пакетные удаления/вставки - жопа, а если изменение схемы затрагивающее индексы, то еще большая жопа :(
 
Yoskaldyr написал(а):
хотя даже при таких объемах и таких индексах селекты вообще не проблема, но вот пакетные апдейты, которые хоть как-то затрагивают один из индексов или пакетные удаления/вставки - жопа, а если изменение схемы затрагивающее индексы, то еще большая жопа :(
Нажмите для раскрытия...
Обычно не делают пакетные UPDATE'ы. Делают много маленьких. Это дольше, но в больших системах никто не гарантирует strong consistency, всё к сводится к eventual.
 
Вурдалак написал(а):
Делают много маленьких.
Нажмите для раскрытия...
Пакетные я понимал в общем смысле. Много маленьких в одной транзакции сразу, один апдейт на много записей или много мелких в разных транзакциях, но за короткий промежуток времени. Проблема в том что мускуль не успевает перестраивать слишком жирный индекс, если сильно изменился, т.к. задача только для одного ядра и не параллелится. Т.е. технически все работает очень неплохо большую часть времени, но если нет никакого контроля над равномерностью вставок/апдейтов/удалений может случится нежданчик во время таких пиков что вся база становится раком если это часто используемая таблица и для селектов :(
 
Я боюсь, что здесь проблема не в MySQL. Ну да, MySQL во многих аспектах очень неприятная СУБД, но явно не по этой причине.

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

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

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

P.S. Насчет UUID я понял что при моих нагрузках UUID облегчит в одних местах, но усложнит в других и заставит переносить все на постгре вместо мускуля. Значит не вариант. Если будет новый проект то может буду сразу uuid на постгре.
 
Я сложно себе представляю пакетные апдейты, где ты массово изменяешь UUID :) эта колонка обычно (insert and read)-only
 
@Adelf Еще раз повторюсь - проблема в том как хранятся индексы в InnoDB. Проблема в том что примари индекс неявно копируется во все вторичные индексы. Из-за этого все проблемы. Обновление любого вторичного индекса значительно тяжелее при жирном примари, чем при простом примари. Это технические особенности хранения индексов в Innodb и все. Я нигде не писал что собираюсь обновлять UUID.
 
Вон Вурдалак советовал когда-то иметь обычный автоинкрементный примарный, а uuid - вторичный.
 
Adelf написал(а):
Вон Вурдалак советовал когда-то иметь обычный автоинкрементный примарный, а uuid - вторичный.
Нажмите для раскрытия...
Так об этом я и писал
Yoskaldyr написал(а):
Самый минимальный вариант это примари индекс как число, а второй индекс по uuid.
Нажмите для раскрытия...
И вопрос был
Yoskaldyr написал(а):
Генерировать цифровой id в добавок к uuid - тогда зачем вообще uuid для данных типов сущностей?
Нажмите для раскрытия...

Я то уже уже понял что там где хотел применить не совсем получится учитывая специфику - минусы перевешивают плюсы, для нового где можно юзать постгре или где не планируются большие объемы можно будет использовать UUID (т.к. плюсы очень приятны)
 
Adelf написал(а):
Вон Вурдалак советовал когда-то иметь обычный автоинкрементный примарный, а uuid - вторичный.
Нажмите для раскрытия...
А, если при этом автоинкрементный вообще никак не использовать - то получится что-то похожее на оракловский rowid или постгресовский with oids. Если проблема исключительно в длинных дополнительных индексах, то, да, вариант
 
@Yoskaldyr основная проблема в том, что тебя невозможно понять - то uuid портит эстетическое удовольствие от чтения url, потом медленно отрабатывает alter table, теперь что uuid в PK тормозит массовые update. Да. uuid не просто втыкается как drop-in replacement на место автоинкремента, он меняет архитектуру приложения, делает алгоритмы проще. Много чего надо поменять под него, и клиентов тоже.
 
Можно и так.
Просто не у всех 8-й мускуль.

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

Для PHP тоже куча генераторов snowflake'ов на github имеется.
 
я на днях наткнулся на шедевр: https://bugreports.qt.io/browse/QTBUG-28560
в QT REST-клиент не разрешает получать от сервера числа за пределами 32 бит - выдает ошибку парсинга
пришлось делать int32 с автоинкрементом
 
С банальным JS тоже могут быть проблемы - когда не влезает в Number.MAX_SAFE_INTEGER
 
@fixxxer в JS хотя бы float, я даже рассчитывал на это и сделал число с точкой, а в QT только int, и только 32
 
Войдите или зарегистрируйтесь для ответа.
Сверху