ข้อจํากัดในฐานข้อมูลมิเรอร์ของ Microsoft Fabric จาก Snowflake

ข้อจํากัดปัจจุบันในฐานข้อมูลมิเรอร์ Microsoft Fabric จาก Snowflake แสดงอยู่ในหน้านี้ หน้านี้อาจเปลี่ยนแปลงได้

ข้อจํากัดในการเชื่อมต่อและการรับรองความถูกต้อง

• ตารางต่อไปนี้แสดงรายการวิธีการรับรองความถูกต้องที่รองรับการมิเรอร์สําหรับ Snowflake:

• ขณะนี้ข้อมูลประจําตัวของพื้นที่ทํางานไม่ได้รับการสนับสนุนสําหรับการสะท้อนเกล็ดหิมะ พร้อมใช้งานสําหรับแหล่งข้อมูลที่เลือก เช่น SharePoint

• การเชื่อมต่อ Private Link ระหว่างพื้นที่ทํางาน Fabric และ Snowflake ยังไม่พร้อมใช้งาน ใช้เกตเวย์ข้อมูลเครือข่ายเสมือนหรือเกตเวย์ข้อมูลภายในองค์กรสําหรับการเชื่อมต่อส่วนตัวในระหว่างนี้

• คุณต้องเพิ่มผู้รับการแชร์ไปยังพื้นที่ทํางาน เมื่อต้องการแชร์ชุดข้อมูลหรือรายงาน ก่อนอื่นให้เพิ่ม access ไปยังพื้นที่ทํางานด้วยบทบาทของผู้ดูแลระบบ สมาชิก ผู้อ่าน หรือผู้สนับสนุน

• การคํานึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่: ตัวระบุ Snowflake ทั้งหมด รวมถึงชื่อคลังสินค้า ชื่อฐานข้อมูล ชื่อสคีมา ชื่อตาราง และชื่อมุมมอง จะคํานึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่เมื่อกําหนดค่าการเชื่อมต่อการมิเรอร์และเมื่อใช้ REST API การมิเรอร์ ตัวพิมพ์ใหญ่ที่คุณป้อนใน Fabric ต้องตรงกับสิ่งที่กําหนดค่าไว้ใน Snowflake ทุกประการ ตัวพิมพ์ใหญ่ที่ไม่ตรงกันอาจทําให้เกิดความล้มเหลวในการเชื่อมต่อหรือตารางไม่ปรากฏขึ้นสําหรับการจําลองแบบ ซึ่งมักจะไม่มีข้อความแสดงข้อผิดพลาดที่อธิบาย ตัวอย่างเช่น ถ้าคลังสินค้า Snowflake ของคุณมีชื่อว่า ANALYTICS_WH คุณต้องป้อน ANALYTICS_WH ในการเชื่อมต่อ Fabric ไม่ใช่ analytics_wh

ชนิดวัตถุที่รองรับ

• ตารางต่อไปนี้แสดงรายการประเภทออบเจ็กต์ Snowflake ที่รองรับการมิเรอร์:

การจําลองแบบและข้อจํากัดของข้อมูล

