Продуктивність UUID в MySQL?

Ми розглядаємо можливість використання значень UUID як первинних ключів для нашої бази даних MySQL. Дані, що вставляються, генеруються з десятків, сотень або навіть тисяч віддалених комп’ютерів і вставляються зі швидкістю 100-40 000 вставок в секунду, і ми ніколи не будемо робити оновлення.

Сама база даних зазвичай отримує близько 50 мільйонів записів до того, як ми почнемо відбирати дані, тож не масивна база даних, але не крихітна. Ми також плануємо працювати на InnoDB, хоча ми готові змінити це, якщо є кращий двигун для того, що ми робимо.

Ми були готові піти з UUID типу 4 Java, але під час тестування спостерігали дивну поведінку. По-перше, ми зберігаємо як varchar (36), і тепер я розумію, що нам було б краще використовувати двійковий файл (16) - хоча наскільки краще, я не впевнений.

Більше питання: наскільки погано ці випадкові дані псують індекс, коли ми маємо 50 мільйонів записів? Чи було б нам краще, якби ми використали, наприклад, UUID типу 1, де крайні ліві біти були позначені часом? А може, нам слід повністю відмовитися від UUID і розглянути первинні ключі auto_increment?

Я шукаю загальні думки / поради щодо продуктивності різних типів UUID, коли вони зберігаються як індекс / первинний ключ у MySQL. Дякую!

UUID - це універсальний унікальний ідентифікатор. Це універсальна частина, яку ви повинні тут розглянути.

Вам справді потрібні посвідчення особи, щоб бути універсально унікальними? Якщо так, то UUID можуть бути вашим єдиним вибором.

Я настійно рекомендую , що якщо ви робите використання UUID , ви зберігаєте їх у вигляді числа , а не у вигляді рядка. Якщо у вас 50 мільйонів записів, тоді економія місця на сховищі покращить вашу продуктивність (хоча я не міг сказати, на скільки).

Якщо ваші ідентифікатори не повинні бути універсально унікальними, то я не думаю, що ви можете зробити набагато краще, ніж просто використовувати auto_increment, який гарантує, що ідентифікатори будуть унікальними в таблиці (оскільки значення буде збільшуватися щоразу)

На моїй роботі ми використовуємо UUID як ПК. Що я можу сказати вам з досвіду, це НЕ ВИКОРИСТОВУВАТИ ЇХ як ПК (SQL Server, до речі).

Це одна з тих речей, що коли у вас менше 1000 записів, це нормально, але коли у вас мільйони, це найгірше, що ви можете зробити. Чому? Оскільки UUID не є послідовними, тому кожного разу, коли вставляється новий запис, MSSQL потрібно перейти до правильної сторінки, щоб вставити запис, а потім вставити запис. Справді потворним наслідком цього є те, що сторінки закінчуються різними розмірами, і вони закінчуються фрагментарно, тож тепер нам доводиться періодично дефрагментувати.

Коли ви використовуєте автоінкремент, MSSQL завжди переходить на останню сторінку, і ви отримуєте однаково великі сторінки (теоретично), тому ефективність відбору цих запитів набагато краща (також тому, що INSERT не блокують таблицю / сторінку для так довго).

Однак велика перевага використання UUID як ПК полягає в тому, що якщо у нас є кластери БД, не буде конфліктів при об’єднанні.

Я б рекомендував наступну модель: 1. Ідентифікація PK INT 2. Додатковий стовпець, автоматично згенерований як UUID.

Таким чином, процес злиття можливий (UUID буде вашим РЕАЛЬНИМ ключем, тоді як PK буде просто тимчасовим, що забезпечує вам хорошу продуктивність).

ПРИМІТКА. Найкращим рішенням є використання NEWSEQUENTIALID (як я вже говорив у коментарях), але для застарілої програми, яка не має багато часу на рефакторинг (і навіть гірше, не контролюючи всі вставки), це неможливо зробити. Але дійсно станом на 2017 рік, я б сказав, що найкращим рішенням тут є NEWSEQUENTIALID або створення Guid.Comb з NHibernate.

Сподіваюся, це допомагає

Щось, що слід врахувати, це те, що автоінкременти генеруються по одному, і їх неможливо вирішити за допомогою паралельного рішення. Боротьба за використання UUID з часом зводиться до того, чого ви хочете досягти, проти того, чим ви потенційно жертвуєте.

Щодо продуктивності, коротко :

UUID, подібний до наведеного вище, має довжину 36 символів, включаючи тире. Якщо ви зберігаєте цей VARCHAR (36), ви значно зменшите ефективність порівняння. Це ваш основний ключ, ви не хочете, щоб він був повільним.

На своєму бітовому рівні UUID дорівнює 128 бітам, що означає, що він вміщуватиметься в 16 байт. Зверніть увагу, це не дуже зручно для читання, але він буде зберігати низький рівень зберігання і лише в 4 рази перевищує 32-розрядний int, або 2 в рази більше, ніж 64-розрядний int. Я буду використовувати VARBINARY (16) Теоретично це може працювати без великих накладних витрат.

