Англійська для розробників Citus

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

Ключовий словник

** Стовпчик розподілу (ключ shard) ** — стовпчик, який Citus використовує для визначення того, до якого шарду належить рядок, цей стовпчик обирається один раз під час розподілу таблиці; швидкість виконання майже кожного запиту залежить від того, чи виконується фільтрування або об’ єднання за допомогою цього стовпчика. “Ми розподілили за tenant_id, тому будь-який запит, що фільтрує за рентієром, залишається на одному шарді — але запит, який ігнорує його, має розгортатися по всіх робочих станціях.”

** Co- location ** — розташування пов’ язаних розподілених таблиць так, щоб рядки, які часто об’ єднуються разом (наприклад, замовлення і його рядкові елементи) опинялися на одному шарді, що дозволяє Citus виконувати об’ єднання локально замість перетасовування даних по мережі. “Оскільки orders і order_items розташовані спільно на tenant_id, це з’єднання працює повністю на одному робочому процесі — якщо вони не були б розташовані спільно, Citus спочатку перерозподіляв би дані.”

** Посилання на таблицю ** — невелика таблиця (наприклад, список країн або стану) повністю реплікується на кожному робочому вузлі, отже, її можна буде приєднати локально до будь- якої розподіленої таблиці без перестановки у мережі. “Зроби таблицю currencies таблицею посилання — вона крихітний, рідко змінюється, і кожен працівник повинен постійно приєднуватися до неї.”

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

• “Після додавання двох нових робочих вузлів, нам слід виконати перебалансування шардів — інакше нові вузли не працюватимуть, а старі залишаться завантаженими, як і раніше.” *

** Маршрутний запит (порівняно з розподіленим запитом) ** — запит, який Citus може цілком маршрутизувати до однієї робочої сторінки, оскільки він фільтрує за стовпчиком розподілу, на відміну від розподіленого запиту, який має торкатися декількох шардів і агрегувати результати у координатора. “Це стало маршрутним запитом у момент, коли ми додали фільтр рентера — до того, він розгортався на всі тридцять два осколки для кожного запиту.”

Звичайні фрази

• «Яка колонка розподілу в цій таблиці, і чи цей запит насправді фільтрує її?»
• Чи ці дві таблиці розташовані разом, чи це з’єднання викликає перестановку шарів?
• Чи є ця невелика, рідко змінювана таблиця хорошим кандидатом для посилання таблиці?
• Чи потрібно нам ребалансувати shard після цієї зміни масштабування?»
• Чи це запит маршрутизатора, чи він розгортається по всіх шардах?»

Приклади висловлювань

Перегляд запиту на звантаження: “Цей запит об’ єднує дві розподілені таблиці без фільтрування за стовпчиком розподілу — це стане повним розподіленим об’ єднанням у кожному шарді, а не запитом маршрутизатора.”

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

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

Професійні поради

• Скажіть “колона розподілу” точно, а не просто “колона шардування” - це термін, який використовують документація Citus і спільнота, і це єдине рішення з найбільшими довгостроковими наслідками.
• Під час перегляду з’ єднання між двома розподіленими таблицями, запитайте “чи вони співрозташовані?” перед тим, як припустити, що запит буде працювати добре - нерозташоване з’ єднання набагато дорожче, ніж здається.
• Використовуйте “посилання таблиця” навмисно для малих, часто-приєднаних пошуку даних - це специфічна функція Citus, а не просто “таблиця, яку ми не турбувалися розповсюджувати.”
• Розрізняйте ** маршрутизаторні запити ** від розподілених запитів під час обговорення швидкодії — запит, який стає маршрутизаторним запитом, зазвичай є найбільшим одним доступним перевагою затримки.

Практичні вправи

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

Навигація Nuance: точність в колективному відгуку

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

Розробник може залишити коментар на PR, описуючи запит, який не оптимально використовує індекси. Вони могли б просто сказати: « Цей запит повільний. » Однак, більш ефективним підходом було б: « Я помітив, що цей запит виконує повне сканування таблиці на таблиці users. Розгляньте можливість додавання індексу до стовпчика email, щоб поліпшити продуктивність і зменшити затримку, особливо з поточним розподілом ключів фрагментів. Ми також можемо дослідити попередню матеріалізацію часто доступних даних, якщо це залишається вузьким місцем. ” Помітили різницю? Це не просто вказівка на проблему; це надання контексту, запропонування рішень і пояснення міркувань за цими пропозиціями. Аналогічно, в каналах Slack, короткі, добре структуровані повідомлення є ключовими. Уникайте нечітких скарг на кшталт «Це не працює!», Замість цього спробуйте «customer_id ключ фрагменту, здається, викликає значне відхилення в розподілі даних - я досліджую потенційні стратегії зменшення»

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

Ось простий приклад оптимізації запиту за допомогою команди EXPLAIN ANALYZE у PostgreSQL:

EXPLAIN ANALYZE SELECT * FROM users WHERE email = 'john.doe@example.com';

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