Англійська для ClickHouse

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

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

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

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

** OLAP (онлайнова аналітична обробка) ** — категорія навантаження ClickHouse оптимізована для: великих агрегованих запитів на величезні набори даних, на відміну від OLTP, який обробляє багато невеликих, окремих транзакційних читання і запису. “Ми не замінюємо наші транзакційні бази даних цим - ClickHouse для OLAP, запускаючи великі агреговані аналітичні запити на історичні дані, в той час як Postgres залишається як система OLTP, що обробляє окремі транзакції користувачів.”

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

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

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

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

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

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

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

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

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

Визначення обсягу бази даних: “Ми додаємо ClickHouse спеціально для OLAP завантажень — аналітичні панелі, що запитують місяці історії подій — в той час як наша існуюча база даних Postgres продовжує обробляти OLTP сторону, як окремі транзакції замовлень.”

Вирівнювання матеріалізованого перегляду:

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

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

• Поясніть ** колонко- орієнтоване зберігання **, коли хтось здивований швидкістю ClickHouse на агреговані запити — це фундаментальна причина, відмінна від будь- якої конкретної оптимізації запиту.
• Будьте ясно про ** OLAP ** проти OLTP при визначенні, які завантаження належать до ClickHouse — натиснення транзакційних, однорядкових пошуків на нього зазвичай працює гірше, ніж традиційна база даних.
• Використовуйте ** матеріалізований перегляд ** для будь- якого дорогого агрегаційного запиту, який виконується неодноразово на тих самих даних — це зменшить витрати на зберігання і запис, а також зменшить вартість читання.
• Тільки введіть sharding, коли обсяг зберігання або пропускна здатність запиту окремого вузла насправді стає в’язким місцем — це додає справжню операційну складність, яка не варте цього передчасно.
• Виберіть стовпчики упорядкування ** дерева об’ єднання ** на основі найпоширеніших фільтрів запиту — невідповідний порядок впорядкування знижує швидкодію ClickHouse.

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

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

Розширення професійного словника: звернення до відгуків і співпраці

Ядро ефективного спілкування в будь-якому середовищі розробки програмного забезпечення - особливо при роботі зі складними технологіями, такими як ClickHouse - залежить від точності. Це не просто про розуміння концепцій; це про їх чітке вираження, конструктивне отримання зворотнього зв’язку і ефективне співробітництво з вашою командою. Для не рідних носіїв англійської мови це може бути особливо складним аспектом професійного життя. Часто, незначні відмінності у фразування можуть повністю змінити сприйняття значення або впливу вашого повідомлення. Давайте розглянемо, як уточнити ваше спілкування навколо термінології ClickHouse.

Одним з найпоширеніших викликів є навігація по коментарях перегляду коду. Отримання зворотного зв’ язку на кшталт «Цей запит може отримати користь від індексування» не є простою пропозицією; це твердження про * продуктивність * і потенційні проблеми. Важливо, щоб ви відповідали на запитання з розумом. Замість того, щоб оборонно сказати: «Я вже це оптимізував», подумайте: «Дякую, що вказали на це. Я досліджував різні стратегії індексування в ClickHouse - конкретно, створюючи матеріалізований вигляд на user_id колонці. Це має значно поліпшити час виконання запиту для подібних пошуків. Чи можемо ми обговорити компроміс між створенням індексу і обсягом пам’ яті?» Зауважте, що у цій відповіді ви підтверджуєте отримання зворотнього зв’ язку, демонструєте розуміння проблеми (індексування і продуктивність), і активно пропонуєте рішення — все це зроблено професійною, точною англійською мовою. Аналогічно, при створенні запитів на захоплення, важливо чітко сформулювати, * чому * ви робите зміни. Не просто скажіть « Виправлено ваду »; поясніть кореневу причину і вплив вашого виправлення.

Іншою ключовою областю є Slack комунікація. Уявіть, що ви отримуєте повідомлення від колеги: «Ця агрегація виглядає повільно — якісь думки?». Проста відповідь на кшталт «Це потребує оптимізації» не особливо корисна. Докладніше пояснення, можливо, з контекстом щодо обсягу даних або складності запиту, демонструє зацікавленість і бажання співпрацювати. « Я помітив, що ця агрегація працює повільно, особливо на великих наборах даних. Я розглядаю можливість використання клаузул ORDER BY стратегічно в запиту, щоб зменшити кількість сканованих даних. Також, давайте дослідимо, чи можемо ми використати матеріалізовані перегляди для цього конкретного сценарію звітів - це може суттєво поліпшити продуктивність. “Знову ж таки, деталі і контекст мають величезне значення.

Нарешті, пам’ятайте, що термінологія ClickHouse - колонне зберігання, шардування, матеріалізовані перегляди - повинна постійно використовуватися правильно. Використання точної мови створює спільне розуміння в команді.

-- Example: Creating a Materialized View for faster reporting

CREATE MATERIALIZED VIEW users_by_country AS
SELECT
    country,
    COUNT(*) AS user_count
FROM
    users
GROUP BY
    country;

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