מסד הנתונים של Azure SQL לעומת מסד הנתונים של Fabric SQL: הבדלי עלויות וחישוב בהסבר

By Mirko Peters · 2026-10-21

השוואה בין עלויות החישוב של Azure SQL Database ל-Fabric SQL Database, כולל שינוי קנה מידה ללא שרת, יחידות קיבולת, כלכלת האחסון והפשרות בין התכונות.

Automatically translated with AI from the original post. Read the English original

הבחירה בין Azure SQL Database ל-Fabric SQL Database תלויה בהבנה של האופן שבו הקצאת המשאבים, התנהגות השינוי בקנה המידה ויחידות הקיבולת שונים זה מזה. למרות ששני המסדים פועלים על אותו מנוע SQL חזק, האינטגרציה של Fabric עם OneLake ומודלי הקיבולת המשותפים יוצרים שיקולים ארכיטקטוניים ותקציביים מובהקים עבור ארגונים מונעי נתונים.

עיקרי הדברים

• Fabric SQL Database שואב משאבים מיחידות קיבולת משותפות של Fabric (CUs) ולא משכבות vCore עצמאיות של Azure.
• משאבי החישוב מצטמצמים לאפס ומשתחררים אוטומטית לאחר 15 דקות של חוסר פעילות, כדי לחסוך בעלויות.
• חיוב האחסון מתבצע באופן רציף מדי שעה, בעוד שאחסון הגיבויים חינמי עד לגודל מסד הנתונים הראשי.
• מירורינג מובנה ואוטומטי מבטל את הצורך בצינורות ETL ידניים, על ידי הזנת קבצי Delta Parquet ב-OneLake בזמן אמת.
• Azure SQL Database המסורתי מספק מאגרים אלסטיים ייעודיים ומשימות SQL Server Agent, שסביבות Fabric מטפלות בהם בצורה שונה.

הבנת החישוב: vCores לעומת יחידות קיבולת

בעת מעבר של עומסי עבודה או תכנון ארכיטקטורת ענן חדשה, השינוי המהותי בין Azure SQL המסורתי ל-Fabric SQL נעוץ בניהול החישוב. ב-Azure SQL Database עצמאי, מקצים vCores ייעודיים או משאבי חישוב Serverless הממופים ישירות למופע מסד הנתונים הבודד שלכם. אתם מנהלים מגבלות קנה מידה, חלונות תחזוקה ורמות ביצועים בכל מסד נתונים בנפרד.

לעומת זאת, Fabric SQL Database שואב את כוח המחשוב שלו ממאגר הקיבולת הרחב יותר של Fabric בארגון. מודל משאבים משותף זה אומר שמסד הנתונים חולק תקציב עם דוחות Power BI, צינורות Data Factory ו-Lakehouses. המרת היחידות בין Fabric Capacity Units (CUs) לבין עוצמת מסד הנתונים מתבצעת באופן דינמי מאחורי הקלעים. לדוגמה, הקצאה של 64 יחידות קיבולת שווה בערך ל-24.5 vCores עבור עומס העבודה של מסד הנתונים. גישת המאגר המאוחד הזו מונעת פיצול משאבים הנפוץ בסביבות מרובות מסדי נתונים, ומאפשרת שיתוף דינמי בין כל חלקי מרחב העבודה לניתוח נתונים.

כללי שינוי קנה מידה ללא שרת וחיוב בזמן חוסר פעילות

שתי אפשרויות מסד הנתונים משתמשות בארכיטקטורות ללא שרת שמתרחבות בזמן שאילתות שיא ומצטמצמות כשהתעבורה דועכת. עם זאת, מנגנוני החיוב בזמן חוסר פעילות חשובים במיוחד לתחזית תקציבית. Fabric SQL Database מנטר את הפעילות באופן רציף. אם מסד נתונים נשאר לא פעיל לחלוטין במשך 15 דקות, ללא שאילתות נכנסות, הוא משחרר את כל משאבי החישוב שלו, וכך עלות החישוב יורדת לאפס.

כדי למנוע השהיית התנעה קרה עבור המשתמש הבא, Microsoft מיישמת מרווח שמירה מכוון. אם מסד נתונים עובד קשה במשך שתי דקות ואז נרגע, מחויבות לשתי הדקות הפעילות בתוספת 15 דקות נוספות של חישוב בהמתנה, כלומר 17 דקות בסך הכול. האחסון, לעומת זאת, נשאר קבוע ומחויב מדי שעה, בין אם מסד הנתונים מעבד עסקאות פעיל ובין אם הוא במצב שינה.

