Comments 5
Спасибо, интересно.
PS. у вас 2 одинаковые картинки где сравнение колоночного формата и heap (497 мб)
"процессу, памяти и чуть в меньшей степени к диску" - В меньше степени???! :)
Самое главное для MPP системы, в большинстве случаев вваливающей на фулскан операции - это скорость работы дисковой подсистемы. Из-за наследия от Postgres GP не может фильтровать данные на стадии чтения с диска (нет storage индексов и не будет еще очень долго), поэтому все что не попадает под секционирование уходит на fullscan. Использование индексов в GP слишком "дорогое" - очень долго перестраивать и нет сжатия. Использовать индексирование в GP - плохая практика. Поэтому "секрет" правильного сайзинга - очень много дисков на сегмент и очень быстрых (ssd или nvme).
Скорость выполнения запроса будет зависеть не от скорости работы сегмент хоста, а от скорости работы отдельного сегмента на сегмент хосте. При неправильном сайзинге сайд эффекты могут быть интересные очень:) Поэтому хороший архитектор знает как соотносить кол-во ядер на память и на кол-во дисков на конкретный сегмент в хосте.
Комментарий от автора:
Да, вы все верно говорите про количество ядер на память и скорость дисков. Но использование медленных дисков не приведет к крашу сегмента Greenplum на ноде, будут медленнее выполняться запросы. А вот недостаток памяти или ядер может к этому привести. Поэтому я и сказал, что "чуть в меньшей степени". Конечно, любая MPP система сильно зависит от количества и типа диска, но это будет влиять только на скорость работы запросов, к тому же использование секционирования или субсекционирования позволит уменьшить нагрузку на диск, не вычитывая всю таблицу целиком. Спасибо за ваш комментарий, он очень полезный.
Не не совсем так как вы пишите. Если не хватит памяти то начнется спил на диск. GP - это система которая очень сильно спилит в принципе и основное потребление памяти на сегмент хосте (сюрприз!) уходит именно на файловый кеш ОС. Те когда worker выходит за предел выделенной ему памяти, определяемой параметром экземпляра, то по сути он продолжает использовать память, но уже только как файловый кэш ОС.
А когда заканчивается общая память на сегмент хосте только тогда начнется интенсивная работа с дисковым кэшом. Поэтому, хороший сайзинг - это не только быстрая файловая система, но и отдельные маунты под кэш GP на супер быстрых твердотельных дисках.
По поводу секций и субсекций. Это не панацея. Это поможет только есть у вас в патерне предиката есть возможность выбрать секции. На практике это скорее исключение.
Представьте что у вас есть большая фактовая таблица (банковские проводки) и измерение (банковский счет). Ключ секционирования не может быть по ключу соединения тк очевидно что могут быть сводные счета по которым проводок будет в тысячи раз больше чем про счетам физлица. Значит запрос на соединение вида: найди все проводки и просуммируй по дебету и кредиту по большому списку счетов не может быть колацированным и никакое секционирование по дате проводки вам не поможет тк даты в предикате нет. Никакой индекс на 20 млрд проводок по номеру счета вы создавать не будете. Поддержка его очень дорогая операция и размер индекса будет превышать размер таблицы. Это будет фулскан.
GreenPlum - система работающая на фулсканах. Это реальность для тех кто строил кластеры хотя бы от пары десятков терабайт и конкурентной пользовательской нагрузкой. Реальностью это будет оставаться до тех пор пока в GP не появится аналог storage index'а. В Postgres какой то худой аналог появился только в 14 версии (BRIN index).
GP простая система с тз погружения в нее и получения минимально достаточной экспертизы для проектирования, но эта самая простота, связанная с ее наследственностью, и является ее недостатком!
Построение DWH на основе Greenplum