• หากไม่มีการอัปเดตในตารางต้นทาง กลไก replicator จะเริ่มถอยหลังด้วยระยะเวลาที่เพิ่มขึ้นแบบทวีคูณสําหรับตารางนั้น สูงสุดหนึ่งชั่วโมง สิ่งเดียวกันนี้อาจเกิดขึ้นได้หากมีข้อผิดพลาดชั่วคราว ซึ่งขัดขวางการรีเฟรชข้อมูล กลไก replicator จะกลับมาสํารวจตามปกติโดยอัตโนมัติหลังจากตรวจพบข้อมูลที่อัปเดต
• ลําดับชั้น Schema ต้นทางถูกจําลองแบบไปยังฐานข้อมูลที่มิเรอร์ สําหรับฐานข้อมูลมิเรอร์ที่สร้างขึ้นก่อนเปิดใช้งานคุณลักษณะนี้ สคีมาต้นทางจะถูกลดรูปแบบ และชื่อ Schema ถูกเข้ารหัสลับเป็นชื่อตาราง ถ้าคุณต้องการจัดระเบียบตารางด้วย Schema ใหม่ ให้สร้างฐานข้อมูลแบบมิเรอร์ของคุณใหม่ เรียนรู้เพิ่มเติมจากลําดับชั้น Schema ต้นทางที่จําลองแบบ
• การทําสําเนาสนับสนุนการจําลองแบบคอลัมน์ที่มีช่องว่างหรืออักขระพิเศษในชื่อ (เช่น ,;{}()\n\t=) สําหรับตารางภายใต้การจําลองแบบก่อนเปิดใช้งานคุณลักษณะนี้ คุณจําเป็นต้องอัปเดตการตั้งค่าฐานข้อมูลแบบมิเรอร์หรือรีสตาร์ทการมิเรอร์เพื่อรวมคอลัมน์เหล่านั้น เรียนรู้เพิ่มเติมจากการสนับสนุนการแมปคอลัมน์ Delta
• จํานวนโต๊ะสูงสุดที่สามารถสะท้อนไปยัง Fabric ได้คือ 1,000 โต๊ะ ตารางใดๆ ที่สูงกว่าขีดจํากัด 1000 ไม่สามารถทําซ้ําได้ในขณะนี้
  • ถ้าคุณเลือก มิเรอร์ข้อมูลทั้งหมด เมื่อกําหนดค่ามิเรอร์ ตารางที่จะมิเรอร์จะถูกกําหนดโดยการนําตาราง 1,000 ตารางแรกเมื่อตารางทั้งหมดถูกเรียงลําดับตามตัวอักษรตามชื่อ Schema และชื่อตาราง ชุดตารางที่เหลือที่ด้านล่างของรายการตามตัวอักษรจะไม่ถูกสะท้อนทับ
  • ถ้าคุณยกเลิกการเลือก มิเรอร์ข้อมูลทั้งหมด และเลือกแต่ละตาราง คุณจะถูกป้องกันไม่ให้เลือกตารางมากกว่า 1,000 ตาราง
• คอลัมน์จากการคํานวณและตารางจากการคํานวณ: ฐานข้อมูลที่มิเรอร์เป็นแบบอ่านอย่างเดียว คุณไม่สามารถสร้างคอลัมน์จากการคํานวณหรือตารางจากการคํานวณได้โดยตรงบนฐานข้อมูลที่มิเรอร์ หากต้องการเพิ่มคอลัมน์จากการคํานวณ ให้สร้าง Lakehouse และใช้ทางลัดเพื่ออ้างอิงข้อมูลที่มิเรอร์ จากนั้นสร้างคอลัมน์จากการคํานวณของคุณใน Lakehouse โดยใช้สมุดบันทึกหรือ SQL

ข้อจํากัดด้านประสิทธิภาพ

• ถ้าคุณกําลังเปลี่ยนแปลงข้อมูลส่วนใหญ่ในตารางขนาดใหญ่ การหยุดและเริ่มการสะท้อนใหม่จะมีประสิทธิภาพมากกว่า การแทรกหรืออัปเดตระเบียนหลายพันล้านระเบียนอาจใช้เวลานาน
• การเปลี่ยนแปลง Schema บางอย่างจะไม่แสดงให้เห็นในทันที การเปลี่ยนแปลง Schema บางอย่างจําเป็นต้องมีการเปลี่ยนแปลงข้อมูล (แทรก อัปเดต หรือลบ) ก่อนที่การเปลี่ยนแปลง Schema จะถูกจําลองแบบไปยัง Fabric
• ข้อควรพิจารณาข้ามรีเจี้ยน: หากอินสแตนซ์ Snowflake และความจุ Fabric ของคุณอยู่ในรีเจี้ยนระบบคลาวด์ที่แตกต่างกัน คุณอาจพบเวลาแฝงในการจําลองแบบและค่าบริการขาออกของข้อมูลที่สูงขึ้น เพื่อประสิทธิภาพสูงสุดและเพื่อหลีกเลี่ยงค่าใช้จ่ายขาออกข้ามรีเจี้ยน ให้ปรับใช้ความจุ Fabric ของคุณในรีเจี้ยนระบบคลาวด์เดียวกันกับอินสแตนซ์ Snowflake ของคุณ หากไม่สามารถหลีกเลี่ยงการปรับใช้ข้ามภูมิภาคได้ ให้คํานึงถึงค่าธรรมเนียมขาออกเพิ่มเติมจาก Snowflake และ/หรือ Azure ดูรายละเอียดในเอกสารประกอบทางออกของ Snowflake
• เมื่อมิเรอร์ข้อมูลจาก Snowflake ไปยัง OneLake ของลูกค้า โดยปกติกระบวนการจะจัดเตรียมข้อมูลผ่าน URL แบบอินไลน์เพื่อปรับปรุงประสิทธิภาพ ถ้าพารามิเตอร์ระดับบัญชี Snowflake PREVENT_UNLOAD_TO_INLINE_URL ถูกตั้งค่าเป็นจริง ลักษณะการทํางานต่อไปนี้จะมีผลบังคับใช้:

การแก้ปัญหาที่วางแผนไว้: การสนับสนุนการรวมที่เก็บข้อมูลอยู่ระหว่างการพัฒนา และจะจัดเตรียมเส้นทางการแสดงละครทางเลือกที่ใช้งานได้เมื่อตั้งค่า PREVENT_UNLOAD_TO_INLINE_URL เป็นจริง โซลูชันนี้ปลดบล็อกสถานการณ์ VNet และ OPDG ตรวจสอบหน้านี้เพื่อดูข้อมูลอัปเดตเกี่ยวกับความพร้อมให้บริการ

• พฤติกรรมการเพาะเมล็ดใหม่: การป้อนข้อมูลใหม่คือการโหลดข้อมูลใหม่ทั้งหมดของทั้งตาราง ซึ่งแตกต่างจากการซิงค์แบบเพิ่มหน่วย (ซึ่งประมวลผลเฉพาะแถวที่เปลี่ยนแปลง) การ reseed จะอ่านซ้ําและเขียนข้อมูลทั้งหมดในตารางอีกครั้ง การเพาะเมล็ดใหม่อาจมีต้นทุนการคํานวณเกล็ดหิมะจํานวนมาก โดยเฉพาะอย่างยิ่งสําหรับโต๊ะขนาดใหญ่
  • สิ่งที่กระตุ้นให้เกิดการเพาะเมล็ดใหม่:

• แนวทางปฏิบัติที่ดีที่สุดในการหลีกเลี่ยงการเพาะเมล็ดใหม่ที่ไม่จําเป็น:
  • กําหนดเวลาการเปลี่ยนแปลง Schema นอกการมิเรอร์ที่ใช้งานอยู่ หากคุณใช้ DBT หรือเครื่องมือการจัดการ Schema อื่นๆ ให้กําหนดเวลาระหว่างกรอบเวลาการบํารุงรักษาหรือหยุดการมิเรอร์ชั่วคราวก่อนที่จะเรียกใช้การเปลี่ยนแปลง Schema
  • หลีกเลี่ยงการดัดแปลง DDL บ่อยครั้ง รวมการเปลี่ยนแปลง Schema เป็นชุดงานที่น้อยลงและใหญ่ขึ้นแทนที่จะทําการเปลี่ยนแปลงที่เพิ่มขึ้นตลอดทั้งวัน
  • ตรวจสอบการเพาะเมล็ดใหม่ที่ไม่คาดคิด บน หน้า สถานะการสะท้อน ให้ดูตารางที่แสดงลักษณะการคัดลอกเริ่มต้นซ้ําๆ หากตารางขนาดใหญ่มีการเพาะเมล็ดใหม่ทุกๆ สองสามนาที ให้ตรวจสอบการเปลี่ยนแปลง DDL อัปสตรีม
  • ระวังผลกระทบด้านต้นทุน การ reseed ของตาราง 226 ล้านแถว (~26.5 GB) ใช้เวลาในการคํานวณอย่างมาก คูณต้นทุนนี้ด้วยความถี่ของการเปลี่ยนแปลง Schema เพื่อประเมินผลกระทบด้านต้นทุน

ข้อจํากัดด้านความปลอดภัย

• Fabric ไม่ได้จําลองนโยบาย Snowflake Row-Level Security (RLS) และ Column-Level Security (CLS) คุณต้องกําหนดค่านโยบายความปลอดภัยที่เทียบเท่าใน Fabric ใหม่ด้วยตนเอง
• ต้องเพิ่มผู้รับการแชร์ลงในพื้นที่ทํางาน เมื่อต้องการแชร์ชุดข้อมูลหรือรายงาน ก่อนอื่นให้เพิ่ม access ไปยังพื้นที่ทํางานด้วยบทบาทของผู้ดูแลระบบ สมาชิก ผู้อ่าน หรือผู้สนับสนุน

