ڳولا جا نتيجا ۽ ڪارڪردگي جا مسئلا

سڀني ايپليڪيشنن ۾ عام منظرنامن مان هڪ آهي جنهن سان اسين واقف آهيون ڪجهه معيارن جي مطابق ڊيٽا ڳولڻ ۽ ان کي پڙهڻ لاءِ آسان فارم ۾ ڊسپلي ڪرڻ. اتي پڻ ٿي سگھي ٿو اضافي اختيارن کي ترتيب ڏيڻ، گروپ ڪرڻ، ۽ پيج ڪرڻ لاء. ڪم، نظريي ۾، ننڍڙو آهي، پر ان کي حل ڪرڻ وقت، ڪيترائي ڊولپر ڪيتريون ئي غلطيون ڪن ٿا، جيڪي بعد ۾ پيداوار جي نقصان جو سبب بڻجن ٿا. اچو ته هن مسئلي کي حل ڪرڻ لاء مختلف اختيارن تي غور ڪرڻ جي ڪوشش ڪريو ۽ سڀ کان وڌيڪ اثرائتي عمل کي چونڊڻ لاء سفارشون ٺاهي.

صفحا اختيار #1

آسان ترين اختيار جيڪو ذهن ۾ اچي ٿو اهو آهي هڪ صفحو-صفحي جي ڳولا جي نتيجن جي ڊسپلي ان جي تمام کلاسک شڪل ۾.

اچو ته چوندا آهن توهان جي ايپليڪيشن هڪ تعلقي ڊيٽابيس استعمال ڪري ٿي. انهي صورت ۾، هن فارم ۾ معلومات ظاهر ڪرڻ لاء، توهان کي ٻه SQL سوالن کي هلائڻ جي ضرورت پوندي:

• موجوده صفحي لاءِ قطارون حاصل ڪريو.
• ڳولها ڳولها جي معيار سان لاڳاپيل لائينن جو ڪل تعداد - اھو صفحا ڏيکارڻ لاءِ ضروري آھي.

اچو ته هڪ مثال طور MS SQL ڊيٽابيس ٽيسٽ استعمال ڪندي پهرين سوال کي ڏسو ساہسک ڪم 2016 سرور لاء. هن مقصد لاءِ اسان استعمال ڪنداسين Sales.SalesOrderHeader ٽيبل:

SELECT * FROM Sales.SalesOrderHeader
ORDER BY OrderDate DESC
OFFSET 0 ROWS
FETCH NEXT 50 ROWS ONLY

مٿي ڏنل سوال فهرست مان پھريون 50 آرڊر واپس ڪندو، ترتيب ڏنل شامل ٿيڻ جي تاريخ جي ترتيب سان، ٻين لفظن ۾، 50 سڀ کان تازو آرڊر.

اهو تيزيءَ سان هلندو آهي ٽيسٽ بيس تي، پر اچو ته ڏسون عملدرآمد پلان ۽ I/O شماريات:

Table 'SalesOrderHeader'. Scan count 1, logical reads 698, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

توھان حاصل ڪري سگھوٿا I/O انگ اکر ھر سوال لاءِ رن ٽائم ۾ SET STATISTICS IO ON ڪمانڊ هلائڻ سان.

جئين توھان ڏسي سگھوٿا عملدرآمد منصوبي مان، سڀ کان وڌيڪ وسيلا-گھڻي اختيار آھي ماخذ جدول جي سڀني قطارن کي ترتيب ڏيڻ لاءِ شامل ڪيل تاريخ سان. ۽ مسئلو اهو آهي ته جدول ۾ جيتريون قطارون ظاهر ٿينديون، اوترو ئي ”سخت“ ترتيب ڏيڻي پوندي. عملي طور تي، اهڙين حالتن کان بچڻ گهرجي، تنهنڪري اچو ته اضافو جي تاريخ ۾ هڪ انڊيڪس شامل ڪريو ۽ ڏسو ته وسيلن جي استعمال ۾ تبديلي آئي آهي:

Table 'SalesOrderHeader'. Scan count 1, logical reads 165, physical reads 0, read-ahead reads 5, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

ظاهر آهي ته اهو گهڻو بهتر ٿي چڪو آهي. پر ڇا سڀ مسئلا حل ٿي ويا آهن؟ اچو ته آرڊر ڳولڻ لاءِ سوال تبديل ڪريون جتي سامان جي ڪل قيمت $100 کان وڌي وڃي:

SELECT * FROM Sales.SalesOrderHeader
WHERE SubTotal > 100
ORDER BY OrderDate DESC
OFFSET 0 ROWS
FETCH NEXT 50 ROWS ONLY

