Розуміння затінення бази даних

Опубліковано 7 лютого 2019 р

Вступ

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

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

Що таке Шардінг?

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

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

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

Осколки бази даних ілюструють архітектуру спільного використання. Це означає, що черепки автономні; вони не діляться тими самими даними чи обчислювальними ресурсами. У деяких випадках, однак, може мати сенс повторити певні таблиці в кожному фрагменті, щоб вони служили в якості довідкових таблиць. Наприклад, скажімо, існує база даних для програми, яка залежить від фіксованих коефіцієнтів перетворення для вимірювання ваги. Тиражуючи таблицю, що містить необхідні дані про коефіцієнт перетворення, на кожен осколок, це допомогло б забезпечити, щоб усі дані, необхідні для запитів, зберігалися в кожному осколку.

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

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

Переваги Sharding

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

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

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

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

Недоліки Sharding

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

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

Однією з проблем, з якою іноді стикаються користувачі після забруднення бази даних, є те, що осколки з часом стають незбалансованими. Для прикладу, скажімо, у вас є база даних з двома окремими осколками, одна для клієнтів, чиї прізвища починаються з літер від A до M, а інша для тих, чиї імена починаються з літер від N до Z. Однак ваша програма подає непомірну суму людей, прізвища яких починаються на букву G. Відповідно, осколок AM поступово накопичує більше даних, ніж NZ, що призводить до того, що програма уповільнює свою діяльність і зупиняється для значної частини ваших користувачів. Осколок A-M став тим, що називається точкою доступу до бази даних. У цьому випадку будь-які переваги заточування бази даних анулюються через уповільнення та збої. Базу даних, швидше за все, доведеться відремонтувати та перезавантажити, щоб забезпечити більш рівномірний розподіл даних.

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

Останній недолік, який слід врахувати, полягає в тому, що шардинг не підтримується спочатку в кожному механізмі баз даних. Наприклад, PostgreSQL не включає автоматичне шардування як функцію, хоча можливо вручну подрібнювати базу даних PostgreSQL. Існує низка вилок Postgres, які включають автоматичне затінення, але вони часто відстають від останнього випуску PostgreSQL і не мають деяких інших функцій. Деякі спеціалізовані технології баз даних, такі як MySQL Cluster або деякі продукти, що надають послуги як MongoDB Atlas, включають функцію автоматичного шардінгу як функцію, але ванільні версії цих систем управління базами даних цього не роблять. Через це для шардингу часто потрібен підхід "по-своєму". Це означає, що документацію щодо шардування або поради щодо усунення неполадок часто важко знайти.

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

Тепер, коли ми розглянули деякі недоліки та переваги шардингу, ми розглянемо кілька різних архітектур для шардованих баз даних.

Шардінг архітектур

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

Ключове заточення

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

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

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

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

Заточення на основі дальності

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

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

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

Заточення на основі каталогів

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

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

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

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

Чи повинен я осколок?

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

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

Кількість даних програми зростає, щоб перевищити обсяг пам’яті одного вузла бази даних.
Обсяг запису або читання в базу даних перевершує те, що може обробити один вузол або його репліка для читання, що призводить до уповільнення часу відгуку або часу очікування.
Пропускна здатність мережі, необхідна програмі, перевершує пропускну здатність, доступну для одного вузла бази даних та будь-яких репліками читання, що призводить до уповільнення часу відгуку або таймаутів.

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

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

Висновок

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

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