การทำ Performance Tuning SQL Query เบื้องต้น (2)


การ Tuning Query นั้น จากประสบการณ์ของผม ควรจะมีขั้นตอนในการ Tune ดังนี้ครับ

Performance Baseline Measurement
Database Design
Optimizing Query Syntax
Index Strategy
Reduce Locking and Blocking
Database Server Configuration
Data Warehouse Strategy
Hardware Upgrade Strategy
1) Performance Baseline Measurement
ก่อนที่จะลงมือทำการ Tuning ใดๆ ผมมีข้อแนะนำครับ เราควรจะทำการวัด baseline ทั้งหมดก่อน เช่น cpu percent processing, disk queue, query time, no. of page scan เป็นต้น

ถ้าถามว่าทำเพื่ออะไร ผมมีเหตุผลง่ายๆ โดยการสมมติครับ เหมือนกับว่าเราเป็นไข้ไปหาหมอ (หมออีกแล้ว!!!) ทางคุณหมอก็จะทำการวัดไข้แล้วบันทึกลงไปใช่ไหมครับ สมมติว่าเราวัดไข้ได้ 38 องศา ทีนี้พอเราได้ยามาทาน เราก็จะสามารถทราบได้ว่าไข้มันลดลงหรือยังโดยการวัดไข้อีกครั้งนึง เพื่อเปรียบเทียบว่าลดลงจาก 38 องศาหรือเปล่า แต่ถ้าเราไม่ได้วัดไข้ก่อนกินยา เราก็จะไม่สามารถทราบได้เลยว่า ยาที่เราทานนั้น ได้ผลหรือไม่ครับ

ก่อนที่จะเริ่มทำการ Tuning ก็เหมือนกันครับ เราควรจะวัด baseline ทั้งหมดก่อน แล้วหลังจากนั้นเราค่อยลงมือการทำการ Tuning แล้ววัดตัวเลขทั้งหมดอีกครั้ง เพื่อเปรียบเทียบว่ามันดีขึ้นหรือแย่ลงน่ะครับ

เครื่องมือที่ใช้ปกติก็จะมี Performance Monitor กับ SQL Profiler ส่วนวิธีการใช้งานจะกล่าวถึงในตอนต่อๆ ไปครับ

2) Database Design
จุดแรกที่ควรจะเริ่มลงมือ tuning ถ้าเป็นไปได้ ก็ควรจะเป็นที่ Database Design ครับ เพราะว่าเป็นจุดที่ใหญ่ที่สุดในเรื่อง performance ครับ ถ้า design ดีก็ถือว่ามีชัยไปกว่าครึ่งแล้ว

Database Architecture ที่นิยมที่สุดในโลกนี้ก็คือ Relational Database แต่รู้ไหมครับว่า Relational มีจุดเสียที่ใหญ่ที่สุดอยู่ข้อนึงก็คือ ถ้า Query ข้อมูลโดย join table หลายๆ table เข้าไปหล่ะก็ รับรองครับ ช้าแน่ๆ

วิธีแก้ง่ายๆ ก็คือ เราอาจจะพิจารณา Database Architecture แบบอื่นเข้าไปครับ ลองพิจารณา Database Architecture ดังรายการต่อไปนี้ดูสิครับว่า Architecture แบบไหน เหมาะกับการทำ Query มากที่สุด

Relational
Hierarchical
Object Oriented DB
Document DB
Network DB
คำตอบก็คือ Hierarchical ครับ ดังนั้นวิธีการออกแบบ Database ที่มีประสิทธิภาพที่สุด ก็ควรจะเป็นดังรูปถัดไปครับ

รูป 2-1 Data Warehouse Concept

จากรูป 2-1 จะเห็นว่าจะเป็นก้อน Relation เราจะใช้เป็น Data Entry อย่างเดียว ส่วนก้อนด้านล่าง เราจะใช้เพื่อ Query ในการออก Report ครับ

ทีนี้ในการออกแบบก็คือส่วนที่เป็น RDB เราก็พยายามใช้หลักการ Normalization ให้เต็มที่ หรือพยายามทำให้ RDB รับผิดชอบเฉพาะคำสั่ง Insert, Update, Delete ให้ดีก็พอครับ

ส่วนก้อน HDB ก็พยายามออกแบบให้รองรับ Query ให้ดีที่สุด เป็นการแบ่งหน้าที่รับผิดชอบอย่างชัดเจนครับ

ในทางปฏิบัติ เราจะมาถึง Data Warehouse ได้จริงๆ ก็คงจะต้องพยายาม tune rdb ให้เต็มที่ก่อนแหล่ะครับ สำหรับ database เล็กๆ ผมจะไม่แนะนำ แต่ถ้าเป็น database ใหญ่ๆ วิธีนี้ก็อาจจะเป็นวิธีที่ช่วยให้เราหลีกเลี่ยงการ upgrade hardware มาหลาย project แล้วครับ

สำหรับ database เล็กๆ เราก็มีวิธีการ Tuning ในหนทางของมันอยู่ เอาไว้ผมจะค่อยๆ เขียนในบทความต่อๆ ไปครับ

3) Optimizing Query Syntax
เป็นจุดที่ผมได้รับคำถามมากที่สุดเลยครับ ประมาณว่า “เขียน query แบบไหนจะเร็วกว่ากัน”

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

4) Index Strategy
เป็นวิธีที่นัก Tuning หลายๆ ท่านมันนิยมทำกันมากที่สุด และก็เป็นวิธีที่ผมนิยมทำเสียด้วย เหตุผลน่ะหรือครับ? เพราะว่าทำได้ง่ายและรวดเร็วไงครับ และที่สำคัญ เราไม่ได้ไปแก้ไข Query Syntax เลย

หลักการของ Index ก็คือ “ลดจำนวน disk scan” นั่นเองครับ เพราะว่า Bottle neck ที่ใหญ่ที่สุด ก็คือ disk ครับ ถ้าเราหาวิธีลดการ scan disk ลงได้ รับรองว่า เร็วขึ้นชัวร์

วิธีนี้ผมจะอธิบายในตอนถัดไปครับ (Part 3)

ขอจบตอนนี้ที่ขั้นตอนที่ 4 ก่อนนะครับ ส่วนที่เหลือจะขอต่อในตอนต่อไปครับ (post ทีละน้อย แต่จะพยายามขยัน post บ่อยๆ ครับ) ถ้ามี comment บ้าง ก็ขอขอบคุณครับ จะได้เป็นกำลังใจให้ผมเขียนต่อไปเรื่อยๆ ครับ

credit : http://yongyutde.spaces.live.com/blog/cns!A1F444837F369955!550.entry

Advertisements

Leave a Reply

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 / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: