Storage Engine – บทบาทในการเพิ่มประสิทธิภาพการค้นหา DAX ใน LuckyTemplates

ในบทช่วยสอนนี้ เราจะดูกลไกที่สองภายในบริการวิเคราะห์ — เครื่องมือจัดเก็บข้อมูล

เราได้พูดถึงกลไกระดับบนสุดกลไกสูตรในบทช่วยสอนที่ผ่านมา เมื่อผู้ใช้เข้าใจวิธีการทำงานของกลไกทั้งสองนี้ การปรับให้เหมาะสมและปรับปรุงประสิทธิภาพการสืบค้น DAX ของคุณจะง่ายขึ้น

จุดประสงค์หลักของกลไกการจัดเก็บข้อมูลคือการทำงานโดยตรงกับฐานข้อมูล

กลไกจัดการสูตรไม่สามารถเข้าถึงฐานข้อมูลได้โดยตรง ดังนั้นโดยปกติแล้วจะต้องผ่านกลไกการจัดเก็บเพื่อจุดประสงค์นี้

เครื่องมือจัดเก็บข้อมูลมีสองประเภท — โหมดนำเข้าและ DirectQuery คุณสามารถผสมและจับคู่ทั้งสองประเภทในตัวแบบข้อมูลเดียวกันเพื่อสร้างแบบจำลองแบบผสม

สารบัญ

• การทำงานกับโหมดนำเข้าใน Storage Engine
• การทำงานกับ DirectQuery ใน Storage Engine
• การทำงานกับโมเดลคอมโพสิต
• ประเด็นสำคัญอื่นๆ เกี่ยวกับ Storage Engine
• ทำงานกับแบบสอบถามที่ซับซ้อน
• บทสรุป

การทำงานกับโหมดนำเข้าใน Storage Engine

ก่อนอื่นเรามาพูดถึงโหมดการนำเข้ากันก่อน สิ่งนี้เรียกอีกอย่างว่า Vertipaq แต่เรียกอีกอย่างว่า xVelocity หรือ In Memory Columnar Database

มีสิ่งสำคัญสี่ประการที่ต้องทำความเข้าใจเกี่ยวกับวิธีการทำงานของโหมดการนำเข้า

ขั้นแรกVertipaq สร้างสำเนาของข้อมูลโดยตรงจากแหล่งข้อมูลและจัดเก็บไว้ใน RAM ในรูปแบบที่บีบอัด

ประการที่สองข้อมูลที่ประมวลผลในโหมดนำเข้าจะขึ้นอยู่กับการดำเนินการรีเฟรชครั้งล่าสุด ซึ่งหมายความว่าหากคุณรีเฟรชข้อมูลครั้งล่าสุดเมื่อสัปดาห์ที่แล้ว ข้อมูลที่คุณกำลังจัดการจะยังเป็นข้อมูลเดิมจากสัปดาห์ที่แล้ว นี่เป็นสิ่งสำคัญอย่างยิ่งหากคุณกำลังใช้การตั้งค่าแบบผสมโดยที่ตารางหนึ่งอยู่ในโหมดนำเข้าและอีกตารางหนึ่งอยู่ในโหมด DirectQuery

สมมติว่าคุณมีตารางผลิตภัณฑ์ซึ่งรีเฟรชเมื่อสัปดาห์ที่แล้วในโหมดนำเข้า สำหรับตารางการขาย คุณตัดสินใจที่จะดำเนินการผ่าน DirectQuery เนื่องจากขนาดของตาราง สมมติว่าคุณกำลังสร้างรายงานตามตารางทั้งสองที่คุณนำคอลัมน์แบรนด์มาไว้ในคอลัมน์และสร้างการวัดยอดขายรวมในตารางยอดขายเดียวกัน คุณต้องการแสดงภาพยอดขายตามแบรนด์ด้วย