Table 'SalesOrderHeader'. Scan count 1, logical reads 1081, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

اسان وٽ هڪ عجيب صورتحال آهي: سوال جو منصوبو پوئين هڪ کان وڌيڪ خراب ناهي، پر منطقي پڙهڻ جو حقيقي تعداد تقريباً ٻه ڀيرا وڏو آهي جيترو مڪمل ٽيبل اسڪين سان. هتي هڪ طريقو آهي - جيڪڏهن اسان اڳ ۾ ئي موجود انڊيڪس مان هڪ جامع انڊيڪس ٺاهيو ۽ سامان جي ڪل قيمت کي ٻئي فيلڊ جي طور تي شامل ڪيو، اسان کي ٻيهر حاصل ڪنداسين 165 منطقي پڙهڻ:

CREATE INDEX IX_SalesOrderHeader_OrderDate_SubTotal on Sales.SalesOrderHeader(OrderDate, SubTotal);

مثالن جو اهو سلسلو گهڻي وقت تائين جاري رکي سگهجي ٿو، پر مان هتي ٻه اهم خيال بيان ڪرڻ چاهيان ٿو:

• ڳولا جي سوال ۾ ڪو به نئون معيار يا ترتيب ترتيب ڏيڻ سان ڳولها جي سوال جي رفتار تي اهم اثر پئجي سگهي ٿو.
• پر جيڪڏهن اسان کي ڊيٽا جو صرف حصو ختم ڪرڻ جي ضرورت آهي، ۽ نه سڀئي نتيجا جيڪي ڳولا جي اصطلاحن سان ملن ٿا، اهڙي سوال کي بهتر ڪرڻ جا ڪيترائي طريقا آهن.

ھاڻي اچون ٿا ٻئي سوال ڏانھن جن جو ذڪر بلڪل شروع ۾ ڪيو ويو آھي - اھو اھو آھي جيڪو ڳڻيندو آھي رڪارڊن جو تعداد جيڪو ڳولھا جي معيار کي پورو ڪري ٿو. اچو ته ساڳيو مثال وٺون - آرڊر ڳولڻ لاء جيڪي $ 100 کان وڌيڪ آهن:

SELECT COUNT(1) FROM Sales.SalesOrderHeader
WHERE SubTotal > 100

مٿي ڄاڻايل جامع انڊيڪس کي ڏنو ويو، اسان حاصل ڪريون ٿا:

Table 'SalesOrderHeader'. Scan count 1, logical reads 698, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

حقيقت اها آهي ته سوال سڄي انڊيڪس ذريعي وڃي ٿو، حيرت انگيز ناهي، ڇو ته SubTotal فيلڊ پهرين پوزيشن ۾ ناهي، تنهنڪري سوال ان کي استعمال نٿو ڪري سگهي. مسئلو حل ڪيو ويو آهي هڪ ٻيو انڊيڪس شامل ڪرڻ سان SubTotal فيلڊ تي، ۽ نتيجي طور اهو صرف 48 منطقي پڙهي ٿو.

توهان مقدار جي ڳڻپ لاء درخواستن جا ڪجهه وڌيڪ مثال ڏئي سگهو ٿا، پر مضمون ساڳيو رهي ٿو: ڊيٽا جو هڪ ٽڪرو حاصل ڪرڻ ۽ مجموعي رقم ڳڻڻ ٻه بنيادي طور تي مختلف درخواستون آهن، ۽ هر هڪ کي بهتر ڪرڻ لاءِ پنهنجي اپائن جي ضرورت آهي. عام طور تي، توهان انڊيڪس جو هڪ ميلاپ ڳولڻ جي قابل نه هوندا جيڪي ٻنهي سوالن لاءِ هڪجهڙائي سان ڪم ڪن.

ان جي مطابق، هڪ اهم گهرج جيڪا واضح ٿيڻ گهرجي جڏهن اهڙي ڳولا حل کي ترقي ڪندي اهو آهي ته ڇا واقعي واقعي اهم آهي ڪاروبار لاءِ مليل شين جو ڪل تعداد ڏسڻ. اهو اڪثر ٿئي ٿو ته نه. ۽ مخصوص صفحو نمبرن جي ذريعي نيويگيشن، منهنجي خيال ۾، هڪ تمام تنگ دائري سان هڪ حل آهي، ڇاڪاڻ ته اڪثر پيجنگ منظرنامن وانگر نظر اچن ٿا "ايندڙ صفحي ڏانهن وڃو."

صفحا اختيار #2

اچو ته فرض ڪريو ته صارفين کي معلوم ڪرڻ جي باري ۾ پرواه ناهي ته شيون مليل مجموعي تعداد کي. اچو ته ڳولا واري صفحي کي آسان ڪرڻ جي ڪوشش ڪريون:

حقيقت ۾، صرف هڪ شيء جيڪا تبديل ٿي وئي آهي اها آهي ته مخصوص صفحو نمبرن تي نيويگيٽ ڪرڻ جو ڪو طريقو ناهي، ۽ هاڻي هن ٽيبل کي ڄاڻڻ جي ضرورت ناهي ته ان کي ظاهر ڪرڻ لاء ڪيترا ئي ٿي سگهن ٿا. پر سوال پيدا ٿئي ٿو - ٽيبل کي ڪيئن معلوم ٿئي ٿو ته ايندڙ صفحي لاء ڊيٽا موجود آهي (صحيح طور تي "اڳيون" لنڪ ڊسپلي ڪرڻ لاء)؟

جواب بلڪل سادو آھي: توھان ڊيٽابيس مان پڙھي سگھوٿا ھڪڙو وڌيڪ رڪارڊ جيڪو ڊسپلي لاءِ گھربل آھي، ۽ ھن ”اضافي“ رڪارڊ جي موجودگي ڏيکاريندي ته ڇا ايندڙ حصو آھي. اهو طريقو، توهان کي صرف هڪ درخواست هلائڻ جي ضرورت آهي ڊيٽا جو هڪ صفحو حاصل ڪرڻ لاء، جيڪو ڪارڪردگي کي بهتر بڻائي ٿو ۽ اهڙي ڪارڪردگي کي سپورٽ ڪرڻ آسان بڻائي ٿو. منهنجي مشق ۾، هڪ ڪيس هو جڏهن رڪارڊ جي مجموعي تعداد کي ڳڻڻ کان انڪار ڪندي 4-5 ڀيرا نتيجن جي ترسيل کي تيز ڪيو.

هن طريقي لاءِ ڪيترائي يوزر انٽرفيس آپشن آهن: ”واپس“ ۽ ”اڳتي“ ڪمانڊ، جيئن مٿي ڏنل مثال ۾، ”لوڊ وڌيڪ“ بٽڻ، جيڪو صرف ڏيکاريل نتيجن ۾ هڪ نئون حصو شامل ڪري ٿو، ”لامحدود اسڪرول“، جيڪو ڪم ڪري ٿو. "لوڊ وڌيڪ" جي اصول تي، پر ايندڙ حصو حاصل ڪرڻ لاء سگنل صارف لاء سڀني ڏيکاريل نتيجن کي آخر تائين اسڪرال ڪرڻ لاء آهي. باقي بصري حل، ڊيٽا نموني جو اصول ساڳيو رهي ٿو.

صفحا لاڳو ڪرڻ جي nuances

مٿي ڏنل سوالن جا سڀ مثال ”آفسيٽ + ڳڻپ“ جو طريقو استعمال ڪن ٿا، جڏهن سوال پاڻ بيان ڪري ٿو ته ڪهڙي ترتيب ۾ نتيجن جون قطارون ۽ ڪيتريون قطارون واپس ڪرڻ گهرجن. پهرين، اچو ته ڏسو ته هن معاملي ۾ پيراميٽر پاسنگ کي ڪيئن منظم ڪجي. عملي طور تي، مون کي ڪيترن ئي طريقن سان آيو آهي:

• درخواست ڪيل صفحي جو سيريل نمبر (pageIndex)، صفحي جي سائيز (pageSize).
• پهرين رڪارڊ جو سيريل نمبر جيڪو واپس ڪيو وڃي ٿو (startIndex)، نتيجي ۾ رڪارڊ جو وڌ ۾ وڌ تعداد (ڳڻپ).
• پهرين رڪارڊ جو تسلسل نمبر جيڪو واپس ڪيو ويندو (startIndex)، آخري رڪارڊ جو تسلسل نمبر جيڪو واپس ڪيو ويندو (endIndex).

پهرين نظر ۾ اهو لڳي سگهي ٿو ته اهو ايترو ابتدائي آهي ته ڪو به فرق ناهي. پر اهو ائين ناهي - سڀ کان وڌيڪ آسان ۽ آفاقي اختيار ٻيو آهي (startIndex، شمار). هن جا ڪيترائي سبب آهن:

• مٿي ڏنل +1 انٽري پروف ريڊنگ اپروچ لاءِ، pageIndex ۽ pageSize سان پهريون آپشن انتهائي مشڪل آهي. مثال طور، اسان هر صفحي تي 50 پوسٽون ڏيکارڻ چاهيون ٿا. مٿي ڏنل الگورتھم جي مطابق، توهان کي ضرورت کان وڌيڪ هڪ رڪارڊ پڙهڻ جي ضرورت آهي. جيڪڏهن هي "+1" سرور تي لاڳو نه ڪيو ويو آهي، اهو ظاهر ٿئي ٿو ته پهرين صفحي لاء اسان کي 1 کان 51 تائين رڪارڊ جي درخواست ڪرڻ گهرجي، ٻئي لاء - 51 کان 101، وغيره. جيڪڏهن توهان صفحي جي سائيز 51 جي وضاحت ڪريو ۽ صفحي جي انڊيڪس کي وڌايو، ته پوء ٻيو صفحو 52 کان 102 تائين، وغيره. ان جي مطابق، پهرين اختيار ۾، ايندڙ صفحي تي وڃڻ لاء هڪ بٽڻ کي صحيح طريقي سان لاڳو ڪرڻ جو واحد طريقو آهي سرور کي "اضافي" لائن جو ثبوت ڏيڻو پوندو، جيڪو هڪ تمام واضح nuance هوندو.
• ٽيون آپشن بلڪل به سمجھ ۾ نٿو اچي، ڇو ته اڪثر ڊيٽابيس ۾ سوالن کي هلائڻ لاءِ توھان کي اڃا تائين ڳڻپ پاس ڪرڻ جي ضرورت پوندي بجاءِ آخري رڪارڊ جي انڊيڪس. startIndex کي ختم ڪرڻ endIndex مان هڪ سادي رياضياتي عمل ٿي سگهي ٿو، پر اهو هتي ضرورت کان وڌيڪ آهي.

هاڻي اسان کي ”آفسيٽ + مقدار“ ذريعي پيجنگ لاڳو ڪرڻ جي نقصانن کي بيان ڪرڻ گهرجي:

• هر ايندڙ صفحي کي ٻيهر حاصل ڪرڻ پوئين صفحي جي ڀيٽ ۾ وڌيڪ مهانگو ۽ سست هوندو، ڇاڪاڻ ته ڊيٽابيس کي اڃا به ”شروع کان وٺي“ سڀني رڪارڊن مان وڃڻو پوندو ڳولا ۽ ترتيب جي معيار مطابق، ۽ پوءِ گهربل ٽڪري تي روڪيو.
• نه سڀئي DBMSs هن طريقي جي حمايت ڪري سگھن ٿا.

اتي متبادل آهن، پر اهي پڻ ناقص آهن. انهن طريقن مان پهرين کي ”ڪي سيٽ پيجنگ“ يا ”ڳولڻ جو طريقو“ چئبو آهي ۽ هن ريت آهي: هڪ حصو حاصل ڪرڻ کان پوءِ، توهان صفحي تي آخري رڪارڊ ۾ فيلڊ ويلز کي ياد ڪري سگهو ٿا، ۽ پوءِ انهن کي حاصل ڪرڻ لاءِ استعمال ڪريو. ايندڙ حصو. مثال طور، اسان ھيٺ ڏنل سوال ڪيو:

SELECT * FROM Sales.SalesOrderHeader
ORDER BY OrderDate DESC
OFFSET 0 ROWS
FETCH NEXT 50 ROWS ONLY

۽ آخري رڪارڊ ۾ اسان کي آرڊر جي تاريخ '2014-06-29' جي قيمت ملي. پوءِ ايندڙ صفحو حاصل ڪرڻ لاءِ توھان ھي ڪرڻ جي ڪوشش ڪري سگھو ٿا:

SELECT * FROM Sales.SalesOrderHeader
WHERE OrderDate < '2014-06-29'
ORDER BY OrderDate DESC
OFFSET 0 ROWS
FETCH NEXT 50 ROWS ONLY

مسئلو اهو آهي ته OrderDate هڪ غير منفرد فيلڊ آهي ۽ مٿي بيان ڪيل شرط گهڻو ڪري گهربل قطارن کي وڃائڻ جو امڪان آهي. هن سوال ۾ غير واضح شامل ڪرڻ لاء، توهان کي شرط ۾ هڪ منفرد فيلڊ شامل ڪرڻ جي ضرورت آهي (فرض ڪريو ته 75074 پهرين حصي کان پرائمري ڪي جي آخري قيمت آهي):

SELECT * FROM Sales.SalesOrderHeader
WHERE (OrderDate = '2014-06-29' AND SalesOrderID < 75074)
   OR (OrderDate < '2014-06-29')
ORDER BY OrderDate DESC, SalesOrderID DESC
OFFSET 0 ROWS
FETCH NEXT 50 ROWS ONLY