עלויות אחסון וכלכלת הגיבויים

ניהול האחסון ב-Fabric SQL Database מציע יתרונות חיסכון משמעותיים בעלויות בהשוואה לתשתיות מסורתיות. מכיוון שהמסד מפעיל באופן אוטומטי שכפול רציף ל-OneLake, רשומות התפעול שלכם משוכפלות לקבצי Delta Parquet פתוחים. פורמט פתוח זה מבטיח שהנתונים לעולם לא ייכלאו בסילו קנייני, ומאפשר לכל כלי היודע לקרוא פורמט Delta לבצע שאילתות ישירות על העותק המשוכפל.

נוסף על כך, כלכלת הגיבויים מותאמת מאוד במערכת האקולוגית של Fabric. יכולות שחזור לנקודת זמן מאפשרות למנהלים להחזיר את השעון אחורה עד שבעה ימים כדי להתאושש משחיתות נתונים מקרית או משגיאות משתמש חמורות. אחסון הגיבויים חינמי לחלוטין עד לגודלו הכולל של מסד הנתונים הראשי. חיוב נוסף חל רק אם טביעת הרגל של אחסון הגיבויים גדלה מעבר למסד הנתונים הפעיל עצמו, וזה מספק רשת ביטחון כלכלית צפויה לשמירת נתונים לטווח ארוך.

יתרונות וחסרונות תפעוליים: מה מרוויחים ומה מפסידים

למרות שמנוע ה-SQL הליבתי זהה בשתי הפלטפורמות, בחירה ב-Fabric SQL Database במקום ב-Azure SQL Database מחייבת הערכה של פערים תכונתיים מסוימים. ידיעה מה חסר במימוש של Fabric מונעת חסמים ארכיטקטוניים בלתי צפויים במהלך הפיתוח.

תכונות ייחודיות ל-Azure SQL המסורתי

מסדי נתונים עצמאיים של Azure SQL תומכים מקורית ב-elastic pools לפי שם, ומעניקים למנהלי מסדי הנתונים שליטה מדויקת בקיבוץ המסדים. כמו כן, הם כוללים את SQL Server Agent הקלאסי, שעליו מסתמכות אפליקציות מורשת רבות לתזמון פרוצדורות מאוחסנות ומשימות תחזוקה באופן פנימי.

יתרונות מקוריים של Fabric SQL

Fabric SQL מבטל את העומס הניהולי של הקמת צינורות שכפול חיצוניים. ברגע שיוצרים את המסד, השכפול מופעל אוטומטית עבור כל הטבלאות הנתמכות, ללא צורך בהגדרת ETL ידנית. בנוסף, המערכת משתלבת באופן מקורי עם Git לניהול קוד מקור ותומכת בקונבנציית שמות בת שלושה חלקים, מה שמאפשר לצרף בקלות טבלאות תפעוליות עם Lakehouses ו-Warehouses בשאילתה אחת. לסקירה מקיפה של אופן השתלבות הרכיבים, האזינו לפרק המלא כדי לשמוע ניתוח מומחים ואסטרטגיות מעשיות לארכיטקטים מודרניים של נתונים.

שאלות נפוצות

איך מתבצע החיוב עבור Fabric SQL Database במצב סרק?

חיוב המחשוב נמשך 15 דקות לאחר שהשאילתה האחרונה מסתיימת, כדי לשמור על המסד פעיל, ולאחר מכן עלויות המחשוב יורדות לאפס. אחסון ממשיך להתחייב על בסיס שעתי ללא קשר לפעילות.

האם צריך להגדיר ידנית שכפול כדי להעביר נתונים ל-OneLake?

לא. השכפול מתחיל אוטומטית ברגע שנוצר ה-Fabric SQL Database, ומסנכרן ברציפות את הטבלאות הrelational שלכם ל-OneLake כקבצי Delta Parquet פתוחים, ללא צורך בקוד ETL מותאם אישית.

האם אפשר להשתמש ב-SQL Server Agent לתזמון משימות ב-Fabric SQL Database?

SQL Server Agent אינו זמין ב-Fabric SQL Database. במקום זאת, Microsoft ממליצה להשתמש ב-Data Factory pipelines או במשימות Apache Airflow לתזמון ולאוטומציה.

איך מחויבים הגיבויים ב-Fabric SQL?

גיבויי שחזור לנקודת זמן חינמיים לחלוטין עד לגודל האחסון הכולל של המסד הפעיל. משלמים על אחסון גיבויים רק אם טביעת הרגל של הגיבויים עולה על גודל מסד הנתונים הראשי.