Parallel query processing ตอนที่ 1

เมื่อใดที่เราควรใช้ Parallel processing

ครั้งหนึ่งเมื่อเหล่า Developer เห็นผมใช้ Parallel hint เพื่อทำให้ได้ผลลัพธ์จาก Query เร็วขึ้น ไม่นานหลังจากนั้น ทุกๆ SQL ที่ถุกสร้างขึ้นโดย developer ท่านนั้นจะมีส่วนของ Parallel hint เพิ่มขึ้นมาด้วยตามแบบอย่างที่ผมทำให้พวกเค้าเห็น และหลังจากนั้นไม่นาน ประสิทธิภาพของระบบก็แย่ลงเนื่องมาจากการใช้ Parallel processing ที่มากเกินความจำเป็น

บทเรียนจากเรื่องนี้คือ ถ้ามี SQL ที่ถูกเรียกใช้งานพร้อมๆ กันบนฐานข้อมูลพยายามที่จะใช้ทรัพยากรทั้งหมดของระบบ (โดยเฉพาะแบบParallel processing) นั่นคือยิ่งจะทำให้ประสิทธิภาพของระบบแย่ลง ไม่ใช่ทำให้ดีขึ้น ดังนั้นเราควรเลือกใช้ Parallel เมื่อทำแล้วมั่นใจว่าทำให้ประสิทธิภาพดีขึ้นเท่านั้นโดยไม่ได้ไปกระทบกับประสิทธิภาพในส่วนอื่นๆ บนฐานข้อมูล

ในส่วนของบทความที่จะเขียนต่อไปนี้จะกล่าวถึงลักษณะของเหตุการณ์ว่าเมื่อใดเราควรเลือกใช้ Parallel SQL

เมื่อระบบของคุณมีจำนวนของ CPU Core เพียงพอสำหรับการทำ Parallel processing

การที่ Parallel processing จะมีประสิทธิภาพมากที่สุดบนฐานข้อมูลนั้น สิ่งสำคัญที่สุดสิ่งหนึ่งที่ขาดไม่ได้เลยนั่นก็คือการที่ระบบของคุณมีจำนวน CPU Core มากมายเพียงพอ นั่นเพราะแทบจะทุก Activity บนระบบนั้นๆ จะถูกใช้งานบน Oracle ซึ่งจำเป็นต้องใช้ทรัพยากรของระบบนั่นก็คือ CPU ถ้าระบบใดๆ นั้นมี CPU Core เพียงตัวเดียว Parallel process ใดๆ นั้นก็จะใช้งานบน CPU นั้นๆ และสุดท้ายก็จะทำให้ประสิทธิภาพของฐานข้อมูลแย่ลง

จนกระทั่งในปัจจุบัน คอมพิวเตอร์เกือบทั้งหมดประกอบไปด้วย CPU Core มากกว่า 1 ตัวขึ้นไป ยกตัวอย่างเช่น Dual-core (2 CPU บน 1 processor slot) ซึ่งการใช้งานฐานข้อมูลขนาดเล็กส่วนใหญ่จะถูกใช้งานบน Desktop และบน Laptop ทั่วๆ ไปเพื่อพัฒนาขึ้นมาเป็นDevelopment server แต่อย่างไรก็ตาม ฐานข้อมูลที่ถูกพัฒนาขึ้นมาบน Virtual Machine ก็ยังถูกจำกัดให้ใช้ CPU Core เพียงแค่ 1 ตัวเท่านั้น

ข้อมูลบนฐานข้อมูลถูกจำแนกออกไปอยู่คนละ Disk drive

หลาย SQL Statement สามารถแก้ปัญหาโดยทำให้การเข้าถึงข้อมูลบน Disk น้อยลงหรือไม่ถูกเข้าถึง Disk เลยเมื่อผลลัพธ์ของข้อมูลที่ต้องการนั้นสามารถพบได้ใน Buffer cache แต่อย่างไรก็ตาม Full table scan บน Table ที่มีขนาดใหญ่ เป็นตัวอย่างปกติของ Operationที่ควรใช้ Parallel processing โดยขึ้นอยู่กับว่า SQL ที่ใช้ Full scan table นั้นมีการเข้าถึงข้อมูลบน Disk มากแค่ไหน แต่ถ้าข้อมูลนั้นถูกเก็บไว้บน Disk ลูกเดียวกัน Parallel processing อาจจะไม่ช่วยทำให้ประสิทธิภาพของ SQL ดีขึ้น

การทำ Parallel processing นั้นจะเห็นผลมากที่สุดถ้าข้อมูลถูกจำแนกออกไปอยู่ใน Disk หลายๆ ลูก

เลือก SQL ที่ใช้เวลานานในการทำงานเพื่อทำ Parallel processing

Parallel processing ควรใช้กับ SQL statement ที่ใช้เวลานานบนฐานข้อมูลที่มีการใช้งานพร้อมๆ กันน้อย หรือพูดง่ายๆ ว่า Parallel processing ไม่เหมาะกับฐานข้อมูลแบบ OLTP

