Materialized Views in Amazon Redshift PART1
By: Ayush Pareek
Tags: Redshift, Tableau, Database, Data, AWS

Why do we need materialized views in amazon redshift?

In data warehousing, Sometimes you need to query a very large table or the combination of multiple tables like a fact and multiple dim across it for getting the desired aggregated output. These queries are not performative and consume a lot of DB resources.

In BI we use a lot of types of visualization tools like tableau, Quicksight Looker power BI, etc and they have their own caching mechanism but query pattern for each and every dashboard is unique and accessing them each time will trigger the same queries again and again on DB, and caching all these data on a visualization tool server is a bit hard.

(Please note here I am not talking about the data cubes, data extracts which we store on the visualization server but the dashboards which fetch the data directly from the databases. )

To overcome this problem, recently redshift has introduced the support for materialized views so that we can deal with the above scenarios.

Let’s deep dive into Redshift Materialized views.

Materialized views (MV) contains pre-computed results sets. You can create them by issuing a select statement on one or multiple tables in a similar fashion as we create normal views in the databases. But the main difference is that the precomputed results in MVs are not connected with the underlying or base tables.

Let suppose we have a BI dashboard that is slow because every time when user access that particular dashboard it fires quires on DB and uses DB resources.

But we know and can predict the queries behind it as these are repetitive queries, based on those queries we can create MV so that insisted on recalculating everything again in the dashboard. Queries can be pointed to the pre-computed MVs.

Kindly note that we no need to specify the MVs in our queries, redshift does it via AQMVE (Advance Query Materialize View engine)

When redshift gets the query its AQMVE job to predict which MVs have the desired output for that query then it rewrites the query for fetching the data from that MV. If it doesn’t find any MVs for some queries then it goes directly to the tables mentioned in the queries.

Let’s Create the MVs in redshift

I have a table that contains the daily status of all the items which are active and sellable on an online shop.

We want to create a pre-aggregated Mv for our monthly dashboards which use the daily item status table.

CREATE

MATERIALIZED VIEW mv_item_status_monthly

BACKUP YES

DISTSTYLE EVEN

AUTO REFRESH YES

AS

SELECT item_code,

MAX(is_active) is_active,

MAX(is_sellable) is_sellable,

year_month

FROM f_item_status a

INNER JOIN star_analytical.d_calendar b

ON a.period_date = b.date

GROUP BY item_code, year_month;

‘Backup yes’ means this mv is part of a regular or automatic backup of the redshift cluster on S3

You can specify the tableau attributes like diststyle , distkey, and sortkey on MV as they actually store the data like tables.

‘Auto Refresh yes’ Means whenever data is refreshed in the underlying table, MV’s data is updated automatically based on the availability of the resources on the redshift cluster

Dropping an MV is just similar to drop the other objects in DB.

DROP MATERIALIZED VIEW mv_item_status_monthly;

I will cover other operations and what is happing behind MVs in the part of this blog so stay tuned ….!