Опубликован выпуск проекта pg_ivm 1.0, развивающего расширение с реализацией механизма инкрементального обновления представлений (IVM, Incremental View Maintenance) для СУБД PostgreSQL. Код написан на языке Си и распространяется пол лицензией PostgreSQL. Поддерживается работа с ветками PostgreSQL 13, 14 и 15. В новой версии в IVM добавлена поддержка выражения EXISTS и предоставлена возможность использования подзапросов, использующих EXISTS в блоке WHERE...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=59716
затрудняюсь определить нужность проекта. требуется консультация экспертов.
Использование грамотно обновляющихся представлений способствует повышению удобства доступа к данным.
Повышение удобства доступа к данным полезно.
Формальная логика подсказывает, что IVM - полезная штука.
С уважением, ваш диванный эксперт.
> затрудняюсь определить нужность проекта. требуется консультация экспертов.materialized VIEWS are updated immediately after a base table is modified.
Хоть и не отношусь к олдовым никсовым программерам, но озвучу их точку зрения: быстрый доступ к измененным данным нужен только смузихипсторам со ржавой игогошечкой, а нормальные приложения, написанные на сишке, могут часок(денёк)-другой и со старыми данными поработать.
Чтобы выдать "ценное" и уместное экспертное мнение по протухшим день назад данным?Гипертрофированный пример:
" - Продавай! Быстрее продавай эти акции! Нехорошая картина вырисовывается!
- Поздно, их вчера делистнули с биржи"БД используются не только для неспешной обработки аналитики, когда можно неделями принимать решение.
Биржа акции деньги. Пример по методичке, слабо.
Вы извиняюсь кем работаете с такими взглядами?
> нормальные приложения, написанные на сишке, могут часок(денёк)-другой и со старыми данными поработатьПочти тонко.
За это время они выжмут из данных все... А потом еще разок с ними поработают...
Большинству не нужно значит никому не нужно. Л - Логика.
К примеру, в документоориентированной Lotus Domino есть 3 основных варианта обновления представлений:
- Automatic - оно именно так и работает, как здесь заявлено (происходит обновление данных только той записи представления, которая соответствует изменившемуся документу);
- Manual - для обновления пользователем при открытии представления в UI либо программно (пересчитываются данные всего представления);
- Auto, at most every _ hours (пересчитываются данные всего представления).Особенности первого варианта - обновления работают быстро, но постоянно грузят сервер, - обновление данных по изменившемуся документу автоматически происходят сразу во всех представлениях, у которых обновление установлено в "Automatic". Этот режим как раз установлен по умолчанию при создании нового представления.
Для тех представлений, для которых критически важно в каждую секунду видеть свежее состояние, есть возможность настроить динамическое обновление (очень прожорливая штука).
Что за такое эти материализованные инкрементальеые представления вообще такое?!
вьюха выглядит как таблица, но это просто кусок кода вычисляется каждый раз при обращении к ней
материализованная вьюха - это и впрямь деле таблица, куда кладутся данные из вьюхи, при этом обновляется она при изменении данных.
инкрементальная материализованная вьюха - данные обновляются только в тех строках в которых произошли изменения а не вьюха целиком
наверное как-то так...
Про вьюхи знаю.
Спасибо! Познавательно.
Инкрементальная материализованная вьюха - аналог INSERT FROM SELECT, периодически выполняемого для вспомогательной таблицы-агрегата, в которую автоматом докидываются триггерами изменения построчно
Оуу, доминоха с лотусами
Уж думал никогда больше о них не услышу почти как о квик-бейсике
От Domino мало кто смог уйти в виду отсутствия нормальных платформ-конкурентов. Почту многие перевели на Exchange, но и всё.
Индусы перекупили домину у IBM. Сейчас уже 12-я версия. Там по сути само хранилище осталось старым с небольшими усовершенствованиями, а остальное давно вперёд уехало; к примеру:
- 5 вариантов UI: классический Notes, XPages, Nomad, Volt, возможность разработки на Angular или React;
- новый Java-API, предоставляющий возможность прямой и быстрой работы с базой, в отличие от того, что было раньше (обёртки над C-API);
- множество доработок по администрированию и т.д.
Ну хорошо что хоть допилили, а то во времена моей работы из реального и универсального был лишь жс сильно отсталой версии с кучей нюансовА вообще-то, даже забавно. Когда там МДМ сие представило - в конце 90-х / начале 00-х - и, даже на время моей работы, несмотря на убогость интерфейсов, подобного функционала особо никто не предлагал
Да и сейчас, похоже, тоже. Там ведь хоть и основано многое на почте, но дело не только в ней
Умели же когда-то архитектуру и функционал проектировать
Как раз в начале 0-х IBM купила Lotus у компании Iris. По настоящему вложилась всего в одну версию - в 6-ю. Потом тупо стригла бабло и почти 2 десятка лет кормила обещаниями клиентов, что будет развитие платформы... Индусы, после того, как в 2017-м году выкупили продукт, реально дали ему вторую жизнь. За эти годы они сделали больше, чем за 25 лет IBM.
В том и прикол, отчасти
Там, помнится, даже были подобия электронных подписей для каждого аккаунта
А ведь то начиналось ещё с 00-х
В плане электронных подписей ничего не изменилось - всё норм с давних времён, - полноценные подписи и шифрование тоже. Но оно не включается/отключается в настройках клиента. Это делается кодом и кое что через API. Можно подписывать или шифровать определённый набор полей. Не так чтобы мегаудобно, но возможности такие есть.
когдаже бэкап то нормальный появится в постгресе?
Нормальный это какой?
Для маленьких баз (гигов так на 100) есть бекап из коробки разных видов (бинарный, текстовый, с разными разделителями и даже зачем то с сжатием), а для больших есть решения для инкрементальных бекапов
Что ещё может понадобиться?
Часть того что вы назвали не является бэкапом. Люди называют экспорт бэкапом... и можно было бы смириться если бы не микрософт и оракл...Часть - не позволяет произвести бэкап в зависимости от структуры данных (у микрософта и оракла с этим проблем нет)
Из того что умеет восстанавливать на произвольный промежуток времени - нельзя развернуть произвольную базу в произвольном месте (у микрософта и оракла с этим проблем нет)
И да, все эти способы забэкапить - РАЗНЫЕ, по средствам, логике, жизненному циклу...
Зоопарк разношерстных хреновых инструментов а не бэкап.Посмотрите на бэкап микрософта и оракла.
Мы в качестве бекапа используем целый сервер и называем его stabdby. А так как он у нас на виртуалке то можем всегда его перекинуть куда угодно. А если знаем примерно куда кидать, то отправляем туда snapshot, виртуалки.
че только не узнаешь на ночь глядя... стэндбай это не бэкап. или у вас стэндбай на ленте? и сколько у вас баз в кластере? и ради восстановления одной базы вы перекидываете кудато целую виртуалку? жесть...
С бакапами там всё худо/бедно нормально.С кластеризацией непонятки.
все там понятно. кластер там один - стэндбай.
то что назвали кластером в постгрес про- недоразумение...