Greenplum: хранение таблиц

Проверьте себя

Пять вопросов из банка по этой подтеме. Всего их 13, остальные разбираются в тренажёре.

1. #gp_storage1 / 5
   Что такое append-optimized (AO) таблица в Greenplum и когда её выбирают?

   A)AO-таблицы предназначены прежде всего для частых точечных UPDATE и DELETE отдельных строк

   B)Под bulk-загрузку/чтение и сжатие; для больших append-таблиц

   C)AO — это способ хранить таблицу целиком в оперативной памяти сегментов ради скорости

   D)AO не поддерживает сжатие данных, поэтому занимает больше места на диске, чем обычный heap

   показать ответ и разбор

   +B)Под bulk-загрузку/чтение и сжатие; для больших append-таблиц

   // разбор: Append-optimized (AO) — формат хранения, оптимизированный под массовую загрузку и аналитическое чтение: он компактнее heap, поддерживает сжатие и контрольные суммы, и заточен под добавление данных. Его берут для больших факт-таблиц и данных, которые в основном пишутся пачками и читаются, а не правятся построчно. AO плохо подходит под частые точечные UPDATE/DELETE (они дороги и логически, а не физически, удаляют данные — нужна периодическая компакция). Бывает строковым (AO row) и колоночным (AOCO).

2. #gp_storage2 / 5
   Что такое AOCO (append-optimized column-oriented) хранение и в чём его выгода?

   A)AOCO хранит данные построчно, но с более агрессивным сжатием, чем обычная heap-таблица

   B)Колоночное хранение в Greenplum доступно и для heap-таблиц, и для append-optimized одинаково

   C)Колоночное AO — читаем нужные колонки, сильнее сжатие

   D)AOCO выгоден прежде всего для запросов, читающих каждую строку целиком со всеми её колонками

   показать ответ и разбор

   +C)Колоночное AO — читаем нужные колонки, сильнее сжатие

   // разбор: AOCO хранит данные по столбцам (а не по строкам): для аналитического запроса, берущего несколько колонок из широкой таблицы, читаются только они, а не вся строка, — меньше I/O. Однотипные значения в колонке жмутся сильнее, чем разнородные в строке. В Greenplum колоночное хранение возможно только для append-optimized таблиц (AOCO). Идеально для больших витрин с широкими таблицами и запросами по подмножеству колонок; для узких таблиц или доступа «вся строка целиком» выгода мала, а точечные правки дороги.

3. #gp_storage3 / 5
   Как в Greenplum партиционируют большую факт-таблицу и что это даёт?

   A)Партиционирование в Greenplum раскидывает строки по сегментам вместо ключа распределения

   B)Партиции дают уникальность строк и заменяют собой первичный ключ большой факт-таблицы

   C)Партиционирование поддерживается по хешу столбца, диапазоны и списки в Greenplum недоступны

   D)Range/list-партиции по дате → partition pruning + дешёвый drop

   показать ответ и разбор

   +D)Range/list-партиции по дате → partition pruning + дешёвый drop

   // разбор: Greenplum поддерживает партиционирование по диапазону (range, чаще по дате) и списку (list), с вложенными подпартициями. Это делит таблицу на части внутри каждого сегмента (независимо от распределения по сегментам). Выгода: partition pruning — запрос с фильтром по дате читает только соответствующие партиции, а не всю таблицу; управление данными — удалить/переналить период это drop/exchange партиции, а не тяжёлый DELETE. Партиционирование ортогонально распределению: крупную таблицу и распределяют по ключу, и партиционируют по дате.

4. #gp_storage4 / 5
   Зачем в Greenplum внешние (external) таблицы поверх gpfdist/PXF?

   A)Читать/грузить данные из внешних файлов (сегменты тянут их параллельно) без предварительной загрузки в таблицы кластера

   B)External-таблицы хранят данные внутри Greenplum, но в отдельной сжатой области на координаторе

   C)Через gpfdist данные грузятся строго последовательно через координатор, по одной строке за раз

   D)External-таблицы нужны для экспорта результатов и не могут служить источником загрузки

   показать ответ и разбор

   +A)Читать/грузить данные из внешних файлов (сегменты тянут их параллельно) без предварительной загрузки в таблицы кластера

   // разбор: External table описывает данные, лежащие вне Greenplum (файлы на ETL-хостах, S3/HDFS через PXF), как таблицу, к которой можно обращаться SQL. Ключевое — параллелизм загрузки: сервис gpfdist отдаёт файлы, а сегменты Greenplum тянут их части одновременно, минуя узкое горлышко координатора. Так грузят большие объёмы на порядки быстрее, чем построчными INSERT через координатор. External-таблицы используют и для ELT (SELECT прямо из внешних данных), и как источник для INSERT ... SELECT в целевую таблицу.

5. #gp_storage5 / 5
   Как выбирают между heap, AO-row и AOCO для таблицы в Greenplum?

   A)Берут heap: он поддерживает и обновления, и эффективное аналитическое чтение сразу

   B)Heap — правки; AO-row — append целыми строками; AOCO — колоночная аналитика

   C)AOCO выбирают под частые точечные обновления, а heap — под массовую аналитическую загрузку данных

   D)Тип хранения на производительность не влияет, поэтому выбор между ними — чистая формальность

   показать ответ и разбор

   +B)Heap — правки; AO-row — append целыми строками; AOCO — колоночная аналитика

   // разбор: Выбор диктует профиль нагрузки. Heap — данные с частыми точечными UPDATE/DELETE/singleton INSERT (staging с апдейтами, изменяемые справочники): MVCC-модель это тянет, ценой bloat/VACUUM. AO row-oriented — большие, преимущественно дописываемые таблицы, которые часто читают целыми строками или широким срезом колонок; компактно и со сжатием. AOCO (колоночное) — широкие аналитические таблицы, где запросы берут немного колонок из многих: читаются только нужные колонки, сильное сжатие. Общее правило: меняется часто — heap; льётся пачками и читается аналитикой — AO, а по узкому набору колонок — AOCO.