คุณจะต้องรีเฟรชข้อมูลที่มาจากโหมดนำเข้าก่อน เนื่องจากคุณอาจได้รับข้อมูลที่ใหม่และอัปเดตจาก DirectQuery และข้อมูลที่ล้าสมัยจาก Vertipaq ซึ่งจะทำให้มีแถวว่างสองสามแถวบนเมทริกซ์และการแสดงภาพของคุณ

สิ่งต่อไปที่คุณต้องรู้เกี่ยวกับ Vertipaq ก็คือ การ ดำเนินการพื้นฐานเช่น , , , หรือ เท่านั้น ที่ใช้งานได้ ซึ่งหมายความว่าหากมีการดำเนินการอื่นๆ ที่ซับซ้อนกว่ารวมอยู่ในแผนการสืบค้น เครื่องมือจัดเก็บข้อมูลจะต้องเรียกกลไกจัดการสูตรเพื่อแก้ไขส่วนนี้ของรหัส

สุดท้าย เครื่องมือจัดเก็บเป็นฐานข้อมูลที่ ปรับให้เหมาะสมที่สุดเนื่องจากโครงสร้างคอลัมน์ของ Vertipaq ซึ่งหมายความว่าข้อมูลทั้งหมดจะถูกจัดเก็บแบบคอลัมน์ต่อคอลัมน์ ไม่ใช่แบบแถวต่อแถว เนื่องจากโครงสร้างนี้ Vertipaq จะเร็วกว่าการเชื่อมต่อ DirectQuery เสมอ แม้ว่าคุณจะสร้างดัชนีในแบบจำลองข้อมูลเชิงสัมพันธ์ก็ตาม

การทำงานกับ DirectQuery ใน Storage Engine

ตัวเลือกถัดไปที่เรามีในบริการวิเคราะห์ของ LuckyTemplates คือ DirectQuery หากคุณใช้การเชื่อมต่อ DirectQuery บริการวิเคราะห์จะทำหน้าที่เป็นทางผ่านสำหรับแบบสอบถามที่ส่งโดยกลไกจัดการสูตรเท่านั้น

สมมติว่าคุณเขียนแบบสอบถาม เอ็นจิ้นสูตรจะสร้างแผนการสืบค้น จากนั้นจะส่งต่อแบบสอบถามไปยังเครื่องมือจัดเก็บข้อมูลซึ่งแปลเป็นภาษาแม่ของฐานข้อมูลแล้ว ส่วนใหญ่แล้ว แบบสอบถามเหล่านี้มาใน SQL

หากคิวรีใช้ DirectQuery ให้คาดหวังให้เป็นปัจจุบันตลอดเวลา ไม่ต้องกังวลว่าคุณรีเฟรชข้อมูลครั้งล่าสุดเมื่อใด

กระบวนการปรับโค้ด DAX และโมเดลข้อมูลให้เหมาะสมจะขึ้นอยู่กับวิธีสร้างฐานข้อมูลเชิงสัมพันธ์ด้วย หากคุณมีดัชนีในคอลัมน์ ข้อความค้นหาของคุณจะถูกปรับให้เหมาะสมเสมอ แต่ถ้าฐานข้อมูลของคุณไม่ได้รับการปรับให้เหมาะสมในแง่ของการสร้างรายงานโดยใช้บริการวิเคราะห์หรือ LuckyTemplates คุณอาจเผชิญกับความท้าทายด้านประสิทธิภาพเล็กน้อย ดังนั้นจงตั้งใจสร้างฐานข้อมูลของคุณสำหรับการพัฒนารายงาน

การทำงานกับโมเดลคอมโพสิต

ตัวเลือกที่สามคือการสร้างแบบจำลองผสม เพื่อให้คุณสามารถมีหนึ่งตารางในโหมดนำเข้าและอีกตารางใน DirectQuery

เมื่อคุณใช้สองตารางจากแหล่งที่มาต่างกัน กลไกจัดการสูตรจะส่งหนึ่งคำขอไปยัง Vertipaq และอีกคำขอหนึ่งไปยังแหล่งข้อมูล DirectQuery ในทั้งสองกรณี บริการวิเคราะห์จะดึงแคชข้อมูลจากทั้ง Vertipaq และ DirectQuery กลไกจัดการสูตรจะใช้ JOIN, หรือการวนซ้ำใดๆ บนแคชข้อมูลทั้งสองก่อนที่จะให้ผลลัพธ์แก่ผู้ใช้ปลายทาง

