Шардування баз даних проти розподілу

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

Чи могли б фахівці з stackoverflow допомогти мені зрозуміти основи?

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

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

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

Загальна логіка, яка не містить ключових слів, - це використання алфавіту для поділу даних. AD - це екземпляр 1, EG - екземпляр 2 і т.д.

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

Добре відомий приклад, який ви можете вивчити - це те, як Instagram вирішив свій розділ у перші дні (див. Посилання нижче). Вони почали розподілятися на дуже небагатьох серверах, використовуючи Postgres для поділу даних з початку роботи. Я вважаю, що було кілька тисяч логічних осколків на цих декількох фізичних осколках. Прочитайте їх дивовижний запис із 2012 року тут: Instagram Engineering - Sharding & IDs

Дивіться також тут: http://www.quora.com/Whats-the-difference-bet between-sharding-and-partition

Схоже, це відповідає на обидва ваші запитання:

Горизонтальний розподіл розбиває одну або кілька таблиць за рядками, як правило, в межах одного екземпляра схеми та сервера баз даних. Він може запропонувати перевагу, зменшивши розмір індексу (і, таким чином, пошукові зусилля) за умови наявності явного, надійного, неявного способу визначити, в якій таблиці буде знайдений конкретний рядок, без попереднього пошуку індексу, наприклад, класичний приклад таблиць "CustomersEast" та "CustomersWest", де їх поштовий індекс вже вказує, де вони будуть знайдені.

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

Джерело: Wiki-Shard .

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

Джерело: MongoDB .

Я також занурився в це, і хоча я, безумовно, посилання на це питання, є кілька ключових фактів, які я зібрав, і моменти, якими я хотів би поділитися:

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

https://en.wikipedia.org/wiki/Partition_(database)

Шардінг - це тип розподілу, наприклад горизонтальний перегородка (HP)

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

https://en.wikipedia.org/wiki/Shard_(database_architecture)

Мені дуже подобається відповідь Тоні Бако на Quora, де він змушує задуматися з точки зору схеми (а не стовпців та рядків). Він заявляє, що ...

" Горизонтальний розподіл " або розшифровка реплікації [копіювання] схеми та розділення даних на основі клавіші осколка.

" Вертикальний розподіл " передбачає поділ схеми (і дані надходять на пробіжку).

https://www.quora.com/Whats-the-difference-bet between-sharding-DB-tables-and-partitioning-them

Посібник з розділення баз даних Oracle має кілька приємних цифр. Я скопіював кілька уривків із статті.

https://docs.oracle.com/cd/B28359_01/server.111/b32024/partition.htm

Коли розділити таблицю

Ось кілька пропозицій про те, коли розділити таблицю:

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

Обрізка перегородок

Обрізка перегородок є найпростішим, а також найсуттєвішим засобом підвищення продуктивності за допомогою перегородки. Обрізка розділів часто може покращити ефективність запитів на кілька порядків. Наприклад, припустимо, що програма містить таблицю "Замовлення", що містить історичний запис замовлень, і що ця таблиця була розділена на тиждень. Запит, який запитує замовлення протягом одного тижня, матиме доступ лише до одного розділу таблиці Замовлення. Якщо в таблиці Замовлення були 2 роки історичних даних, то цей запит отримав би доступ до одного розділу замість 104 розділів. Цей запит потенційно може виконуватися в 100 разів швидше просто через обрізку розділів.

Стратегії розподілу

• Дальність
• Хеш
• Список

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

І нарешті, важливо розуміти, що бази даних надзвичайно ресурсомісткі:

• ЦП
• Диск
• I / O
• Пам'ять

Багато DBA будуть розділяти на одній машині, де розділи поділять усі ресурси, але забезпечать поліпшення диска та вводу / виводу шляхом розбиття даних та / або індексу.

У той час як інші стратегії використовуватимуть архітектуру "нічого спільного", де осколки будуть розташовуватися на окремих і чітко виражених обчислювальних одиницях (вузлах), маючи 100% процесора, диска, вводу / виводу та пам'яті для себе. Забезпечення власного набору переваг та складностей.

https://en.wikipedia.org/wiki/Shared_nothing_architecture

Розглянемо таблицю в базі даних з 1 мільйоном рядків і 100 стовпців. В розділі можна розділити таблицю на 2 або більше таблиці, що мають властивість, наприклад:

1. 0,4 млн. Рядків (таблиця1), 0,6 млн. Рядків (таблиця2)

2. 1 мільйон рядків і 60 стовпців (таблиця1) і 1 мільйон рядків і 40 стовпців (таблиця2)

   Таких випадків може бути кілька

Це загальний розподіл

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

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

Якщо говорити про розділення, будь ласка, не використовуйте термін реплікації чи реплікації. Реплікація - це інше поняття і поза рамками цієї сторінки. Коли ми говоримо про розділення, тоді краще слово - це розділення, а коли ми говоримо про різкості, то краще слово розподіляється. У розділі (як правило, і за загальним розумінням не завжди) рядки великої таблиці наборів даних поділяються на дві або більше нерозділених (не поділяють жодних рядків) груп. Можна назвати кожну групу розділом. Ці групи або всі розділи залишаються під контролем одного разу екземпляра RDMB, і це все логічно. Базою кожної групи може бути хеш або діапазон або т. Д. Якщо у вас є дані десяти років у таблиці, ви можете зберігати дані кожного року в окремому розділі, і це можна досягти, встановивши межі розділів на основі ненульовий стовпець CREATE_DATE. Після того, як ви запитаєте на db, якщо ви вказали дату створення між 01-01-1999 та 31-12-2000, тоді будуть звернені лише два розділи, і це буде послідовно. Я робив подібне в БД для мільярда + записів, і час sql доходив до 50 мільйонів за 30 секунд, використовуючи індекси тощо. Шардінг полягає в тому, що ви розміщуєте кожен розділ на іншому вузлі / машині. Зараз пошук всередині розділів / фрагментів може відбуватися паралельно.

Горизонтальний розділ при переміщенні в інший екземпляр бази даних * стає частиною бази даних .

Екземпляр бази даних може бути на тій же машині або на іншій машині.