Як архівувати дані SQL Server з урахуванням масштабу

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

Огляд

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

Почніть з кінця на увазі

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

Сценарій 1: Ми додаємо, перетворюємо та подаємо дані до звітів з бази даних або набору баз даних. Додаток та звіти вказують на ці бази даних. Коли нам потрібно архівувати дані, ми переносимо дані у формі вставок і видаляємо з цих баз даних в іншу базу даних, де ми зберігаємо історичні дані. Якщо користувачеві потрібно отримати доступ до історичних даних, запити виконуються проти цього історичного середовища.
Сценарій 2: Ми додаємо, трансформуємо та подаємо дані до звітів з безлічі баз даних (або таблиць), створених часовим вікном із програми, в якій дані отримуються (або потрібні для клієнтів) і зберігаються на той час, наприклад, всі дані для 2017 рік зберігається лише у базі даних 2017 року. Оскільки існує часове вікно, бази даних не ростуть, як у сценарії 1. Часове вікно для цієї бази даних (або структури таблиці) визначає, які дані зберігаються, і архівувати не потрібно, оскільки ми можемо просто створити резервну копію та відновити базу даних на окремому сервера, якщо нам потрібно перенести дані.

Це популярна техніка зберігання даних - дані надходять із програми або рівня ETL в базу даних. У міру зростання бази даних, і нам потрібно архівувати дані, ми переносимо дані в інші місця до інших баз даних на інших серверах.

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

Канали даних

Коли ми розглядаємо кінцеве використання наших даних, ми можемо виявити, що моделювання наших даних із каналів допоможе нашим клієнтам і допоможе нам масштабуватись. Уявіть собі звіт, де люди вибирають зі спадного меню часові рамки, в які вони хочуть запитувати дані - у роках, місяцях чи днях. За лаштунками запит визначає, яка база даних або бази даних використовуються (або таблиці, якщо масштабувати за таблицями). Ми розглядаємо час у цьому випадку як змінну, яка визначає подачу, наприклад 2017 рік, який є стрічкою даних для всіх з 2017 року.