هي اختيار صحيح ڪم ڪندو، پر عام طور تي ان کي بهتر ڪرڻ ڏکيو ٿيندو ڇو ته شرط ۾ هڪ OR آپريٽر شامل آهي. جيڪڏهن پرائمري ڪيچ جي قيمت وڌي ٿي جيئن OrderDate وڌي ٿي، ته پوءِ شرط کي آسان ڪري سگهجي ٿو صرف SalesOrderID طرفان فلٽر ڇڏڻ سان. پر جيڪڏهن پرائمري ڪيئي جي قدرن ۽ فيلڊ جي وچ ۾ ڪو سخت تعلق نه آهي جنهن جي ذريعي نتيجو ترتيب ڏنو ويو آهي، اهو OR اڪثر DBMSs ۾ نه ٿو بچائي سگهجي. هڪ استثنا جنهن کان آئون واقف آهيان PostgreSQL آهي، جيڪو مڪمل طور تي ٽپل جي مقابلي کي سپورٽ ڪري ٿو، ۽ مٿين شرط کي "WHERE (OrderDate, SalesOrderID) < ('2014-06-29', 75074)" طور لکي سگهجي ٿو. انهن ٻن شعبن سان گڏ هڪ جامع ڪنجي ڏني وئي، هن طرح هڪ سوال بلڪل آسان هجڻ گهرجي.

