Комментарии 16
Сто лет делали materialized views на триггерах и не парились (как и ещё кучу функциональности вроде partitioning, о наличии которой другие БД заявляли с гордостью, хотя по факту сильно уступали в плане фичастости тому, что в PG можно сделать руками).
НЛО прилетело и опубликовало эту надпись здесь
Сто лет на лошадях ездили и не парились.
Ну это зря. Mview — это не только табличка, которая обновляется по запросу (хотя в данной статье — пока что — не более). Но это первый шаг к реализации других фич материализованных представлений. Если они пойдут дальше реализовывать возможости оракла, то, возможно, со временем появится и code rewrite, например. А его уже так просто «триггерами» не напишешь — на нём навешено существенно больше функционала. Конечно, можно всё руками написать, и перед каждым запросом самому проверять актуальны ли данные в каких представлениях, в зависимости от настройки системы, анализировать все запросы, можно ли хотя бы часть его покрыть существующими сотнями материализованных представлений, как можно преобразовать запрос итд итп. Но так можно скатиться до того, что сказать, что индексы тоже не нужны — можно самим аналогичные структуры сформировать, если пару библиотек написать. За это ведь мы и используем СУБД — чтобы не изобретать велосипеды.
Ну наконец-то!
Это круто, но какой оверхед будет на наполнении этих view? Они же обновляются в реальном времени, нет?
Нет, перечитайте внимательнее. Пока что они обновляются вручную, а в будущих релизах запланировано автообновление с различными таймингами.
Нормальные materialized views обновляются инкрементально, отслеживая все таблицы, участвующие в join-е. Но это пока не готово, так что обновляется все с нуля, по явной команде. Рекомендую пост прочитать все-таки.
Ну, справедливости ради, надо добавить, что в «нормальных materialized view», если мы говорим про реализацию того же Оракла, оверхед от инкрементального обновления тоже весьма чуствителен: включение materialized view log нагружает OLTP систему-источник данных порядочно. Приходилось видеть как, после подклчения mview log-ов, система начинала «тормозить», просаживаясь в отдельных местах на 200% (DML-ы проходили на 2-3 раз медленнее на таблицах, где висят mview logs).
Они бы лучше нормальный failover в родной репликации сделали, чтобы при смерти мастера остальные ноды сами друг с друга догонялись до одинакового состояния. А не так, как сейчас — с бубном, rsync-ом и тормозами. Между прочим, нормальный failover уже сто лет существует в slony, не rocket science это. И вообще, убрали бы необходимость в rsync-е при наливке реплики — цены бы не было… А то делают какие-то второстепенные и легко эмулируемые вещи типа материализованных представлений (да еще не обновляющихся инкрементально, что сводит на нет все плюсы)…
Похоже, но не совсем. Навернее, с помощью этой утилиты можно сделать, если каждая реплика соединится с каждой другой и догонится до недостающего у нее состояния. Но штука в том, что это все слишком низкоуровневые вещи, оно должно быть в идеале реализовано в самой СУБД, чтобы кластер с репликацией работал как единое отказоустойчивое целое (slony к этому, кстати, близко подошел, если бы не протух под собственной тяжестью). а сейчас приходится все собирать по отдельности из полуглючных кирпичей…
… еще на правах «поворчать»: сделали бы они уже возможность любые хуки вешать на кастомный синтаксис запросов и вызывать хранимки на plpgsql в ответ. Тогда можно было бы create materialized view не зашивать в сишном коде, а просто сверху навесить — эта команда же ничего не делает, кроме как создает новую таблицу и заливает в нее результат селекта. Типа, задал один раз грамматику нового запроса в BNF, привязал хранимку, и оп! — sql расширен. Сколько бы времени и сил сэкономило на последних фичах типа материализованных представлений…
При учете того, что для изменения грамматики нужно изменять ядро СУБД, обреченная идея. И для materialized view не подходит. Основная суть поделанных изменений не в том, чтобы просто копировать результат sql в таблицу (это и так все могли сделать), а в создании необходимой инфраструктуры внутри СУБД, чтобы в дальнейшем развивать все необходимые фичи materialized view.
можно, правда придется повозиться с Си кодом или питоном. Знакомая группа в университете занималась проектов, который позволят перед запросом писать ключевое слово «open», что дает движку понять, что несуществующие идентификаторы колонок в данном запросе следует дополнить данными из вэба.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
Обзор важнейших фич Postgres 9.3: материализованные представления