Розуміння шардінгу баз даних DigitalOcean
Опубліковано 7 лютого 2019 р
Вступ
Будь-яка програма чи веб-сайт, які бачать значне зростання, з часом потребуватиме масштабування, щоб забезпечити збільшення обсягу трафіку. Для додатків та веб-сайтів, керованих даними, надзвичайно важливо, щоб масштабування здійснювалося таким чином, щоб забезпечити безпеку та цілісність їх даних. Буде важко передбачити, наскільки популярним стане веб-сайт або додаток або як довго він буде підтримувати цю популярність, саме тому деякі організації вибирають архітектуру баз даних, яка дозволяє динамічно масштабувати свої бази даних.
У цій концептуальній статті ми обговоримо одну таку архітектуру баз даних: шардовані бази даних. Протягом останніх років шардингу приділяється велика увага, але багато хто не має чіткого розуміння того, що це таке, або сценарії, в яких може мати сенс обробляти базу даних. Ми розглянемо, що таке шардінг, деякі його основні переваги та недоліки, а також кілька поширених методів шардінгу.
Що таке Шардінг?
Шардінг - це шаблон архітектури бази даних, пов’язаний з горизонтальним розділенням - практика розділення рядків однієї таблиці на кілька різних таблиць, відомих як розділи. Кожен розділ має однакову схему та стовпці, але також абсолютно різні рядки. Аналогічно, дані, що зберігаються в кожному, є унікальними та незалежними від даних, що зберігаються в інших розділах.
Може бути корисним подумати про горизонтальне розділення з точки зору його відношення до вертикального розділення. У вертикально розділеній таблиці цілі стовпці відокремлюються та розміщуються в нових, окремих таблицях. Дані, що зберігаються в одному вертикальному розділі, не залежать від даних усіх інших, і кожен містить як окремі рядки, так і стовпці. Наступна схема ілюструє, як таблицю можна розділити як горизонтально, так і вертикально:
Шардінг передбачає розбиття власних даних на два або більше менші шматки, які називаються логічними осколками. Потім логічні осколки розподіляються по окремих вузлах бази даних, іменованих фізичними осколками, які можуть містити кілька логічних осколків. Незважаючи на це, дані, що зберігаються в усіх фрагментах, у сукупності представляють цілий логічний набір даних.
Осколки бази даних ілюструють архітектуру спільного використання. Це означає, що черепки автономні; вони не діляться тими самими даними чи обчислювальними ресурсами. У деяких випадках, однак, може мати сенс повторити певні таблиці в кожному фрагменті, щоб вони служили в якості довідкових таблиць. Наприклад, скажімо, існує база даних для програми, яка залежить від фіксованих коефіцієнтів перетворення для вимірювання ваги. Тиражуючи таблицю, що містить необхідні дані про коефіцієнт перетворення, на кожен осколок, це допомогло б забезпечити, щоб усі дані, необхідні для запитів, зберігалися в кожному осколку.
Часто шардінг реалізується на рівні програми, тобто додаток включає код, який визначає, якому осколку передавати читання та запис. Однак деякі системи управління базами даних мають вбудовані можливості шардування, що дозволяє реалізовувати шардінг безпосередньо на рівні бази даних.
З огляду на цей загальний огляд шардінгу, давайте розглянемо деякі позитивні та негативні сторони, пов’язані з цією архітектурою бази даних.
Переваги Sharding
Основна привабливість шардування бази даних полягає в тому, що це може допомогти полегшити горизонтальне масштабування, також відоме як масштабування. Горизонтальне масштабування - це практика додавання більшої кількості машин до існуючого стеку з метою розподілу навантаження та збільшення трафіку та швидшої обробки. Це часто протиставляється вертикальному масштабуванню, інакше званому масштабуванням, яке передбачає модернізацію обладнання існуючого сервера, як правило, шляхом додавання більше оперативної пам'яті або центрального процесора.
Порівняно просто мати реляційну базу даних, що працює на одній машині, і масштабувати її за необхідності, модернізуючи її обчислювальні ресурси. Врешті-решт, будь-яка нерозподілена база даних буде обмежена з точки зору зберігання та обчислювальної потужності, тому наявність свободи масштабування по горизонталі робить ваше налаштування набагато гнучкішим.
Ще однією причиною того, чому деякі можуть вибрати архівовану архітектуру бази даних, є прискорення часу відповіді на запит. Коли ви надсилаєте запит до бази даних, яка не була шардованою, можливо, йому доведеться здійснити пошук у кожному рядку таблиці, яку ви запитуєте, перш ніж він зможе знайти набір результатів, який ви шукаєте. Для програми з великою монолітною базою даних запити можуть стати надмірно повільними. Однак, поділяючи одну таблицю на кілька, запити повинні переходити через меншу кількість рядків, і їхні результати повертаються набагато швидше.
Шардінг також може допомогти зробити додаток більш надійним, пом'якшивши вплив відключень. Якщо ваша програма або веб-сайт спирається на незмінену базу даних, відключення може зробити всю програму недоступною. Однак із заблокованою базою даних відключення, ймовірно, торкнеться лише одного осколка. Незважаючи на те, що це може зробити деякі частини програми чи веб-сайту недоступними для деяких користувачів, загальний вплив все одно буде меншим, ніж якби вся база даних розбилася.
Недоліки Sharding
Хоча заточування бази даних може спростити масштабування та покращити продуктивність, воно також може накласти певні обмеження. Тут ми обговоримо деякі з них, і чому вони можуть бути причинами, щоб взагалі уникати шардування.
Перша складність, з якою люди стикаються з шардінгом, полягає в самій складності правильної реалізації архітектури шардованих баз даних. Якщо це зробити неправильно, існує значний ризик того, що процес шардінгу може призвести до втрати даних або пошкодження таблиць. Навіть якщо все зроблено правильно, шардінг, ймовірно, матиме серйозний вплив на робочий процес вашої команди. Замість того, щоб отримувати доступ до даних і керувати ними з однієї точки входу, користувачі повинні керувати даними в кількох місцях осколка, що може потенційно заважати деяким командам.
Однією з проблем, з якою іноді стикаються користувачі після забруднення бази даних, є те, що осколки з часом стають незбалансованими. Для прикладу, скажімо, у вас є база даних з двома окремими осколками, одна для клієнтів, чиї прізвища починаються з літер від A до M, а інша для тих, чиї імена починаються з літер від N до Z. Однак ваша програма подає непомірну суму людей, прізвища яких починаються на букву G. Відповідно, осколок AM поступово накопичує більше даних, ніж NZ, що призводить до того, що програма уповільнює свою діяльність і зупиняється для значної частини ваших користувачів. Осколок A-M став тим, що називається точкою доступу до бази даних. У цьому випадку будь-які переваги заточування бази даних анулюються через уповільнення та збої. Базу даних, швидше за все, доведеться відремонтувати та перезавантажити, щоб забезпечити більш рівномірний розподіл даних.