هڪ ٻيو متبادل طريقو ڳولي سگهجي ٿو، مثال طور، ۾ ElasticSearch scroll API يا Cosmos DB - جڏهن هڪ درخواست، ڊيٽا کان علاوه، هڪ خاص سڃاڻپ ڪندڙ موٽائي ٿو جنهن سان توهان ڊيٽا جو ايندڙ حصو حاصل ڪري سگهو ٿا. جيڪڏهن هن سڃاڻپ ڪندڙ وٽ لامحدود زندگي آهي (جيئن Comsos DB ۾)، ته پوءِ هي هڪ بهترين طريقو آهي پيجنگ کي لاڳو ڪرڻ لاءِ صفحا جي وچ ۾ ترتيب وار منتقلي سان (مٿي ڏنل اختيار #2). ان جا ممڪن نقصان: اهو سڀ ڊي بي ايم ايس ۾ سهڪار نه آهي؛ نتيجي ۾ ايندڙ-چنڪ جي سڃاڻپ ڪندڙ کي شايد محدود حياتي هجي، جيڪا عام طور تي استعمال ڪندڙ جي رابطي کي لاڳو ڪرڻ لاءِ مناسب ناهي (جهڙوڪ ElasticSearch scroll API).

ڪمپليڪس فلٽرنگ

اچو ته ڪم کي وڌيڪ پيچيده ڪريون. فرض ڪريو اتي ھڪڙي گهربل آھي جنھن کي لاڳو ڪرڻ جي ضرورت آھي نام نہاد پہلو واري ڳولا، جيڪا آن لائن اسٽورن مان ھر ڪنھن کي تمام واقف آھي. مٿي ڏنل مثال آرڊر ٽيبل جي بنياد تي هن معاملي ۾ تمام مثالي نه آهن، تنهنڪري اچو ته ايڊونچر ورڪ ڊيٽابيس مان پراڊڪٽ ٽيبل ڏانهن وڃو:

Faceted ڳولا جي پويان خيال ڇا آهي؟ حقيقت اها آهي ته هر فلٽر عنصر لاء رڪارڊ جو تعداد ڏيکاريل آهي جيڪي هن معيار کي پورا ڪن ٿا ٻين سڀني ڀاڱن ۾ چونڊيل اڪائونٽ فلٽرن ۾ کڻڻ.

مثال طور، جيڪڏهن اسان هن مثال ۾ سائيڪل جي ڪيٽيگري ۽ رنگ ڪارو چونڊيو ٿا، ٽيبل صرف ڪارو سائيڪلون ڏيکاريندو، پر:

• زمرا گروپ ۾ هر معيار لاءِ، ان درجي مان پروڊڪٽس جو تعداد ڪاري رنگ ۾ ڏيکاريو ويندو.
• "رنگ" گروپ جي هر معيار لاء، هن رنگ جي سائيڪلن جو تعداد ڏيکاريو ويندو.

هتي اهڙين حالتن جي نتيجن جو هڪ مثال آهي:

جيڪڏھن توھان پڻ چيڪ ڪريو "ڪپڙي" جي درجي کي، ٽيبل پڻ ڏيکاريندو ڪارو ڪپڙا جيڪي اسٽاڪ ۾ آھن. ”رنگ“ سيڪشن ۾ ڪارا پروڊڪٽس جو تعداد به نون حالتن مطابق ٻيهر ڳڻيو ويندو، صرف ”ڪئٽيگريز“ سيڪشن ۾ ڪجھ به تبديل نه ٿيندو... اميد اٿم ته اهي مثال عام فهم واري سرچ الگورٿم کي سمجهڻ لاءِ ڪافي هوندا.

هاڻي اچو ته تصور ڪريون ته اهو ڪيئن لاڳاپي جي بنياد تي لاڳو ٿي سگهي ٿو. معيار جي هر گروهه، جهڙوڪ درجه بندي ۽ رنگ، هڪ الڳ سوال جي ضرورت پوندي:

SELECT pc.ProductCategoryID, pc.Name, COUNT(1) FROM Production.Product p
  INNER JOIN Production.ProductSubcategory ps ON p.ProductSubcategoryID = ps.ProductSubcategoryID
  INNER JOIN Production.ProductCategory pc ON ps.ProductCategoryID = pc.ProductCategoryID
WHERE p.Color = 'Black'
GROUP BY pc.ProductCategoryID, pc.Name
ORDER BY COUNT(1) DESC

SELECT Color, COUNT(1) FROM Production.Product p
  INNER JOIN Production.ProductSubcategory ps ON p.ProductSubcategoryID = ps.ProductSubcategoryID
WHERE ps.ProductCategoryID = 1 --Bikes
GROUP BY Color
ORDER BY COUNT(1) DESC

هن حل سان ڇا غلط آهي؟ اهو تمام سادو آهي - اهو سٺو ماپ نٿو ڪري. هر فلٽر سيڪشن کي مقدار کي ڳڻڻ لاءِ الڳ سوال جي ضرورت آهي، ۽ اهي سوال تمام آسان نه آهن. آن لائين اسٽورن ۾، ڪجھ ڪيٽيگريز ۾ ڪيترائي درجن فلٽر سيڪشن آھن، جيڪي ھڪ سنگين ڪارڪردگي جو مسئلو ٿي سگھن ٿا.

عام طور تي انهن بيانن کان پوء مون کي ڪجهه حل پيش ڪيا ويا آهن، يعني:

• ھڪڙي سوال ۾ سڀني مقدار جي ڳڻپ کي گڏ ڪريو. ٽيڪنيڪل طور تي اهو ممڪن آهي UNION لفظ استعمال ڪندي، پر اهو ڪارڪردگيءَ ۾ وڌيڪ مدد نه ڪندو - ڊيٽابيس کي اڃا تائين هر هڪ ٽڪري کي شروع کان ئي عمل ڪرڻو پوندو.
• ڪيش مقدار. اهو مون کي تجويز ڪيو ويو آهي تقريبا هر وقت جڏهن آئون هڪ مسئلو بيان ڪريان ٿو. احتياط اهو آهي ته اهو عام طور تي ناممڪن آهي. اچو ته چئو ته اسان وٽ 10 "facets" آهن، جن مان هر هڪ 5 قدر آهن. اها هڪ تمام ”معمولي“ صورتحال آهي ان جي مقابلي ۾ جيڪا ساڳي آن لائين اسٽورن ۾ ڏسي سگهجي ٿي. ھڪڙي عنصر جو انتخاب 9 ٻين ۾ مقدار کي متاثر ڪري ٿو، ٻين لفظن ۾، معيار جي ھر ھڪڙي ميلاپ لاء مقدار مختلف ٿي سگھي ٿو. اسان جي مثال ۾، ڪل 50 معيار آھن جيڪي صارف چونڊي سگھن ٿا؛ تنھنڪري، اتي 250 ممڪن مجموعا ھوندا. ڊيٽا جي اھڙي صف کي ڀرڻ لاءِ ڪافي ياداشت يا وقت نه آھي. هتي توهان اعتراض ڪري سگهو ٿا ۽ چئي سگهو ٿا ته سڀئي مجموعا حقيقي نه آهن ۽ صارف گهٽ ۾ گهٽ 5-10 معيار کان وڌيڪ چونڊيندو آهي. ها، اهو ممڪن آهي ته سستي لوڊشيڊنگ ۽ ڪيش ڪيل مقدار جي مقدار کي جيڪو ڪڏهن چونڊيو ويو آهي، پر اتي وڌيڪ چونڊون هونديون، اهڙي ڪيش گهٽ موثر هوندي ۽ جوابي وقت جا مسئلا وڌيڪ قابل ذڪر هوندا (خاص طور تي جيڪڏهن ڊيٽا سيٽ باقاعده تبديليون).

خوشقسمتيءَ سان، اهڙي مسئلي ۾ ڪافي وقت تائين ڪافي اثرائتو حل موجود آهن جيڪي ڊيٽا جي وڏي مقدار تي اڳڪٿي طور ڪم ڪن ٿا. انهن مان ڪنهن به آپشن لاءِ، اهو سمجهه ۾ اچي ٿو ته پاسن جي ٻيهر ڳڻپ کي ورهايو وڃي ۽ نتيجن واري صفحي کي سرور ڏانهن ٻن متوازي ڪالن ۾ ورهايو وڃي ۽ يوزر انٽرفيس کي اهڙي طرح منظم ڪيو وڃي ته فيٽس ذريعي ڊيٽا کي لوڊ ڪرڻ ”مداخلت نٿو ڪري“ جي ڊسپلي سان. ڳولا جا نتيجا.

• جيتري قدر ممڪن طور تي "پنهنجي" جي مڪمل ٻيهر ڳڻپ کي ڪال ڪريو. مثال طور، هر دفعي ڳولا جي معيار کي تبديل ڪرڻ تي هر شيء کي ٻيهر نه ڪريو، پر ان جي بدران نتيجن جو مجموعي تعداد ڳولهيو جيڪي موجوده حالتن سان ملن ٿا ۽ صارف کي انهن کي ڏيکارڻ لاء ترغيب ڏين ٿا - "1425 رڪارڊ مليا، ڏيکاريو؟" استعمال ڪندڙ يا ته ڳولا جي اصطلاحن کي تبديل ڪرڻ جاري رکي سگهي ٿو يا "ڏسو" بٽڻ تي ڪلڪ ڪريو. صرف ٻئي صورت ۾ نتيجا حاصل ڪرڻ لاءِ سڀني درخواستن تي عمل ڪيو ويندو ۽ مقدار کي ٻيهر ڳڻڻ جي سڀني ”پنهنجن“ تي عمل ڪيو ويندو. انهي صورت ۾، جيئن توهان آساني سان ڏسي سگهو ٿا، توهان کي نتيجن جي مجموعي تعداد ۽ ان جي اصلاح کي حاصل ڪرڻ لاء هڪ درخواست سان معاملو ڪرڻو پوندو. اهو طريقو ڪيترن ئي ننڍن آن لائين اسٽورن ۾ ڳولي سگهجي ٿو. ظاهر آهي، هي هن مسئلي لاء هڪ علاج نه آهي، پر عام حالتن ۾ اهو هڪ سٺو سمجھوتو ٿي سگهي ٿو.
• سرچ انجڻ استعمال ڪريو نتيجن کي ڳولهڻ لاءِ ۽ ڳڻپ جا حصا، جهڙوڪ سولر، ايلسٽڪ سرچ، اسفنڪس ۽ ٻيا. اهي سڀئي ٺهيل آهن "پنهنجو" ٺاهڻ لاءِ ۽ اهو ڪم ڪارائتو طريقي سان انڊيڪس انڊيڪس جي ڪري. سرچ انجڻون ڪيئن ڪم ڪن ٿيون، ڇو ته اهڙين حالتن ۾ اهي عام مقصدن جي ڊيٽابيس کان وڌيڪ اثرائتو آهن، ڪهڙا طريقا ۽ نقصان آهن - هي هڪ الڳ مضمون جو موضوع آهي. هتي مان توهان جو ڌيان ان حقيقت ڏانهن ڇڪائڻ چاهيان ٿو ته سرچ انجڻ مکيه ڊيٽا اسٽوريج لاءِ متبادل نه ٿي سگهي؛ اهو اضافي طور استعمال ڪيو ويندو آهي: مکيه ڊيٽابيس ۾ جيڪي به تبديليون آهن جيڪي ڳولا لاءِ لاڳاپيل آهن، انهن کي سرچ انڊيڪس ۾ هم وقت ڪيو ويندو آهي. سرچ انجڻ عام طور تي صرف سرچ انجڻ سان رابطو ڪري ٿو ۽ مکيه ڊيٽابيس تائين رسائي نٿو ڪري. هتي جي سڀ کان اهم نقطي مان هڪ آهي ته هن هم وقت سازي کي منظم طريقي سان ڪيئن ڪجي. اهو سڀ ڪجهه "رد عمل جي وقت" جي ضرورتن تي منحصر آهي. جيڪڏهن مکيه ڊيٽابيس ۾ تبديلي ۽ ڳولا ۾ ان جي "ظاهر" جي وچ ۾ وقت نازڪ نه آهي، توهان هڪ خدمت ٺاهي سگهو ٿا جيڪو تازو تبديل ٿيل رڪارڊ هر چند منٽن جي ڳولا ڪري ٿو ۽ انهن کي ترتيب ڏئي ٿو. جيڪڏھن توھان چاھيو ٿا گھٽ ۾ گھٽ جوابي وقت، توھان ڪجھ لاڳو ڪري سگھو ٿا جھڙوڪ ٽرانزيڪشن آئوٽ باڪس ڳولا سروس ڏانهن تازه ڪاري موڪلڻ لاء.

پهچڻ

1. سرور-سائڊ پيجنگ کي لاڳو ڪرڻ هڪ اهم پيچيدگي آهي ۽ صرف تيز وڌندڙ يا صرف وڏي ڊيٽا سيٽن لاءِ سمجهه ۾ اچي ٿي. ”وڏي“ يا ”تيزي سان وڌندڙ“ جو اندازو ڪيئن ڪجي، ان لاءِ ڪو بلڪل صحيح طريقو ناهي، پر مان هن طريقي جي پيروي ڪندس:
   • جيڪڏهن ڊيٽا جو مڪمل مجموعو حاصل ڪرڻ، اڪائونٽ سرور جي وقت ۽ نيٽ ورڪ ٽرانسميشن کي مدنظر رکندي، ڪارڪردگي جي گهرج کي عام طور تي پورو ڪري ٿو، سرور جي پاسي تي پيجنگ لاڳو ڪرڻ ۾ ڪو به مقصد ناهي.
   • ٿي سگهي ٿو هڪ اهڙي صورتحال هجي جتي ويجهي مستقبل ۾ ڪارڪردگي جي مسئلن جي توقع نه آهي، ڇاڪاڻ ته اتي ٿورڙي ڊيٽا آهي، پر ڊيٽا گڏ ڪرڻ ۾ مسلسل واڌارو آهي. جيڪڏهن مستقبل ۾ ڊيٽا جو ڪجهه سيٽ اڳئين نقطي کي پورو نٿو ڪري سگهي، اهو بهتر آهي ته فوري طور تي پيج ڪرڻ شروع ڪيو وڃي.
2. جيڪڏهن ڪاروبار جي طرف کان نتيجن جي مجموعي تعداد کي ظاهر ڪرڻ يا صفحي نمبرن کي ظاهر ڪرڻ جي ڪا سخت ضرورت ناهي، ۽ توهان جي سسٽم ۾ سرچ انجڻ نه آهي، اهو بهتر آهي ته انهن نقطن تي عمل نه ڪيو وڃي ۽ اختيار #2 تي غور ڪيو وڃي.
3. جيڪڏهن گهربل ڳولا لاء واضح گهربل آهي، توهان وٽ ڪارڪردگي جي قرباني کان سواء ٻه اختيار آهن:
   • هر دفعي ڳولا جا معيار تبديل ٿيڻ تي سڀني مقدارن کي ٻيهر نه ڳڻيو.
   • سرچ انجڻ استعمال ڪريو جهڙوڪ سولر، ايلسٽڪ سرچ، اسفنڪس ۽ ٻيا. پر اهو سمجهڻ گهرجي ته اهو مکيه ڊيٽابيس جي متبادل نه ٿي سگهي، ۽ ڳولا جي مسئلن کي حل ڪرڻ لاء مکيه اسٽوريج جي اضافي طور استعمال ڪيو وڃي.
4. انهي سان گڏ، فڪري ڳولها جي صورت ۾، ڳولا جي نتيجن واري صفحي جي ٻيهر حاصل ڪرڻ ۽ ڳڻپ کي ٻن متوازي درخواستن ۾ ورهائڻ جو احساس آهي. ڳڻپ جي مقدار نتيجا حاصل ڪرڻ کان وڌيڪ وقت وٺي سگھي ٿي، جڏهن ته نتيجا صارف لاءِ وڌيڪ اھم آھن.
5. جيڪڏھن توھان ڳولھا لاءِ SQL ڊيٽابيس استعمال ڪري رھيا آھيو، ھن حصي سان لاڳاپيل ڪنھن به ڪوڊ تبديليءَ کي چڱيءَ طرح جانچيو وڃي ته ڪارڪردگيءَ لاءِ ڊيٽا جي مناسب مقدار تي (لائيو ڊيٽابيس ۾ حجم کان وڌيڪ). اهو پڻ مشورو ڏنو ويو آهي ته سوالن جي عمل جي وقت جي نگراني کي ڊيٽابيس جي سڀني مثالن تي، ۽ خاص طور تي "لائيو" تي. جيتوڻيڪ ترقي جي مرحلي تي سوالن جي منصوبن سان سڀ ڪجهه ٺيڪ هو، جيئن ڊيٽا جو حجم وڌي ٿو، صورتحال شايد خاص طور تي تبديل ٿي سگهي ٿي.

جو ذريعو: www.habr.com