Производительность UUID в MySQL?
Мы рассматриваем использование значений UUID как первичных ключей для нашей базы данных MySQL. Вставляемые данные сгенерированы от десятков, сотен, или даже тысячи удаленных компьютеров и вставляемый на уровне 100-40 000 вставляют в секунду, и мы никогда не будем делать никаких обновлений.
Сама база данных будет обычно добираться до приблизительно 50M записи, прежде чем мы начнем отбирать данные, таким образом, не крупная база данных, но не крошечные также. Мы также планируем работать на InnoDB, хотя мы открыты для изменения что, если существует лучший механизм для того, что мы делаем.
Мы были готовы пойти с UUID Типа 4 Java, но в тестировании видели некоторое странное поведение. Для одного мы храним как varchar (36), и я теперь понимаю, что мы были бы более обеспеченным двоичным файлом использования (16) - хотя, насколько более обеспеченный я не уверен.
Больший вопрос: как плохо эти случайные данные завинчивают индекс, когда мы имеем 50M записи? Мы были бы более обеспечены, если бы мы использовали, например, UUID типа 1, где к крайним левым битам добавили метку времени? Или возможно мы должны угробить UUID полностью и рассмотреть auto_increment первичные ключи?
Я ищу общие мысли/подсказки о производительности различных типов UUID, когда они хранятся как индекс/первичный ключ в MySQL. Спасибо!
4 ответа
UUID - это универсальный уникальный идентификатор. Это универсальная часть, которую вы должны здесь учитывать.
Вам действительно нужно, чтобы идентификаторы были универсально уникальными? Если это так, то UUID может быть вашим единственным выбором.
Я настоятельно рекомендую, чтобы если вы использовали UUID, вы сохраняли их как числа, а не как строку. Если у вас более 50 миллионов записей, то экономия места для хранения улучшит вашу производительность (хотя я не могу сказать, насколько).
Если ваши идентификаторы не должны быть универсально уникальными, то я не думаю, что вы можете добиться большего, чем просто использовать auto_increment, который гарантирует, что идентификаторы будут уникальными в пределах таблицы (поскольку значение будет увеличиваться каждый раз)
Следует принять во внимание, что автоинкременты генерируются по одному и не могут быть решены с использованием параллельного решения. Борьба за использование UUID в конечном итоге сводится к тому, чего вы хотите достичь, а не к тому, чем вы потенциально жертвуете.
По производительности, кратко :
UUID, подобный приведенному выше, состоит из 36 символов, включая тире. Если вы сохраните этот VARCHAR (36), вы резко снизите эффективность сравнения . Это ваш основной ключ , вы не хотите, чтобы он работал медленно.
На битовом уровне UUID составляет 128 бит, что означает, что он умещается в 16 байтов, обратите внимание, что это не очень удобно для чтения человеком, но он сохранит недостаточно памяти и всего в 4 раза больше, чем 32-битное int, или в 2 раза больше, чем 64-битное int. Я буду использовать VARBINARY (16) Теоретически это может работать без накладных расходов.
Я рекомендую прочитать следующие два сообщения:
Я считаю, что они отвечают на ваш вопрос .
А как насчет UID, созданного вручную? Дайте каждому из тысяч серверов идентификатор и сделайте первичный ключ комбинированным ключом автоинкремента, MachineID ???
Поскольку первичный ключ создается децентрализованно, у вас в любом случае нет возможности использовать auto_increment.
Если вам не нужно скрывать идентификационные данные удаленных машин, используйте UUID типа 1 вместо UUID. Их легче создать, и они, по крайней мере, не могут повлиять на производительность базы данных.
То же самое и с varchar (char, на самом деле) по сравнению с двоичным: это может только помочь. Насколько важно улучшить производительность?