View vs. Materialized View | A Beginner’s Guide with AWS Athena & Redshift

View vs. Materialized View สองอย่างนี้แตกต่างกันอย่างไรและมาลองสร้างที่ Redshift กับ Athena กันดู

What is View Table

การ Query ข้อมูลที่ได้จาก Database หรือ Warehouse นั้นปรกติเราก็ดึงจาก Table ตรงๆเลยใช่ไหมครับ แต่ทีนี้ถ้าเราต้องมีการเรียกใช้ ซ้ำๆหรือมีความจำเป็นต้องมีการเอา Query ที่เราเขียนไปใช้ในที่อื่นๆ เช่นใน Backend, ETL หรือ ELT อื่นๆ เป็นต้น เราก็ต้องเอา SQL ที่เราเขียนไปใส่ด้วย แต่ทีนี้ลองนึกดูว่า SQL ที่เราเขียนนั้นมันยาวซัก 100+ บรรทัด สิ่งที่เกิดขึ้นคืออะไรครับ รก! การจัดการ Script ก็ทำได้ลำบาก

ยกตัวอย่าง จากในรูปจะเห็นได้ว่า SQL นี้มีความยาวและซับซ้อนมากๆ ทำให้การ Copy ไปใช้ที่ต่างๆหรือ เอาไปเขียนต่อทำให้ ยุ่งยาก และ มีโอกาศเกิดข้อผิดผลาดได้สูง หมายถึง Copy ไปแล้วเกิด Syntax เพี้ยน😅

เพราะงั้นสิ่งที่เรียกว่า View table จึงได้เกิดขึ้นมา 🔥 เพื่อลดความยุ่งยากในการเรียกใช้ ทำให้ SQL ที่เราเห็นด้านบนจะเหลือแค่ตามตัวอย่างด้านล่าง

-- Example usecase, which is not really a good usecase LOL
SELECT * FROM company_table
WHERE member_id IN (SELECT employee_id FROM view_table)

-- If we not using view table
SELECT * FROM company_table
WHERE member_id IN (
SELECT employee_id 
FROM abc as a
LEFT JOIN efg as e
ON a.id = e.id
.
.
.
.
WHERE id IS NOT NULL);

จะเหมือนกับการเรียกใช้ Table ปรกติเลย แค่ว่าข้อมูลที่ได้ก็คือผลลัพธ์จาก Query ที่อยู่ภายใต้ View table นั้นเอง

แต่ !! Data warehouse ยุคนี้ต่างก็มีทั้ง View Table และ Materialized View Table สองอย่างต่างกันยังไง หัวข้อถัดไปจะอธิบาย View แต่ละชนิด

View Table

View Table คือลักษณะจำลองของตาราง กล่าวคือเมื่อเราได้สร้าง View table แล้วนั้นจะไม่ได้มีการเก็บข้อมูลที่เป็น Physical อยู่ใน Database แต่เวลาที่เรียกใช้จะเป็นการสั่งให้ Query ที่สร้าง View table ขึ้นมาทำงาน เพราะฉะนั้น เราจะสร้างอีกกี่ร้อย View table พื้นที่จัดเก็บก็ไม่ได้เพิ่มขึ้นแต่อย่างไร มาดูวิธีสร้าง View table

-- syntax
CREATE [ OR REPLACE ] VIEW name [ ( column_name [, ...] ) ] AS query
[ WITH NO SCHEMA BINDING ] -- [] optional
-- example  use               
CREATE VIEW vw_myevents
AS
SELECT id FROM mockl;

พอเราได้สร้าง View table แล้วเมื่อลอง refresh ดูแล้วเราจะพบว่ามี View table อยู่ในส่วนของ View แล้ว ทั้ง Redshift และ Athena โดยสอง Service มี syntax ที่ใช้จะคล้ายๆกัน ก็คือ CREATE VIEW

โดยใน Redshift เราสามารถดูได้ว่าภายใต้ View นั้นสามารถดู Query ได้ว่ามีอะไรบ้างสามารถกดดูได้โดยคลิ๊กขวาเลือก Show view difinitions และสามารถแก้ไขเพิ่มเติมผ่านตรงนี้ได้เลย

ส่วนใน Athena สามารถเลือกดูได้ผ่านการคลิ๊กขวาแล้วเลือก Show/edit Query สามารถแก้ไขเพิ่มเติมผ่านตรงนี้ได้เลย

Materialized View

Materialized View คือ View ที่คล้ายๆกับ View table ปรกติเลยแต่แค่ว่าสิ่งเพิ่มเติมมานั้นคือ Materialized View จะเอาข้อมูลที่ได้จากการ Query มาสร้าง Table เป็น Physical table ที่มีการจัดเก็บอยู่ใน Database

ทำให้การ Query ข้อมูลจะทำได้เร็วกว่าการทำเป็น View table เฉยๆ อย่างเช่น เรามีการ Join table A กับ table B เอาไว้ ถ้าเราทำเป็น View table เวลาที่เรา Query view table นั้นเรา ก็จะเกิดการประมวลผลที่ต้องไปเอาข้อมูล Table A และ table B มา Join ใหม่ทุกครั้ง แต่ถ้าเป็น Materialized View การประมวลผลจะไม่ได้มีการ Join แล้วเพราะข้อมูลที่ได้ Join ถูกจัดเก็บมาไว้แล้ว

