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

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

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

** Розділення обчислень і зберігання ** — архітектура Databend, що дозволяє зберігати дані в об’єкті зберігання (наприклад, S3), а обчислювальні вузли масштабуються незалежно, що дозволяє збільшувати або зменшувати об’єм без переміщення базових даних. “Розділення обчислень і зберігання є причиною, чому ми можемо запускати додаткові вузли запиту для звітів на кінець місяця і виключати їх після, не торкаючись шару даних взагалі.”

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

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

• “Еластичне масштабування дозволило нам поглинути пік трафіку від маркетингової кампанії без будь- якого вручну забезпечення — кластер зростав автоматично і зменшувався після.” *

** Сервер об’ єктного зберігання ** — використовує службу, на зразок S3 або сумісну альтернативу, як стійкий шар зберігання під базою даних, замість локальних дисків, приєднаних до обчислювальних вузлів. “Оскільки сервером об’ єктного зберігання є S3, ми отримуємо ті ж гарантії довговічності, що і S3, без запуску власного реплікованого кластера зберігання.”

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

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

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

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

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

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

Перегляд запиту перед його запуском на виробничих даних:

• “Спочатку запустіть оцінку вартості запиту — формат зберігання у колонках допомагає, але це все одно торкнеться величезної кількості даних, якщо фільтр не вибірковий.” *

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

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

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

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

Переклади: «Переклади з англійської мови» (англ

Зрозуміти технічний жаргон - це не просто знати окремі слова; це розуміти намір за ними. Як розробник, що працює з Databend - особливо в глобально розподіленій команді - ви часто стикаєтеся з фразою, яка виходить за рамки простого перекладу її основних концепцій. Недостатньо сказати «колонарне зберігання» - вам потрібно сформулювати * чому * це має значення і як це впливає на рішення. Аналогічно, розмова навколо «розділення обчислень і зберігання» - це не просто технічна деталь; це двигун для оптимізації витрат. Це особливо важливо при спілкуванні з зацікавленими сторонами, які можуть не мати глибокого розуміння архітектури сховища даних.

Одна з найпоширеніших проблем виникає під час перегляду коду. Уявіть, що ви отримали такий коментар щодо запиту на звантаження: « Цей запит не використовує повністю переваги стовпчиків — розгляньте можливість зміни структури, щоб використовувати більше стовпчиків для оптимізації швидкодії ». Хоча це технічно правильно, але у цьому коментарі бракує контексту. Краще було б відповісти: « Я змінив структуру запиту, щоб він відповідав колонковому формату, що має значно скоротити час сканування і поліпшити загальну продуктивність запиту. Я зосередився на оптимізації з’ єднань і фільтрування на основі типів даних стовпчиків. » Незначна відмінність полягає у тому, що зміна розглядається як перевага — поліпшення * продуктивності * — а не просто виправлення технічної проблеми.

Інша область, де нюанс має значення, це розмови Slack. Отримавши повідомлення на кшталт: «Давайте збільшимо це, щоб обробляти більше користувачів», без розуміння наслідків розділення обчислень і зберігання може призвести до неправильно спрямованих зусиль і марнування ресурсів. Більш інформована відповідь може бути: «Масштабування обчислень само по собі не обов’язково є найкращим підходом тут. Зважаючи на нашу поточну архітектуру з окремими рівнями зберігання, нам слід спочатку проаналізувати шаблони запитів і оптимізувати доступ до даних перед збільшенням використання процесора. Можливо, перерозподіл таблиці може зменшити кількість даних, сканованих для часто доступних запитів. ”

Нарешті, при обговоренні витрат, важливо вийти за рамки сирих обчислювальних годин. Фраза «еластичні аналітичні завдання» це не просто модне слово; це означає можливість динамічно коригувати ресурси на основі попиту - основна функція, доступна завдяки архітектурі Databend. Розмови навколо «оптимізації рівнів зберігання для шаблонів читання / запису» або «використання ступеневої пам’яті для мінімізації витрат під час періодів низької пікової напруги» демонструють глибше розуміння того, як дизайн Databend впливає на кінцеву лінію.

Ось приклад використання dbd (засіб командного рядка Databend) для дослідження швидкодії запиту:

dbd exec -c "EXPLAIN ANALYZE SELECT * FROM sales_data WHERE region = 'NorthAmerica';" --project=my-databend-project --database=default

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