Стендап Сьогодні 📢 Канал в Telegram @stendap_sogodni

🤖🚫 AI-free content. This post is 100% written by a human, as is everything on my blog. Enjoy!

26.09.2022

Ключові моменти розробки схеми для AWS Redshift

❄️📦🪣 Сьогодні вдало попрацював з AWS Redshift.

Redshift - це аналітична (OLAP) база даних, що виросла з PostgreSQL, виглядає як PostgreSQL, але працює фундаментально по-іншому. Вона призначена для обробки великого обсягу даних, про що свідчить і цінник, що починається з $0.25 на годину.

Але просто завантажити дані у Redshift та отримати швидкий результат не вийде. (Перевірено.) Треба знати деякі ключові моменти.

• Спочатку треба зрозуміти, що це не база для транзакційного використання — робота з індивідуальними записами набагато повільніша, ніж у Postgres.
• Redshift, як стовпчикова база даних, добре робить внутрішню “нормалізацію” даних, тому від явної нормалізації не так багато вигоди.
• Індексів у Redshift взагалі немає. Замість індексів є ключ сортування та ключ розподілення. Від правильно заданих ключів продуктивність запитів може різнитися на порядки.
• Ключ розподілення (distribution key) - це колонка, яка визначає, на який вузол потрапить рядок. (Бо на відміну від Postgres, Redshift відразу розподіляє рядки таблиці по всіх вузлах у кластері.) Такій колонці варто мати рівномірно поділені значення, для досягнення найбільшої вигоди від паралелізації.
• Ключ сортування (sort key) - це колонка або декілька, що задають фізичний порядок зберігання даних. Це значно впливає на швидкість фільтрації по ключу, а також операції JOIN. Якщо, наприклад, дані поділені по клієнтах, то сортування по коду клієнта дозволить Redshift просто відкидати при обробці всі дані, окрім даних вказаного клієнта.
• Матеріалізовані розрізи (materialized view) у Redshift категорично крутіші, ніж у Postgres, і їх опанування є критично важливим для розкриття можливостей цієї бази.
• Перше - materialized view можна оновлювати не тільки цілком, але й інкрементально — що набагато швидше, особливо зі складними запитами. Є певні інтуїтивні обмеження на запити, які це підтримують. Наприклад, максимум можна порахувати інкрементально, а кількість унікальних значень — ні.
• Друге - materialized view можна оновлювати автоматично — тобто Redshift сам відстежує зміни у вхідних таблицях, та оновлює розріз (навіть інкрементально). На жаль, це не працює з каскадами розрізів. Емпірично, оновлення відбуваються протягом хвилин.
• Для розрізів так само задаються ключі сортування і розподілення, тобто це повноцінні та повно-швидкісні таблиці.
• А ще Redshift вміє і забирати дані з AWS S3, і отримувати їх з Kinesis Firehose.