Чи поганий первинний ключ стовпця 5+ для великої (100 мільйонів +) таблиці?

Я читав про деякі проблеми БД у реальному житті, і в одному проекті була 100-мільйонна рядок плюс таблиця, у якій 5 основних стовпців були основними. Я думаю, що це погано, але хто може мені точно сказати, чому?

Таблиця була своєрідною мікро-таблицею зведення / агрегації, тому 5 стовпців були схожими (day, market_id, product_id ...). Спочатку я подумав, що первинний ключ з 5 стовпчиків не є ідеальним, але, як я більше думав, я не міг справді придумати вагому причину, чому це було погано.

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

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

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

Деякі бази даних звітів імітують схему зіркової схеми, навіть якщо вона не чітко створена таким чином.

100 мільйонів + рядків не надто великі для таблиці фактів, особливо з великими даними сьогодні.

Розглянута таблиця була таблицею збору / агрегації.

Тоді це не тільки добре, це "правильно".

І це пахне Зведеною таблицею, оскільки починається з day.

У вас є вторинні індекси? Майте на увазі, що якщо ви використовуєте InnoDB, решта стовпців PRIMARY KEY буде розміщена на кінці вторинного індексу. Знову ж таки, це не обов'язково проблема.

100М рядків - це багато для зведення. Здається, стіл занадто дрібнозернистий. Тобто, можливо, замість того, якщо (дата, a, b, c, d) у вас повинно бути 4 складання з ПК, наприклад (дата, a, b, c), (дата, b, c, d), (дата, c, d, a), (дата, d, a, b) (або деякі відповідні комбінації). Я роблю це, кожен може мати лише 10М рядків, тим самим роблячи звіти ще швидшими, маючи майже стільки ж гнучкості у звіті.

А може, перейти на (тиждень, a, b, c, d), що веде до 14M рядків. (Напевно, більше.)

Використання ЧАСТИНИ для полегшення обрізки --- Прийом у швидку їжу --- Поради щодо сховища даних --- Зведені таблиці . Вони узагальнюють багато методів, які я розробив у кількох проектах DW. Як можна зробити висновок, кожен проект відрізняється. "Типова" кількість зведених таблиць (на мій досвід) становить 3-7. Ціль у підведенні підсумків - 10 фактичних рядків -> 1 Зведений рядок. (Це може бути "медіаною".) У рідкісних випадках я підсумував Зведену таблицю. В іншому рідкісному випадку я РОЗДІЛУВАННЯ підсумкової таблиці; Зазвичай таблиці підсумків досить малі, тому вони досить швидкі для прямого доступу з інтерфейсу користувача.

Ну, насправді наявність ПК із 5+ стовпцями не обов’язково сама по собі погана.

Стає погано, коли ПК також є кластеризованим індексом, який вважатиметься ідентифікатором рядків і таким чином буде доданий до кожного рядка в індексі NC. Це різко збільшить необхідний простір.

Було б також погано, коли ви фактично використовуєте ПК іншим FK, оскільки у вас повинні бути дані всіх 5+ стовпців як у поточній таблиці, так і у тому, на який посилається. Ще раз це збільшить сховище на багато!

Виконання продуктивності буде поганим, коли ПК використовуватиметься як індекс - нехай це буде виключно в таблиці або спільно з FK - оскільки більший PK-ключ, що містить 5+ стовпців, займе більше місця, таким чином менше записів буде вміщуються в межах сторінки, і відтепер потрібно читати більше сторінок, щоб проаналізувати індекс.

Це сказало - завжди може бути вагома причина для того, щоб насправді зробити це, як наприклад таблиця фактів. Тому найкраща відповідь насправді була б як у більшості випадків: Це залежить!

З повагою Денніс

Якийсь 15+ років мені не потрібен такий ключ, бачив його іноді, і це викликало лише неприємності. Дуже багато неприємностей. Перш за все первинний ключ - це збереження цілісності даних, і вони повинні бути синтетичними. Вони не повинні мати прив'язки до реального світу. Чому? Як тільки реальний світ зміниться, і він, безумовно, зникне ваш основний ключ, і вам доведеться оновити його та всю пов’язану інформацію.

Imagime вам потрібно запам'ятати це ядро ​​в якійсь іншій таблиці / базі даних / службі замість одного поля, вам потрібно скопіювати кілька, і ви можете забути скопіювати деякі з них. Замість систематичного первинного ключа - це лише один фрагмент даних, який ви повинні надати. Я не згадую про унікальність індексу, який може бути ще однією величезною темою для обговорення.

Отже короткий підсумок, синтетичний первинний ключ (автоматичне збільшення, наведення, ..) простий у обслуговуванні, копіюванні, ...

Тож я вважаю, синтетичний первинний ключ та ще один ключ на 5 згаданих вами стовпців.

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