Parallel processing มักถูกนำมาใช้งานในแบบต่างๆ เหล่านี้
– การเรียก Report ที่ต้องใช้เวลานานในการทำงาน
– Update operation บน Table ขนาดใหญ่
– การ Rebuild index บน Table ขนาดใหญ่
– การสร้าง Temporary table สำหรับฐานข้อมูลแบบ Analytical processing
– การ Rebuild table เพื่อเพิ่มประสิทธิภาพหรือการ Purge ข้อมูลที่ไม่ต้องการบน Table

อย่างที่ได้กล่าวไปแล้วว่า Parallel processing นั้นไม่เหมาะอย่างยิ่งที่จะนำมาใช้บนฐานข้อมูลแบบ OLTP เนื่องจากลักษณะของฐานข้อมูลแบบ OLTP นั้น จะมีการเข้ามาใช้งานพร้อมๆ กันหลายๆ Session ซึ่งการใช้งานทรัพยากรบนระบบนั้นจะถูกใช้งานอยู่ตลอดเวลานั่นก็เพราะแต่ละ Transaction สามารถทำงานบน CPU คนละตัวได้ การเลือกใช้งาน Parallel processing บนระบบ OLTP จะทำให้ประสิทธิภาพโดยรวมของฐานข้อมูลแย่ลงนั่นก็เพราะผู้ใช้งาน 1 Session สามารถจอง CPU Core เพื่อการทำงานได้หลายๆ ตัวในเวลาเดียวกัน

SQL statement อย่างน้อยควรมี Full table scan, Full index scan หรือ Partition scan

โดยปกติแล้ว Parallel processing จะถูกใช้สำหรับ Query ที่ประกอบด้วย table scan, index scan หรือ partition table อยู่แล้ว อย่างไรก็ตาม Query ต่างๆ นั้นสามารถประกอบไปด้วยหลายๆ operation ในกรณีสำหรับ nested loop join นั้นซึ่งจะใช้ index ในการjoin table สามารถทำ Parallel processing ได้ ซึ่งจะทำให้เกิด table scan ขึ้น

ถึงแม้ว่า query ที่ทำการเข้าถึงข้อมูลผ่าน index จะไม่สามารถใช้ Parallel processing ได้โดยปกติแล้ว แต่ถ้าเกิดเป็น Query ที่มีการอ่านข้อมูลจาก Partitioned table และมี Partitioned index เมื่อนั้นจึงจะสามารถทำ Parallel processing ได้

มั่นใจว่ามีทรัพยากรเหลือเพียงพอบนระบบ

ถ้าระบบของคุณใช้ทรัพยากรเครื่องจนหมดแล้วการทำ Parallel processing อาจจะทำให้ประสิทธิภาพของระบบแย่ลง Parallel processing จะสามารถทำงานได้ดีกับ Query ที่เหมาสมและมี CPU Core เหลือเพียงพอ

ควรจำไว้ว่าเมื่อใดที่มีการใช้ Parallel processing จะมีการใข้ทรัพยากรระบบมากขึ้นกว่าเดิม ถ้าหลายๆ Query ต่างเรียกใช้ Parallel processing พร้อมๆ กัน นั่นหมายถึงการที่หลายๆ process จำเป็นต้องขอทรัพยากรระบบและจำเป็นต้องรอจนกว่า process ที่ทำงานอยู่เสร็จ จึงเริ่มทำงานต่อกันได้ เมื่อนั้นประสิทธิภาพระบบจะแย่ลงมากกว่าที่จะดีขึ้น

SQL ที่ถูก tune มาอย่างดีแล้ว

การทำ Parallel processing กับ Query ที่แย่อาจจะช่วยลดเวลาในการ execute ได้ อย่างไรก็ตามคุณจะสังเกตเห็นว่ามันจสร้างผลกระทบให้กับส่วนอื่นๆ บนระบบได้ คุณควรมั่นใจว่า Query จะทำงานได้ดีขึ้นเมื่อคุณตัดสินใจที่จะทำ Parallel processing บน Query นั้นๆ และที่สำคัญคือ Parallel processing นั่นไม่ใช่ทางเลือกที่ดีสำหรับการ Tuning SQL ครับ

ปล. เพื่อป้องกันการทำงานที่เกินขีดจำกัดของระบบ คุณจำเป็นต้องศึกษาว่า ณ สถานการณ์ใดควรใช้ Parallel processing? และควรทำความเข้าใจเมื่อใช้ Parallel SQL บน Oracle และการ Monitor parallel SQL นั้นทำอย่างไร?

Credit: http://searchitchannel.techtarget.com

Parallel Query Processing

Advertisements

ใส่ความเห็น

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  เปลี่ยนแปลง )

Google+ photo

You are commenting using your Google+ account. Log Out /  เปลี่ยนแปลง )

Twitter picture

You are commenting using your Twitter account. Log Out /  เปลี่ยนแปลง )

Facebook photo

You are commenting using your Facebook account. Log Out /  เปลี่ยนแปลง )

Connecting to %s