Реферат
ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ
РОССИЙСКАЯ АКАДЕМИЯ НАРОДНОГО ХОЗЯЙСТВА И ГОСУДАРСТВЕННОЙ СЛУЖБЫ
ПРИ ПРЕЗИДЕНТЕ РОССИЙСКОЙ ФЕДЕРАЦИИ
ЛИПЕЦКИЙ ФИЛИАЛ
КАФЕДРА ГУМАНИТАРНЫХ И ЕСТЕСТВЕННОНАУЧНЫХ ДИСЦИПЛИН
Реферат
по дисциплине
«Специальные информационные системы в профессиональной деятельности»
На тему:« Материализованные представления»
Выполнил:
студент 1 курса
группы ЭБЗ-21-1
Вишняков Д.Ю
Проверил:
доцент
Яворский Ю.А.
Липецк - 2022
Содержание
1.Что такое материализованное представление, и зачем его использовать?.....................................................................3
2.Что такое материализованное представление?...............................................................3
3.Материализованные представления по сравнению с обычными представлениями…………………………...4
4.Следует ли мне использовать материализованные представления………………………………………………6
5.Материализованное представление: советы к использованию……………………………………………..7
6.38.3. Материализованные представления……………………………………………………………….….8
7.Заключение……………………………………………...…12
8. Список использованных источников……………………………………………..13
По мере роста объема данных все больше разработчиков обращаются к материализованным представлениям для обработки запросов. Этот подход имеет много возможностей.
В этой статье рассматривается понятие материализованного представления, его условий и тех преимуществ, которое оно дает пользователям. Вы также поймете разницу между представлением и материализованным представлением, и как получить выгоду от использования материализованного представления, если вы этого еще не делали.
Что такое материализованное представление?
Материализованное представление упрощает сложные данные путем сохранения результатов запросов - Вам не придется создавать новый запрос всякий раз, когда вам потребуется доступ к соответствующей информации.
Основное, что выделяет материализованное представление, это копия данных запроса, который не выполняется в реальном времени. Она занимает немного больше места, но зато и данные извлекаются очень быстро. Вы можете настроить материализованные представления на получение обновленных данных по расписанию с тем, чтобы обновленная информация не осталась незамеченной.
При использовании в сочетании с другими инструментами разработки материализованное представление может создать более безопасную среду для вашей базы данных.
Впервые материализованные представления появились в Oracle. Начиная с 8i, они стали частью каждого релиза. Не все среды поддерживают материализованные представления, т.к. это инструмент относительно современных баз данных. Но их поддерживают SQL Server, Sybase SQL Anywhere, а недавно PostgreSQL и BigQuery.
Важность использования материализованных представлений заключается не только в увеличении производительности.
Материализованные представления по сравнению с обычными представлениями
Представления как и материализованные представления могут быть очень полезны для упрощения и оптимизации данных. Вы можете соединить данные из множества разных таблиц и скомпилировать информацию в одну простую таблицу.
Чтобы лучше понять преимущества, которые несет материализованное представление, сравним их с обычными представлениями.
Представление - это виртуальная таблица, которая собирает данные, которые вы ранее собирали из любого другого соответствующего запроса. Всякий раз, когда вы обращаетесь к представлению, оно рекомпилирует данные для предоставления актуальной информации в соответствии с надлежащим запросом.
Вы можете вносить изменения в представление или в базовые таблицы, и данные будут обновляться автоматически в обоих местах. Таким образом, если вы вносите изменения в представление, они будут проникать в данные базовых таблиц. Изменение в базовых таблицах автоматически проникает в представление. По этой причине может потребоваться некоторое время для обновления обычного представления.
Преимущество обычного представления состоит в том, что оно не занимает много места. Но оно проигрывает в скорости и производительности.
Материализованное представление значительно более эффективно при выполнении запросов. Данные физически сохраняются в определенный момент времени. Вам не потребуется всякий раз повторно считывать все данные, связанные с запросом.
Недостатком является то, что не гарантируется, что вы видите самые свежие данные. Чтобы снизить риск получения устаревших данных, вы можете обновлять их вручную или установить обновление по расписанию, или же посредством триггеров.
Следует ли мне использовать материализованные представления
Когда вы понимаете, что делает материализованное представление, может возникнуть вопрос, стоят ли несколько секунд дополнительного места для сохранения копии данных.
Во-первых, стоит сказать об эффективности стоимости. Всякий запрос к базе данных имеет стоимость. Приложения все более интенсивно используют ресурсы. Так каждый шаг выполнения запроса (разбор, валидация, планирование, оптимизация) оценивается временем ЦП, использованием памяти и стоимости.
Материализованные представления существенно снижают стоимость для разработчиков. Результаты, полученные в материализованном представлении сохраняются в памяти. Они обновляются только по мере необходимости, а не на постоянной основе. Тем самым вы улучшаете производительность предварительным вычислением большинства дорогих операций. Кроме того, при их использовании в запросах к большим базам данных может значительно вырасти скорость.
К сожалению, использование материализованных представлений подходит не во всех ситуациях. Во-первых, не всякая база данных поддерживает материализованные представления.
Есть и другие проблемы. Материализованные представления могут использоваться только на чтение. Это означает, что вы не можете обновлять таблицы из материализованного представления так, как вы это делаете с помощью обычного представления. Кроме того, хотя материализованные представления довольно безопасны, все же имеется некоторый риск, поскольку не все функции безопасности присутствуют. Например, вы не можете создать ключи безопасности или ограничения на материализованном представлении.
Материализованное представление: советы к использованию
Вы должны иметь в виду некоторые особенности, чтобы получить максимум пользы от материализованных представлений:
Убедитесь, что вы работаете с материализованным представлением, которое отражает шаблоны запросов к базовой таблице. Не следует создавать материализованные представления для каждой отдельной итерации запроса. Это разрушит цель. Создавайте материализованное представления, которое будет ориентировано на широкий спектр запросов.
Если оригинальная таблица секционирована, вы также должны секционировать материализованное представление. Если этого не сделать, оно может стать больше, чем вы хотели. Секционирование материализованного представления в соответствии с секционированной базовой таблицей гарантирует, что вы сохраните производительность.
Помните о платформах с открытым исходным кодом. Вам потребуется исследовать их уязвимость при создании материализованных представлений. Использование собственного кода лишено уязвимости, влияющего на API. Это может улучшить производительность, и его сложнее взломать.
38.3. Материализованные представления
Материализованные представления в Postgres Pro основаны на системе правил, как и представления, но их содержимое сохраняется как таблица. Основное отличие между:
CREATE MATERIALIZED VIEW mymatview AS SELECT * FROM mytab;
и этой командой:
CREATE TABLE mymatview AS SELECT * FROM mytab;
состоит в том, что материализованное представление впоследствии нельзя будет изменить непосредственно, а запрос, создающий материализованное представление, сохраняется точно так же, как запрос представления, и получить актуальные данные в материализованном представлении можно так:
REFRESH MATERIALIZED VIEW mymatview;
Информация о материализованном представлении в системных каталогах Postgres Pro ничем не отличается от информации о таблице или представлении. Поэтому для анализатора запроса материализованное представление является просто отношением, как таблица или представление. Когда запрос обращается к материализованному представлению, данные возвращаются непосредственно из него, как из таблицы; правило применяется, только чтобы его наполнить.
Хотя обращение к данным в материализованном представлении часто выполняется гораздо быстрее, чем обращение к нижележащим таблицам напрямую или через представление, данные в нём не всегда актуальные (но иногда это вполне приемлемо). Рассмотрим таблицу с данными продаж:
CREATE TABLE invoice (
invoice_no integer PRIMARY KEY,
seller_no integer, -- идентификатор продавца
invoice_date date, -- дата продажи
invoice_amt numeric(13,2) -- сумма продажи
);
Если пользователям нужно быстро обработать исторические данные, возможно их интересуют только общие показатели, а полнота данных на текущий момент не важна:
CREATE MATERIALIZED VIEW sales_summary AS
SELECT
seller_no,
invoice_date,
sum(invoice_amt)::numeric(13,2) as sales_amt
FROM invoice
WHERE invoice_date < CURRENT_DATE
GROUP BY
seller_no,
invoice_date
ORDER BY
seller_no,
invoice_date;
CREATE UNIQUE INDEX sales_summary_seller
ON sales_summary (seller_no, invoice_date);
Это материализованное представление может быть полезно для построения графика в информационной панели менеджеров по продажам. Для ежесуточного обновления статистики можно запланировать задание по расписанию, которое будет выполнять этот оператор:
REFRESH MATERIALIZED VIEW sales_summary;
Ещё одно применение материализованного представления — предоставить быстрый доступ к данным, получаемым с удалённой системы через обёртку сторонних данных. Ниже приведён простой пример с обёрткой file_fdw, с замерами времени, но так как при этом использовался кеш локальной системы, выигрыш в производительности при обращении к удалённой системе обычно будет гораздо больше, чем показано здесь. Заметьте, что мы также использовали возможность добавить индекс в материализованное представление, тогда как file_fdw индексы не поддерживает; при других видах доступа к сторонним данным такого преимущества может не быть.
Подготовка:
CREATE EXTENSION file_fdw;
CREATE SERVER local_file FOREIGN DATA WRAPPER file_fdw;
CREATE FOREIGN TABLE words (word text NOT NULL)
SERVER local_file
OPTIONS (filename '/usr/share/dict/words');
CREATE MATERIALIZED VIEW wrd AS SELECT * FROM words;
CREATE UNIQUE INDEX wrd_word ON wrd (word);
CREATE EXTENSION pg_trgm;
CREATE INDEX wrd_trgm ON wrd USING gist (word gist_trgm_ops);
VACUUM ANALYZE wrd;
Теперь давайте проверим написание слова. Сначала непосредственно через обёртку file_fdw:
SELECT count(*) FROM words WHERE word = 'caterpiler';
count
-------
0
(1 row)
Выполнив EXPLAIN ANALYZE, мы получаем:
Aggregate (cost=21763.99..21764.00 rows=1 width=0) (actual time=188.180..188.181 rows=1 loops=1)
-> Foreign Scan on words (cost=0.00..21761.41 rows=1032 width=0) (actual time=188.177..188.177 rows=0 loops=1)
Filter: (word = 'caterpiler'::text)
Rows Removed by Filter: 479829
Foreign File: /usr/share/dict/words
Foreign File Size: 4953699
Planning time: 0.118 ms
Execution time: 188.273 ms
Если же теперь обратиться к материализованному представлению, запрос выполнится гораздо быстрее:
Aggregate (cost=4.44..4.45 rows=1 width=0) (actual time=0.042..0.042 rows=1 loops=1)
-> Index Only Scan using wrd_word on wrd (cost=0.42..4.44 rows=1 width=0) (actual time=0.039..0.039 rows=0 loops=1)
Index Cond: (word = 'caterpiler'::text)
Heap Fetches: 0
Planning time: 0.164 ms
Execution time: 0.117 ms
В любом случае слово записано неправильно, поэтому давайте попробуем найти то, что имелось в виду. Сначала опять через file_fdw:
SELECT word FROM words ORDER BY word <-> 'caterpiler' LIMIT 10;
word
---------------
cater
caterpillar
Caterpillar
caterpillars
caterpillar's
Caterpillar's
caterer
caterer's
caters
catered
(10 rows)
Limit (cost=11583.61..11583.64 rows=10 width=32) (actual time=1431.591..1431.594 rows=10 loops=1)
-> Sort (cost=11583.61..11804.76 rows=88459 width=32) (actual time=1431.589..1431.591 rows=10 loops=1)
Sort Key: ((word <-> 'caterpiler'::text))
Sort Method: top-N heapsort Memory: 25kB
-> Foreign Scan on words (cost=0.00..9672.05 rows=88459 width=32) (actual time=0.057..1286.455 rows=479829 loops=1)
Foreign File: /usr/share/dict/words
Foreign File Size: 4953699
Planning time: 0.128 ms
Execution time: 1431.679 ms
Затем через материализованное представление:
Limit (cost=0.29..1.06 rows=10 width=10) (actual time=187.222..188.257 rows=10 loops=1)
-> Index Scan using wrd_trgm on wrd (cost=0.29..37020.87 rows=479829 width=10) (actual time=187.219..188.252 rows=10 loops=1)
Order By: (word <-> 'caterpiler'::text)
Planning time: 0.196 ms
Execution time: 198.640 ms
Если периодическое обновление данных из другого источника в локальной базе данных вас устраивает, этот подход может дать значительный выигрыш в скорости.
Заключение
Использование материализованных представлений вместо непосредственного извлечения данных из базовых таблиц или использования обычных представлений может помочь оптимизировать производительность и увеличить продуктивность данных.
Использование материализованных представлений уменьшает стоимость ваших данных и увеличивает скорость выполнения запросов. Хотя стоимость компьютеров постоянно снижается, стоимость данных остается весьма высокой. Поиск способов снижения затрат на данные и их хранение, таких как использование материализованных представлений, является ключевым в цифровую эпоху.
Список использованных источников:
https://postgrespro.ru/docs/postgrespro/9.5/rules-materializedviews