สมมติว่าคุณกำลังพยายามนึกภาพยอดขายตามแบรนด์ของผลิตภัณฑ์ในรายงานของคุณ กลไกจัดการสูตรจะส่งคำขอไปยัง Vertipaq ซึ่งจะดึงข้อมูลผลิตภัณฑ์ ยี่ห้อ และรหัสผลิตภัณฑ์ จากนั้น จาก DirectQuery จะพยายามดึงยอดขาย ราคาสุทธิ ปริมาณการขาย และรหัสผลิตภัณฑ์การขาย

เมื่อมีแคชข้อมูล 2 แคชตามรหัสผลิตภัณฑ์ ก็จะรวมแคชข้อมูล 2 แคชเข้าด้วยกันและคำนวณยอดขายรวม จากนั้นจะนำเสนอผลลัพธ์ให้กับผู้ใช้ปลายทาง

ประเด็นสำคัญอื่นๆ เกี่ยวกับ Storage Engine

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

ดังที่ฉันได้กล่าวไว้ก่อนหน้านี้ กลไกการจัดเก็บข้อมูลจัดเตรียมแคชข้อมูลกลับไปยังกลไกจัดการสูตรในรูปแบบของแคชข้อมูลที่ไม่บีบอัด เมื่อคุณอยู่ในโหมดนำเข้า คำขอที่ส่งกลับไปยัง Vertipaq ในกระบวนการจะดำเนินการในภาษา xmSQL

ภาษา xmSQL ค่อนข้างคล้ายกับ SQL แต่ไม่เหมือนกันทั้งหมด เราจะพูดถึงรายละเอียดเกี่ยวกับ xmSWL เมื่อเราพูดถึงแผนการสืบค้นในบทช่วยสอนอื่น

สิ่งสำคัญคือต้องจำไว้ว่ากลไกการจัดเก็บข้อมูลใช้คอร์ทั้งหมดที่มีอยู่ใน CPU ของคุณ ความสามารถในการใช้หลายคอร์มีประโยชน์ในกรณีที่คุณมีหลายเซกเมนต์ภายในโมเดลข้อมูลของคุณ

สมมติว่าคุณมีตารางใน LuckyTemplates ที่มี 12 ล้านแถว จากนั้นตารางนี้จะถูกแบ่งออกเป็น 12 ส่วน เนื่องจากทั้งใน Power Pivot และ LuckyTemplates แต่ละส่วนจะพอดีกับ 1 ล้านแถว ซึ่งแตกต่างจากบริการวิเคราะห์ทั่วไปที่หนึ่งเซกเมนต์สามารถรองรับได้ 8 ล้านแถว

ดังนั้นหากฉันมี 6 คอร์ใน CPU ทั้ง 6 คอร์จะสแกน 6 คอร์แรกจาก 12 เซกเมนต์พร้อมกัน เมื่อทำเสร็จแล้ว พวกเขาจะไปยังหกส่วนถัดไป

แต่ถ้าฉันทำงานกับบริการวิเคราะห์โดยที่เซกเมนต์เริ่มต้นมี 8 ล้านแถว จะใช้เพียงสองคอร์จากหกคอร์ของฉัน — เซกเมนต์หนึ่งจะประมวลผล 8 ล้านแถว ในขณะที่อีกเซ็กเมนต์ประมวลผล 4 ล้าน

ทำงานกับแบบสอบถามที่ซับซ้อน

ก่อนหน้านี้ ฉันได้กล่าวว่าโหมดนำเข้ารองรับเฉพาะการดำเนินการพื้นฐาน เช่น MIN, MAX, SUM, COUNT และ GROUPBY แล้วจะเกิดอะไรขึ้นถ้าคุณทำงานกับคำค้นหาที่ซับซ้อนกว่านี้

