• Products
    مطابق با جستجوی شما محصولی یافت نشد. توجه فرمایید که در جستجو ترتیب عبارات وارد شده مهم می باشد.

    پایگاه داده گراف در Sql Server - قسمت هفت: مزایای استفاده از ویژگیهای پایگاه داده گراف SQL Server

    استفاده از ویژگی های گراف SQL Server 2 مزیت دارد. و این یک معامله بزرگ است. بنابراین بیایید نگاهی به هر دو آنها بیندازیم.

    1-نحوه جستجوی پایگاه داده گراف SQL سرور ساده تر است

    بیایید از همان  گراف کوئری استفاده کنیم که پاسخ می دهد "افرادی که <food item> سفارش داده اند…":

    SELECT

    fb2.Name

    FROM Orders o1, isIncluded ii1, OrderDetails od1, includes i1, FoodBeverages fb1

    ,isIncluded ii2, OrderDetails od2, includes i2, FoodBeverages fb2

    WHERE MATCH(fb1<-(i1)-od1<-(ii1)-o1-(ii2)->od2-(i2)->fb2)

    AND fb1.FoodBeverageID = 16

    AND fb2.FoodBeverageID <> 16

    حال ، بیایید با استفاده از روش رابطه ای معمول آن را با پرس و جو مقایسه کنیم. لطفا توجه داشته باشید که من یک پایگاه داده رابطه ای با جداول مشابه ایجاد کردم و کلیدهای اصلی و خارجی اضافه کردم. گرافی را که قبلا در شکل سوم نشان دادم مشاهده کنید. در اینجا پرسش معادل آن وجود دارد:

    WITH OrderIDs AS

    (

    SELECT Orders.OrderID

    FROM Orders

    INNER JOIN OrderDetails ON Orders.OrderID = OrderDetails.OrderID

    WHERE Orders.RestaurantID=4

    AND OrderDetails.FoodBeverageID = 16

    )

    SELECT

    FoodBeverages.[Name]

    FROM Orders

    INNER JOIN OrderDetails ON Orders.OrderID = OrderDetails.OrderID

    INNER JOIN FoodBeverages ON OrderDetails.FoodBeverageID =

    FoodBeverages.FoodBeverageID

    WHERE Orders.RestaurantID=4

    AND FoodBeverages.FoodBeverageID <> 16

    AND Orders.OrderID IN (SELECT OrderID FROM OrderIDs)

    هر دو پرسش 1 رکورد را برمی گردانند که Strawberry Whirl است .

    یکی از مواردی که می توانیم از 2 برجسته کنیم این است که پرسش گراف چقدر ساده تر و کوتاه تر از روش رابطه ای است. حتی اگر به جای عبارت جدول مشترک (CTE) از زیر پرسشی استفاده کنید ، کد حاصل از پرس و جو گراف SQL طولانی تر خواهد بود.

    چرا؟

    از آنجا که پرس و جو گراف ، مشکلی را که برای پایگاه داده های گراف مناسب تر است ، حل می کند.

    اما این پایان کار نیست.

     2- عملکرد پایگاه داده گراف SQL سرور بهتر است

    همانطور که قبلاً اشاره کردم ، با یک مشکل درست ، یک پایگاه داده گراف می تواند از معادل رابطه ای بهتر عمل کند. بیایید این را امتحان کنیم

    ما از STATISTICS IO برای اندازه گیری میزان خواندن منطقی هر دو سeriesال استفاده خواهیم کرد و می بینیم که SQL Server برای پردازش این سeriesالات به چه مقدار داده نیاز دارد. هرچه عدد بزرگتر باشد ، پرس و جو کندتر است.

     

    تجزیه و تحلیل کوئری گراف SQL

    بیایید با کوئری گراف شروع کنیم:

    SELECT

    fb2.Name

    FROM Orders o1, isIncluded ii1, OrderDetails od1, includes i1, FoodBeverages fb1

    ,isIncluded ii2, OrderDetails od2, includes i2, FoodBeverages fb2

    WHERE MATCH(fb1<-(i1)-od1<-(ii1)-o1-(ii2)->od2-(i2)->fb2)

    AND fb1.FoodBeverageID = 16

    AND fb2.FoodBeverageID <> 16

    خواندن منطقی این پرسش در زیر نشان داده شده است:

    تجزیه و تحلیل کوئری گراف SQL

    در اینجا چند نکته از شکل بالا آورده شده است:

    نیاز به درخواست 12 * 8kb (96kb) از FoodBeverages ، 10 * 8kb (80kb) از جدول لبه و 8 * 8kb (64kb) از جدول حاوی حاشیه است. مجموع 240 کیلو بایت.

    به دلیل وجود WorkFile و WorkTable ، از عبارت tempdb استفاده می شود. اگر نگاهی به نقشه اجرا بیندازید ، این یک گره با مطابقت Hash دارد. این کار با مقادیر صفر در تمام معیارها کاملا خوب انجام می شود.

    در نتیجه جدول Orders و OrderDetails را مشاهده نکردیم ، اما جداول لبه آنها ظاهر شد.

    قبل از شروع به پرس و جو دوم ، بیایید برنامه اجرا را بررسی کنیم.

    تجزیه و تحلیل کوئری گراف SQL

    اولین چیزی که ممکن است متوجه شوید وجود INNER JOIN ها در بیشتر گره های برنامه اجرا است.

    چرا؟ آیا ما از یک پایگاه داده گرافیکی استفاده نمی کنیم؟

    این یک واقعیت را باید در نظر گرفت: از آنجا که SQL Server یک پایگاه داده رابطه ای با ویژگی های گراف است و نه یک پایگاه داده گراف بومی ، طبیعی است که یک پردازشگر پرس و جو داشته باشید که با یک رویکرد رابطه ای رفتار کند.

    با این حال ، سوال اصلی این است: آیا این برای عملکرد بد است؟

    نتیجه تجزیه و تحلیل ما با پرسش دوم نشان می دهد که پاسخ چیست.

    تجزیه و تحلیل کوئری های رابطه ای

    اجازه دهید دوباره کوئری دوم را ارائه دهم:

    WITH OrderIDs AS
    (
    SELECT Orders.OrderID
    FROM Orders
    INNER JOIN OrderDetails ON Orders.OrderID = OrderDetails.OrderID
    WHERE Orders.RestaurantID=4
    AND OrderDetails.FoodBeverageID = 16
    )
    SELECT
    FoodBeverages.[Name]
    FROM Orders
    INNER JOIN OrderDetails ON Orders.OrderID = OrderDetails.OrderID
    INNER JOIN FoodBeverages ON OrderDetails.FoodBeverageID =
    FoodBeverages.FoodBeverageID
    WHERE Orders.RestaurantID=4
    AND FoodBeverages.FoodBeverageID <> 16
    AND Orders.OrderID IN (SELECT OrderID FROM OrderIDs)

    و در زیر نتیجه STATISTICS IO است:

    تجزیه و تحلیل کوئری های رابطه ای

    این چه چیزی را نشان داد؟

    • FoodBeverages دارای خواندن منطقی 8 * 8 کیلوبایت (64 کیلو بایت) ، سفارش جزئیات با 15 * 8 کیلوبایت (120 کیلوبایت) و سفارشات با 34 * 8 کیلوبایت (272 کیلوگرم) است. در کل 456 کیلوبایت. این تقریباً دو برابر بیشتر از قرائت منطقی پرسش گراف است.
    • بدون استفاده از tempdb

    بنابراین ، آیا استفاده از پایگاه داده گراف ایده بدی است؟

    اعداد موجود در STATISTICS IO خود گویا هستند. پرسشهای پایگاه داده گراف می توانند در هنگام حل یک مسئله سیستم توصیه در زمان واقعی ، از معادل رابطه ای بهتر عمل کنند.

    توضیحات خود را بنویسید

    back to top
    فیلترگذاری