Як пояснити базу даних Sharding англійською мовою
Вивчіть англійську лексику для пояснення розшарування бази даних як інженерам, так і нетехнічним користувачам: ключі розшарування, перебалансування і гарячі точки.
Шардинг є одним з тих архітектурних рішень, які справді важко пояснити добре — це змінює поведінку всієї системи, і нечітке пояснення («ми розділили базу даних») залишає зацікавлених осіб нездатними оцінити компроміси, які робляться від їх імені. Цей підручник містить англійську мову, щоб його було зрозуміло.
Ключовий словник
** Shard ** — один з декількох незалежних розділів бази даних, кожен з яких містить підмножину загальних даних, які разом утворюють повний набір даних у всіх шардах. “Кожен шард містить приблизно одну восьму частину наших загальних даних користувача — запит для конкретного користувача повинен потрапити лише в один шард, а не всі вісім.”
** Ключ шарду ** — поле (часто ІД користувача або ІД користувача), яке використовується для визначення того, до якого шарду належить даний рядок, єдиний найважливіший елемент рішення щодо розробки стратегії шардування. “Ми обирали ідентифікатор користувача як ключ для шарду, що означає, що будь- який запит, адресований одному користувачеві, буде швидким і локальним — але запит, який охоплює багатьох користувачів, тепер буде розгортатися по шардах.”
** Hotspot ** — шард, який отримує непропорційно більше трафіку або даних, ніж інші, зазвичай, тому що ключ шарду не розподіляє навантаження рівномірно, створюючи вузьке місце, незважаючи на те, що загальна система « шардована » “У нас є точка доступу на фрагменті 3 — виявляється, що дані нашого найбільшого корпоративного клієнта всі опиняються там через те, як гешується ключ фрагмента, і цей один фрагмент тепер є нашим справжнім вузьким місцем.”
** Cross- shard запит ** — запит, який потребує читання або агрегування даних з більш ніж одного шарду, що зазвичай є повільнішим і складнішим, ніж запит з одним шардом і часто вимагає координації на рівні програми. “Цей запит панелі управління повільний, тому що це агрегація між осколками — він повинен потрапити на всі вісім осколків і об’єднати результати, на відміну від запитів на користувача, які залишаються на одному осколку.”
** Перебалансування ** — процес пересування даних між фрагментами, зазвичай, для виправлення гарячої точки або для додавання нових фрагментів, що є чутливим з операційної точки зору, оскільки це передбачає пересування поточних даних. “Перебалансування третього шару займе кілька годин і має відбутися в дні з низьким трафіком, оскільки ми фізично переміщуємо великий обсяг даних клієнтів між машинами.”
** Перешарування ** — зміна більшого масштабу до самої стратегії шарування, наприклад, зміна ключа шару або збільшення загальної кількості шарів, відмінне від рутинного перебалансування. “Це не просто перебалансування — зміна ключа шарду з ідентифікатора користувача на ідентифікатор користувача є повним перебалансуванням, що є набагато більшим проектом, ніж пересування деяких даних.”
Звичайні фрази
- Що таке shard key тут, і чи розподіляє він навантаження рівномірно по shards?
- Чи це проблема гарячої точки на одному конкретному шарді, чи вся система під навантаженням?»
- Чи є цей запит cross-shard, і якщо так, то як відбувається агрегація?»
- Чи ми говоримо про перебалансування існуючих осколків, або про повне перебалансування стратегії?»
- Як довго очікується ребалансування, і який вплив на трафік під час цього вікна?
Приклади висловлювань
Пояснення шардингу для нетехнічного користувача: “Ми розділили базу даних на декілька незалежних частин, кожна з яких містить частину даних, так що жодна з них не повинна обробляти весь обсяг даних — це схоже на те, якби було декілька менших картотечних шкафів замість одного величезного, кожен з яких відповідає за певний діапазон файлів.”
Звітування про проблему з точкою доступу: “Дані нашого найбільшого клієнта сконцентровані на одному шарді через те, як розподіляються наші ключі шардів, і цей шард тепер обробляє значно більше навантаження, ніж інші — ми плануємо перебалансування, щоб розподілити його більш рівномірно.”
Вирівнювання проекту перешарування: “Поточний ключ фрагментів був в порядку в нашому попередньому масштабі, але зараз він виробляє нерівномірний розподіл, оскільки наші найбільші рентієри зросли — перерозподіл навколо розміру рентієра, а не ідентифікатора рентієра є справжнім виправленням, а не просто ще одним перебалансуванням.”
Професійні поради
- Поясніть шардинг нетехнічним аудиторіям з ** конкретною аналогією ** (файлові шкафчики, склади), а не стрибати прямо в ключі шардів і гешування - ментальна модель має більше значення, ніж механізм для цієї аудиторії.
- Визначте назву ** ключа shard **, коли обговорюватимемо проблеми з швидкодією — більшість проблем з шардингом пов’ язано з вибором ключа, і якщо ви так сказаєте, то це правильно вплине на розмову.
- Відрізняти ** точку доступу ** від загального навантаження на систему — виправлення для одного конкретного перевантаженого шарду дуже відрізняється від виправлення для всієї системи, яка не має достатньої пропускної здатності.
- Використовуйте ** перебалансування ** і ** перерозподіл ** точно - поєднання рутинної операції переміщення даних з повною зміною стратегії неправильно представляє обсяг роботи для зацікавлених сторін, які планують навколо неї.
Практичні вправи
- Пояснити шардування нетехнічним учасникам за допомогою конкретної аналогії.
- Написати звіт про помилку з описом точки доступу на одному з певних осколків.
- Поясніть у одному реченні різницю між перебалансуванням і перешаруванням.
Навигація по нюансах: специфічна фраза для технічних дискусій
Будьмо чесними – навіть якщо ви * розумієте * концепцію шардингу бази даних, чітко сформулювати її в професійному середовищі може бути складно. Це не просто про те, щоб сказати «ми розділяємо наші дані». Спосіб, в який ви це формулюєте, драматично впливає на те, як інші сприймають архітектуру і її наслідки. Це особливо важливо для не-рідних носіїв англійської мови, які будують свій професійний словник. Розгляньте такий сценарій: Ви переглядаєте запит на завантаження, який пропонує розшарування на основі ідентифікатора користувача. Коментар від головного інженера, Марка, говорить: «Це відчувається як передчасна оптимізація. Чи ми абсолютно впевнені, що user ID буде постійно найкращим ключем фрагменту?»
Ця фраза не є поганою за своєю суттю, але вона використовує технічні терміни («передчасна оптимізація»), які можуть не відразу резонувати з кимось, хто менш знайомий з принципами дизайну баз даних. Більш доступний спосіб відповісти був би: “Я ціную твою обережність, Марк. Ми проаналізували історичні шаблони запитів, і ідентифікатор користувача демонструє відносно рівномірне розповсюдження в різних географічних регіонах - що є нашим основним критерієм ключів фрагментів. Однак, давайте чітко задокументуємо це рішення, заявивши, що ми будемо регулярно моніторити hard hotspots на предмет будь-яких виникаючих дисбалансу. Важливо активно вирішувати потенційні проблеми з доступом до даних.” Зауважте, як додавання фраз на кшталт “моніторинг гарячих точок фрагментів” і “активно адресувати” надає контекст і демонструє продуманий підхід.
Аналогічно, при описі шардування під час опису Запиту на завантаження, не описуйте його просто так: « Ми реалізуємо шардування за допомогою ідентифікатора користувача як ключа. » Замість цього спробуйте: « Щоб поліпшити швидкість читання для нашої глобальної бази користувачів, ми реалізували шардування бази даних за допомогою ідентифікатора користувача. Ця стратегія розподіляє дані між декількома серверами, зменшуючи затримку запиту і покращуючи загальну масштабованість системи. Ми будемо уважно стежити за * операціями запису * до кожного шарду, щоб визначити будь-які потенційні «гарячі точки » - області, де відбувається непропорційна кількість записів. Використання таких термінів, як «підвищити продуктивність читання», «покращити загальну масштабованість системи» і «уважно стежити за операціями запису» повідомляє про * переваги * шардингу в легко зрозумілий спосіб. Крім того, проактивне згадування моніторингу для гарячих точок демонструє передбачення і зменшення ризику.
І нарешті, подумайте, як ви поясните це під час обговорення Slack з менеджером продукту. Замість того, щоб сказати «Ми розділяємо», спробуйте: «Ми реалізували розділення бази даних за допомогою ідентифікатора користувача як первинного ключа. Це означає, що дані, пов’язані з кожним окремим користувачем, зберігаються на окремих серверах - по суті, розподіляючи навантаження і дозволяючи нам масштабувати більш ефективно, оскільки наша база користувачів зростає. ” Ключовим тут є переклад технічного жаргону на просту англійську, зосереджуючись на * тому, що * зміна досягає цілей продукту: масштабованість і поліпшення продуктивності. Завжди прагніть до ясності і контексту під час обговорення складних тем, таких як шардування бази даних, особливо під час спілкування з колегами, які можуть мати різні рівні технічної експертизи.