สมมติว่าคุณตัดสินใจใช้คำสั่ง IF ในบริบทของแถว หรือใช้การวนซ้ำซ้อนกัน เช่น SUMX ในตารางผลิตภัณฑ์และการขาย

ในกรณีนี้ เครื่องมือจัดเก็บข้อมูลจะไม่สามารถแก้ไขคำค้นหาได้ด้วยตัวเอง จากนั้นจะเรียกกลไกจัดการสูตร ซึ่งจะเริ่มแก้ปัญหาการคำนวณที่ซับซ้อนทีละแถวภายในกลไกการจัดเก็บ บางคนอาจคิดว่านี่เป็นสถานการณ์ที่ดี โดยที่เครื่องยนต์ทั้งสองทำงานร่วมกัน — แต่สิ่งนี้ยังห่างไกลจากความจริง

คุณจะเห็นว่า เมื่อสิ่งนี้เกิดขึ้น แคชข้อมูลที่สร้างโดยกลไกการจัดเก็บข้อมูลจะไม่สามารถแคชได้ในกรณีที่มี callbackdataID ในแบบสอบถามนั้น ดังนั้น หากคุณรีเฟรชวิชวล การคำนวณแบบเดียวกันจะต้องดำเนินการโดยทั้งกลไกจัดการสูตรและกลไกการจัดเก็บ แม้ว่าคุณจะเพิ่งดำเนินการค้นหาเดียวกันเมื่อไม่กี่วินาทีที่แล้วก็ตาม สิ่งนี้จะนำไปสู่ความล่าช้าของประสิทธิภาพและประสบการณ์ของผู้ใช้ที่ไม่ดี

โปรดทราบว่ากลไกการจัดเก็บข้อมูลไม่ทราบว่าการสืบค้นถูกดำเนินการโดยใช้ DAX หรือ MDX ดังที่เราได้กล่าวไว้ก่อนหน้านี้ การทำงานของ Formula Engine คือการแปลงข้อความค้นหาให้เป็นภาษาที่ถูกต้องก่อนที่จะส่งต่อไปยังแผนการสืบค้นข้อมูล

สุดท้าย กลไกจัดการสูตรจะส่งการสืบค้นไปยังกลไกการจัดเก็บข้อมูลทีละรายการ ซึ่งหมายความว่าการมีหลายส่วนจะดีกว่าจริง ๆ ดังนั้นเวลาการสแกนโดยรวมภายใน Vertipaq จึงลดลงได้ด้วยการสแกนหลายส่วนพร้อมกัน

DAX สำหรับ LuckyTemplates: การเพิ่มประสิทธิภาพโดยใช้ Formula Engines ใน DAX Studio
เทคนิคการเพิ่มประสิทธิภาพการสืบค้นข้อมูล DAX และ
ประสิทธิภาพการสืบค้นบทเรียนและการตั้งค่า DAX Studio

บทสรุป

การทำความเข้าใจข้อมูลเชิงลึกของกลไกการจัดเก็บข้อมูลจะช่วยเพิ่มประสิทธิภาพการสืบค้น DAX ของคุณได้อย่างแท้จริง โดยเฉพาะอย่างยิ่งหากคุณใช้ DAX Studio หากคุณได้ดูบทแนะนำสอนการใช้งานที่อธิบายเกี่ยวกับเครื่องมือสร้างสูตร คุณจะตัดสินใจได้ดีขึ้นเกี่ยวกับวิธีสร้างข้อความค้นหาที่มีประสิทธิภาพดีขึ้น

แม้ว่าเครื่องยนต์สูตรจะทำหน้าที่เป็นเครื่องยนต์ระดับบนสุด ไม่ต้องสงสัยเลยว่ามันจะไม่สามารถทำงานได้ดีเท่าที่ควรหากเราไม่เพิ่มเครื่องยนต์ทั้งสองให้สูงสุด

สิ่งที่ดีที่สุด