پایگاه داده گراف در 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

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

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

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

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

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

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

اولین چیزی که ممکن است متوجه شوید وجود 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 خود گویا هستند. پرسشهای پایگاه داده گراف می توانند در هنگام حل یک مسئله سیستم توصیه در زمان واقعی ، از معادل رابطه ای بهتر عمل کنند.