มาลองทำ Materialized View ผ่าน Redshift (Athena จะไม่สามารถสร้าง Materialized View ได้เนื่องจาก Athena เป็น Serverless query engine จะไม่ได้มีการจัดเก็บข้อมูลอะไรไว้เลย ก็เลยทำให้ไม่สามารถสร้างได้ ทางแก้คือสร้าง Table จาก Query แล้วไปเก็บที่ S3 ก็ได้😁)

-- syntax
CREATE MATERIALIZED VIEW mv_name
[ BACKUP { YES | NO } ]
[ table_attributes ]
[ AUTO REFRESH { YES | NO } ]
AS query 

-- example use
CREATE MATERIALIZED VIEW "public"."mvw_myevent_demo"
AUTO REFRESH YES
AS
SELECT
    id, first_name, last_name
FROM
    "public"."mockl"

เมื่อเรารีเฟรชหน้า Editor ดูแล้วจะพบว่าได้มี Materialized View ไปอยู่ในส่วนของ View เรียบร้อยแล้ว และอย่างที่บอกไว้ว่า Materialized View นั้นจะเป็นการเก็บข้อมูลอยู่ใน Database ด้วย เราจึงเห็นได้ว่าเวลาที่ Query ผ่าน SVV_TABLE_INFO (ตารางที่เก็บข้อมูลของ System table และ User-defined tables) จะพบว่ามีเฉพาะ Materialized View แต่ไม่มี View table พร้อมทั้งแสดงให้เห็นถึงขนาดของข้อมูลด้วย

ในส่วนของ Limitations นั้นก็ไม่ใช่น้อยๆเหมือนกันของ Materialized View ตัวอย่างสิ่งที่จะไม่สามารถนำมาสร้าง Materialized View ได้เช่นตัวอย่างต่อไปนี้🤓:

Standard view หรือ system tables และ view
ตารางชั่วคราว (Temporary tables)
ฟังก์ชันที่ผู้ใช้กำหนดเอง (User-defined functions)
คำสั่ง ORDER BY, LIMIT หรือ OFFSET

Pros and Cons of View and Materialized View

View Pros:

ทำให้การ Query ง่ายขึ้นจากที่ต้อง Query ยาวๆเหลือแค่ 1 บรรทัด
ทุกครั้งที่ Query ข้อมูล จะได้ข้อมูลที่เขียนใน View เอาไว้เสมอ เช่นถ้า ใน View ไม่มีการ Filter ข้อมูลไว้ (Where) เราก็จะได้ข้อมูลที่สดใหม่

View Cons:

เวลาจะแก้ไขอะไรใน View จะต้องแก้และสร้างทับใหม่
ถ้าเกิด Table ต้นทางของ Query ใน View นั้นมีการเปลี่ยนแปลงอาจจะส่งผลกระทบทำให้ View ไม่สามารถทำงานได้
จากข้อดีที่จะได้ข้อมูลสดใหม่ แต่ก็มีข้อเสียด้วยคือการที่ไม่สามารถทำ Index หรือ Optimise อะไรได้ต้องทำผ่าน Table ที่อยู่ใน View อีกที

Materialized View Pros:

ความรวดเร็วในการ Query เพราะเราไม่ได้ดึงข้อมูลจากต้นทางแต่เป็นข้อมูลที่ Materialized View เก็บเอาไว้แล้ว
ลดขั้นตอนการทำ ETL/ELT ด้วยและยังสามารถแก้ไขได้ง่ายๆแทนที่จะสร้าง Table ใหม่ผ่านการทำ ETL/ELT
ใน Redshift มีความสามารถในการ Auto refresh ด้วยก็คือจะมีการ อัพเดทข้อมูลตาม Table ต้นทางด้วย ทำให้ไม่สร้าง Pipeline ที่คอยอัพเดทข้อมูล

Materialized View Cons:

การใช้งานความจุของ Database จะเพิ่มขึ้นตาม Materialized View เพราะคล้ายกับการสร้าง Table ใหม่ขึ้นมานั้นเอง
ไม่เหมาะกับข้อมูลที่เป็น Realtime ที่มีการอัพเดทข้อมูลตลอด จะเหมาะข้อมูลที่เป็น Batch มากกว่า (ถึงจะมี Manual refresh ก็ตาม)
ไม่สามารถสร้างได้บน Athena

When to choose between View and Materialized View

เรื่องการเลือกใช้ว่าเราจะใช้งานอะไร ผมมีหลักประมาณนี้

View ถ้าไม่อยากเพิ่มค่าใช้จ่ายเกี่ยวกับการจัดเก็บข้อมูล
View ถ้าต้องการใช้งานร่วมกับ Realtime data
View ถ้า Query นั้นเป็น Query เรียบง่ายไม่ได้ซับซ้อนอะไร
Materialized View ถ้าต้องการเพิ่ม Performance การ Query ข้อมูลเพื่อไปออก Dashboard กรณีที่มีการประมวลผลก่อนนำออกไปใช้
Materialized View ลดการประมวลผล ที่เกิดจาก Query ที่ซับซ้อนเพราะ Materialized View จะประมวลผลให้เรียบร้อยและเก็บเป็น Physical table เอาไว้ให้

หวังว่าจะมีประโยชน์นะครับ

Clouddatalabor