Comments 6
> Теперь есть возможность раздавать права на конкретные колонки в таблицах (фича приехала из PostgreSQL)
Видимо я что-то упустил, когда это в PostgreSQL появилась такая функциональность? Можно ссылку на документацию?
Видимо я что-то упустил, когда это в PostgreSQL появилась такая функциональность? Можно ссылку на документацию?
Так вот же в официальной документации PostgreSQL 9.4:
И там же пример:
GRANT { { SELECT | INSERT | UPDATE | REFERENCES } ( column_name [, ...] )
[, ...] | ALL [ PRIVILEGES ] ( column_name [, ...] ) }
ON [ TABLE ] table_name [, ...]И там же пример:
GRANT SELECT (col1), UPDATE (col1) ON mytable TO miriam_rw;
Скажите, правильно ли я понимаю архитектуру Greenplum в плане утилизации CPU: если сейчас нужно утилизировать 6 ядер из 16 — создаем 6ть сегментов. А если в будущем понадобиться 12 ядер — нужно создать ещё 6 сегментов и перешардировать?
В целом, правильно, но есть нюанс: один запрос утилизирует максимум одно ядро на один сегмент. То есть, если, например, в вашем примере 6 сегментов и 16 ядер на сегмент-сервер, то один запрос утилизирует максимум 6 ядер, два запроса — 12 ядер, и так далее. Так как обычно в аналитической СУБД работает 20-100 запросов, то проблем с утилизацией не возникает почти никогда (если, конечно, совсем не жестить и не делать по одному сегменту на сервер).
Каждый раз, когда вижу статью про greenplum не могу понять, почему не упоминается сжатие rle, хотя в тестах сжатие вроде выше?
Добавление сегментов на gp5 требует не только перезапуска, но так же синхронизации метаданных. При большом объеме метаданных это может давать часы простоя.
Про переход на gp6: так и не доделан gp_upgrade. А бэкап-рестор может быть очень долгим, это могут быть сутки простоя. Что подойдёт далеко не всем.
О, с RLE ситуация интересная. Действительно, RLE даёт фантастическую степень сжатия (в моей практике доходило до 60-70 раз). Иногда. Если быть точным, при соблюдении нескольких условий:
1. Дельта между данными (строками) небольшая и одинаковая
2. Таблица отсортирована (в случае с ГП это INSERT… SELECT… ORDER BY… )
На практике RLE выстреливает ОЧЕНЬ редко. Всегда надо пробовать и смотреть, что оно даст. Обычно получается использовать RLE для подневных витрин или таблиц фактов.
Про метаданные — всё так. Другой вопрос, что если у вас настолько много метаданных, что они реплецируются по интерконнекту часами, то, возможно, стоит пересмотреть модель? В нашей практике есть только один заказчик с действительно раздутыми каталогами.
gp_upgrade — да, пока не доделан. Кстати, наша команда (Arenadata) принимала активное участие в его разработке этим летом, надеемся к нему вернуться. Минусы бекапа и рестора понятны, но есть разные методики, ускоряющие миграцию, мы в том числе и этим помогаем нашим заказчикам.
1. Дельта между данными (строками) небольшая и одинаковая
2. Таблица отсортирована (в случае с ГП это INSERT… SELECT… ORDER BY… )
На практике RLE выстреливает ОЧЕНЬ редко. Всегда надо пробовать и смотреть, что оно даст. Обычно получается использовать RLE для подневных витрин или таблиц фактов.
Про метаданные — всё так. Другой вопрос, что если у вас настолько много метаданных, что они реплецируются по интерконнекту часами, то, возможно, стоит пересмотреть модель? В нашей практике есть только один заказчик с действительно раздутыми каталогами.
gp_upgrade — да, пока не доделан. Кстати, наша команда (Arenadata) принимала активное участие в его разработке этим летом, надеемся к нему вернуться. Минусы бекапа и рестора понятны, но есть разные методики, ускоряющие миграцию, мы в том числе и этим помогаем нашим заказчикам.
Sign up to leave a comment.
Greenplum 6: обзор новых фич