ข้อควรพิจารณาเกี่ยวกับค่าใช้จ่ายและการเรียกเก็บเงิน

เพื่อลดต้นทุนการประมวลผลของ Snowflake จากการมิเรอร์ ให้พิจารณาแนวทางปฏิบัติที่ดีที่สุดต่อไปนี้:

• นําคลังสินค้าที่มีอยู่กลับมาใช้ใหม่ แทนที่จะสร้างคลังสินค้าเฉพาะสําหรับการมิเรอร์ ให้กําหนดค่าการมิเรอร์เพื่อใช้คลังสินค้าเดียวกันกับที่แอปพลิเคชันของคุณใช้อยู่แล้วเพื่ออัปเดตตารางต้นทาง วิธีนี้ช่วยหลีกเลี่ยงการปลุกคลังสินค้าโดยไม่จําเป็นและรอบการระงับอัตโนมัติ เมื่อแอปพลิเคชันของคุณอัปเดตตาราง ตัวจําลองการมิเรอร์จะรับการเปลี่ยนแปลงเกือบจะในทันทีในขณะที่คลังสินค้ายังคงทํางานอยู่ บางองค์กรอาจต้องการคลังสินค้าเฉพาะสําหรับการแยกงบประมาณ ตัวเลือกนี้เป็นการแลกเปลี่ยนระหว่างการประหยัดต้นทุนและความละเอียดของงบประมาณ
• สะท้อนเฉพาะตารางที่คุณต้องการ การมิเรอร์ฐานข้อมูลทั้งหมดอาจทําให้การใช้ Snowflake สูงโดยไม่คาดคิดและความจุของ Fabric พุ่งสูงขึ้น เริ่มต้นด้วยการเลือกเฉพาะตารางที่จําเป็นสําหรับสถานการณ์การวิเคราะห์ของคุณ คุณสามารถเพิ่มตารางในภายหลังได้ตามต้องการ
• ตรวจสอบการเพาะเมล็ดใหม่ที่ไม่คาดคิด การ reseed (การโหลดข้อมูลใหม่ทั้งหมด) จะประมวลผลทั้งตารางและก่อให้เกิดต้นทุนการประมวลผลตามสัดส่วนของขนาดตาราง การเปลี่ยนแปลงสคีมา รวมถึงการเปลี่ยนแปลงที่ทริกเกอร์โดยเครื่องมือเช่น DBT อาจทําให้เกิดการเพาะเมล็ดใหม่อย่างต่อเนื่อง ตรวจสอบหน้า สถานะการมิเรอร์ สําหรับตารางที่แสดงลักษณะการทํางานของการคัดลอกครั้งแรกซ้ําๆ และตรวจสอบส่วน การ Reseeding สําหรับทริกเกอร์และคําแนะนําในการแก้ไขปัญหา
• โปรดทราบว่าการสะท้อนจะทํางานอย่างต่อเนื่อง การสะท้อนภาพไม่สนับสนุนหน้าต่างการจัดกําหนดการหรือการจําลองแบบในขณะนี้ ตัวจําลองจะสํารวจการเปลี่ยนแปลงอย่างต่อเนื่อง ซึ่งสร้างการใช้งานการประมวลผล Snowflake อย่างต่อเนื่อง วางแผนงบประมาณ Snowflake ของคุณให้เหมาะสม

ภูมิภาคที่รองรับ

การมิเรอร์ฐานข้อมูลและการมิเรอร์แบบเปิดจะพร้อมใช้งานในภูมิภาค Microsoft Fabric ทั้งหมด สําหรับข้อมูลเพิ่มเติม ดู ความพร้อมใช้งานของภูมิภาค Fabric

เนื้อหาที่เกี่ยวข้อง

• การมิเรอร์ใน Fabric คืออะไร
• มิเรอร์เกล็ดหิมะ
• บทช่วยสอน: กําหนดค่าฐานข้อมูลมิเรอร์ Microsoft Fabric จาก Snowflake