Рекомендую прочитати наступні два дописи:

• Брайан "Кроу" Бездіяльні думки Акера - міфи, GUID проти автоінкременту
• На UUID чи ні на UUID?

Я вважаю, що вони відповідають на ваше запитання.

Я схильний уникати UUID просто тому, що це біль, яку потрібно зберігати, і біль, яка використовується як первинний ключ, але є переваги. Головна з них - це УНІКАЛЬНІ.

Зазвичай я вирішую проблему та уникаю UUID, використовуючи подвійні ключові поля.

КОЛЕКТОР = УНІКАЛЬНИЙ, ПРИПИСАНИЙ МАШИНІ

ID = ЗАПИС, ЗБЕРЕЖЕНИЙ КОЛЕКТОРОМ (поле auto_inc)

Це пропонує мені дві речі. Швидкість полів автоматичного включення та унікальність даних, що зберігаються в центральному місці після їх збору та згрупування. Я також знаю під час перегляду даних, де вони були зібрані, що часто є досить важливим для моїх потреб.

Я бачив багато випадків, маючи справу з іншими наборами даних для клієнтів, коли вони вирішили використовувати UUID, але тоді все ще є поле для збору даних, що насправді є марною тратою зусиль. Просто використовуючи два (або більше, якщо потрібно) полів, оскільки ваш ключ справді допомагає.

Я щойно бачив занадто багато хітів продуктивності за допомогою UUID. Вони відчувають себе шахраєм ...

Замість того, щоб централізовано генерувати унікальні ключі для кожної вставки, як щодо розподілу блоків ключів для окремих серверів? Коли у них закінчуються ключі, вони можуть запросити новий блок. Тоді ви вирішуєте проблему накладних витрат, підключаючи для кожної вставки.

Сервер ключів підтримує наступний доступний ідентифікатор

• Сервер 1 вимагає блокування ідентифікатора.
• Сервер ключів повертає (1,1000)
  Сервер 1 може вставляти 1000 записів, поки йому не буде потрібно запитувати новий блок
• Сервер 2 запитує індексний блок.
• Повернення сервера ключів (1001,2000)
• тощо ...

Ви можете придумати більш досконалу версію, де сервер може запитувати кількість необхідних ключів, або повертати невикористані блоки на сервер ключів, що, звичайно, потрібно буде вести карту використаних / невикористаних блоків.

Я б призначив кожному серверу числовий ідентифікатор транзакційним способом. Потім кожен вставлений запис просто автоматично збільшить власний лічильник. Поєднання ServerID та RecordID буде унікальним. Поле ServerID може бути проіндексовано, і майбутня вибрана продуктивність на основі ServerID (за потреби) може бути набагато кращою.

Коротка відповідь полягає в тому, що багато баз даних мають проблеми з продуктивністю (зокрема, з великими обсягами INSERT) через конфлікт між їх методом індексування та навмисною ентропією UUID у бітах високого порядку. Є декілька поширених хакерів:

• оберіть інший тип індексу (наприклад, некластерований на MSSQL), який не проти
• обміняти дані, щоб перемістити ентропію до бітів нижчого порядку (наприклад, переупорядкувати байти V1 UUID на MySQL)
• зробіть UUID вторинним ключем із автоматичним збільшенням первинного ключа

... але це все хакі - і, мабуть, крихкі.

Найкраща відповідь, але, на жаль, найповільніша, - це вимагати від вашого постачальника вдосконалення свого продукту, щоб він міг мати справу з UUID як первинними ключами, як і будь-який інший тип. Вони не повинні змушувати вас прокручувати власну напівпіку, щоб компенсувати їх невдачу у вирішенні того, що стало звичним випадком використання, і буде лише зростати.

А як щодо деяких UID, створених вручну? Дайте кожному з тисяч серверів ідентифікатор і зробіть первинний ключ комбінованим ключем автоінкременту, MachineID ???

Оскільки первинний ключ генерується децентралізовано, ви все одно не можете використовувати auto_increment.

Якщо вам не потрібно приховувати ідентифікацію віддалених машин, використовуйте UUID типу 1 замість UUID. Їх легше генерувати і, принаймні, можуть не зашкодити продуктивності бази даних.

Те саме стосується і varchar (char, дійсно), і бінарного: це може лише допомогти питанням. Це насправді важливо, наскільки покращена продуктивність?

Я усвідомлюю, що це питання досить давнє, але я в своєму дослідженні натрапив на нього. З тих пір сталося багато речей (SSD є всюдисущими InnoDB отримував оновлення тощо).

У своєму дослідженні я знайшов цю досить цікаву публікацію про ефективність:

стверджуючи, що через випадковість GUID / UUID дерева індексів можуть стати досить незбалансованими. у MariaDB KB я знайшов інший допис, що пропонує рішення. Але з цього часу новий UUID_TO_BIN подбає про це. Ця функція доступна лише в MySQL (перевірена версія 8.0.18), а не в MariaDB (версія 10.4.10)

TL; DR: Зберігає UUID як перетворені / оптимізовані значення BINARY (16).