PostgreSQL سوالن جي بلڪ اصلاح. ڪريل بوروفوف (ٽينسر)

رپورٽ پيش ڪري ٿو ڪجھ طريقا جيڪي اجازت ڏين ٿا SQL سوالن جي ڪارڪردگي کي مانيٽر ڪريو جڏهن اهي هر روز لکين آهن، ۽ سوين مانيٽر ٿيل PostgreSQL سرور آهن.

ڪهڙا ٽيڪنيڪل حل اسان کي معلومات جي اهڙي مقدار کي موثر طريقي سان پروسيس ڪرڻ جي اجازت ڏين ٿا، ۽ اهو ڪيئن هڪ عام ڊولپر جي زندگي کي آسان بڻائي ٿو؟

ڪير دلچسپي رکي ٿو؟ مخصوص مسئلن جو تجزيو ۽ مختلف اصلاح جي ٽيڪنالاجي SQL سوالن ۽ حل ڪرڻ عام DBA مسئلا PostgreSQL ۾ - توھان پڻ ڪري سگھو ٿا مضمونن جو هڪ سلسلو پڙهو هن موضوع تي.


منهنجو نالو Kirill Borovikov آهي، مان نمائندگي ڪريان ٿو ٽينسر ڪمپني. خاص طور تي، مان اسان جي ڪمپني ۾ ڊيٽابيس سان ڪم ڪرڻ ۾ ماهر آهيان.

اڄ مان توهان کي ٻڌايان ٿو ته اسان سوالن کي ڪيئن بهتر بڻائي سگهون ٿا، جڏهن توهان کي هڪ سوال جي ڪارڪردگي کي "الڳ ڌار" ڪرڻ جي ضرورت ناهي، پر مسئلي کي حل ڪريو. جڏهن لکين درخواستون آهن، ۽ توهان کي ڪجهه ڳولڻ جي ضرورت آهي حل لاء طريقا هي وڏو مسئلو.

عام طور تي، اسان جي گراهڪن جي هڪ ملين لاء Tensor آهي VLSI اسان جي درخواست آهي: ڪارپوريٽ سوشل نيٽ ورڪ، وڊيو ڪميونيڪيشن جا حل، اندروني ۽ بيروني دستاويزن جي وهڪري لاءِ، اڪائونٽنگ سسٽم لاءِ اڪائونٽنگ ۽ گودام،... يعني هڪ اهڙي ”ميگا ڪمبين“ لاءِ مربوط ڪاروباري انتظام، جنهن ۾ 100 کان وڌيڪ مختلف اندروني منصوبا آهن. .

انهي کي يقيني بڻائڻ لاءِ ته اهي سڀئي ڪم ڪن ٿا ۽ عام طور تي ترقي ڪن ٿا، اسان وٽ سڄي ملڪ ۾ 10 ترقياتي مرڪز آهن، جن ۾ وڌيڪ آهن 1000 ڊولپرز.

اسان 2008 کان PostgreSQL سان ڪم ڪري رهيا آهيون ۽ اسان جيڪو پروسيس ڪريون ٿا ان جو هڪ وڏو مقدار جمع ڪيو آهي - ڪلائنٽ ڊيٽا، شمارياتي، تجزياتي، ڊيٽا خارجي معلومات سسٽم مان. 400TB کان وڌيڪ. صرف پيداوار ۾ اٽڪل 250 سرور آهن، ۽ مجموعي طور تي اٽڪل 1000 ڊيٽابيس سرورز آهن جن کي اسين مانيٽر ڪندا آهيون.

SQL هڪ بياني ٻولي آهي. توهان بيان نه ڪيو ته "ڪيئن" ڪجهه ڪم ڪرڻ گهرجي، پر "ڇا" توهان حاصل ڪرڻ چاهيو ٿا. DBMS بهتر ڄاڻي ٿو ته ڪيئن جوڙيو وڃي - توهان جي جدولن کي ڪيئن ڳنڍجي، ڪهڙيون شرطون لاڳو ڪيون وڃن، ڇا انڊيڪس مان گذرندو، ڇا نه ٿيندو...

ڪجهه DBMSs اشارو قبول ڪن ٿا: "نه، انهن ٻن ٽيبلن کي اهڙي ۽ اهڙي قطار ۾ ڳنڍيو،" پر PostgreSQL اهو نٿو ڪري سگهي. هي آهي معروف ڊولپرز جي باشعور پوزيشن: "اسان ڊولپرز کي ڪجهه قسم جا اشارا استعمال ڪرڻ جي اجازت ڏيڻ بجاءِ پڇا ڳاڇا اصلاحي کي ختم ڪرڻ چاهيندا."

پر، ان حقيقت جي باوجود ته PostgreSQL ”ٻاهر“ کي پاڻ تي ڪنٽرول ڪرڻ جي اجازت نٿو ڏئي، اهو مڪمل طور تي اجازت ڏئي ٿو ڏسو ته هن جي اندر ڇا ٿي رهيو آهيجڏهن توهان پنهنجي سوال کي هلائيندا آهيو، ۽ ڪٿي اهو مسئلو آهي.

عام طور تي، هڪ ڊولپر [ڊي بي اي ڏانهن] عام طور تي ڪهڙو ڪلاسيڪل مسئلا اچي ٿو؟ ”هتي اسان درخواست پوري ڪئي، ۽ اسان سان هر شي سست آهي، سڀ ڪجهه لٽڪيل آهي، ڪجهه ٿي رهيو آهي ... ڪجهه قسم جي مصيبت!

سبب تقريبن هميشه ساڳيا آهن:

• غير موثر سوال الگورٿم
  ڊولپر: ”هاڻي مان هن کي SQL ۾ 10 ٽيبلون ڏئي رهيو آهيان JOIN ذريعي...“ - ۽ اميد رکي ٿو ته هن جون حالتون معجزاتي طور تي اثرائتو ٿي وينديون آهن ”انٽيل“ ۽ هو جلدي سڀ ڪجهه حاصل ڪري وٺندو. پر معجزا نه ٿا ٿين، ۽ اهڙي تبديليءَ سان ڪو به نظام (10 جدولن مان هڪ ۾) هميشه ڪنهن نه ڪنهن قسم جي غلطي ڏئي ٿو. [هڪ مضمون]
• غير لاڳاپيل انگ اکر
  اهو نقطو خاص طور تي PostgreSQL لاءِ تمام لاڳاپيل آهي، جڏهن توهان سرور تي هڪ وڏو ڊيٽا سيٽ “ڊايو”، هڪ درخواست ڪريو، ۽ اهو توهان جي ٽيبليٽ کي ”جنسي طور“ بڻائي ٿو. ڇاڪاڻ ته ڪالهه ان ۾ 10 رڪارڊ هئا، ۽ اڄ 10 ملين آهن، پر PostgreSQL اڃا تائين ان بابت ڄاڻ ناهي، ۽ اسان کي ان بابت ٻڌائڻ جي ضرورت آهي. [هڪ مضمون]
• "پلگ" وسيلن تي
  توهان هڪ ڪمزور سرور تي هڪ وڏو ۽ وڏي لوڊ ٿيل ڊيٽابيس نصب ڪيو آهي جنهن ۾ ڪافي ڊسڪ، ميموري، يا پروسيسر ڪارڪردگي نه آهي. ۽ اهو سڀ ڪجهه آهي... ڪٿي ڪٿي هڪ ڪارڪردگي جي ڇت آهي جنهن جي مٿان توهان اڳتي نه ٿا سگهو.
• بلاڪ ڪرڻ
  هي هڪ مشڪل نقطو آهي، پر اهي مختلف تبديلين جي سوالن لاءِ تمام گهڻي لاڳاپيل آهن (انسرٽ، تازه ڪاري، حذف ڪريو) - هي هڪ الڳ وڏو موضوع آهي.

منصوبو حاصل ڪرڻ

... ۽ هر شي لاء اسان هڪ منصوبي جي ضرورت آهي! اسان کي ڏسڻ جي ضرورت آهي ته سرور اندر ڇا ٿي رهيو آهي.

PostgreSQL لاءِ پڇا ڳاڇا ڪرڻ وارو منصوبو متن جي نمائندگي ۾ سوال جي عمل جي الگورتھم جو ھڪڙو وڻ آھي. اهو خاص طور تي الورورٿم آهي، جيڪو پلانر پاران ڪيل تجزيو جي نتيجي ۾، سڀ کان وڌيڪ اثرائتو ثابت ٿيو.

هر وڻ جو نوڊ هڪ آپريشن آهي: ٽيبل يا انڊيڪس مان ڊيٽا واپس وٺڻ، بٽ ميپ ٺاهڻ، ٻن جدولن ۾ شامل ٿيڻ، شامل ڪرڻ، ٽڪرائڻ، يا چونڊ کان ڌار ڪرڻ. هڪ سوال تي عمل ڪرڻ هن وڻ جي نوڊس ذريعي هلڻ شامل آهي.

سوال جو منصوبو حاصل ڪرڻ لاء، آسان طريقو بيان تي عمل ڪرڻ آھي EXPLAIN. سڀني حقيقي خاصيتن سان حاصل ڪرڻ لاء، اهو آهي، اصل ۾ بنيادي طور تي هڪ سوال تي عمل ڪرڻ لاء - EXPLAIN (ANALYZE, BUFFERS) SELECT ....

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

انهي کي سمجهڻ لاءِ ته واقعي ڇا ٿيو ان وقت جڏهن درخواست سرور تي عمل ۾ آئي ، هوشيار ماڻهن لکيو auto_explain module. اهو موجود آهي لڳ ڀڳ تمام عام PostgreSQL تقسيم ۾، ۽ صرف چالو ڪري سگهجي ٿو config فائل ۾.

جيڪڏهن اهو محسوس ٿئي ٿو ته ڪجهه درخواست ان حد کان وڌيڪ هلي رهي آهي جيڪا توهان ان کي ٻڌايو، اهو ڪري ٿو هن درخواست جي منصوبي جو "سنيپ شاٽ" ۽ انهن کي لاگ ۾ گڏ ڪري ٿو.

ھاڻي سڀ ڪجھ ٺيڪ ٿي پيو آھي، اسان لاگ ڏانھن وڃون ٿا ۽ اتي ڏسون ٿا... [text footcloth]. پر اسان ان بابت ڪجهه به نٿا چئي سگهون، حقيقت کان سواءِ ته اهو هڪ بهترين منصوبو آهي ڇاڪاڻ ته ان تي عمل ڪرڻ ۾ 11ms لڳي ويا.

سڀ ڪجھ ٺيڪ لڳي ٿو - پر ڪجھ به واضح ناهي ته اصل ۾ ڇا ٿيو. عام وقت کان سواء، اسان واقعي ڪجھ به نه ٿا ڏسو. ڇو ته سادي متن جي اهڙي "ليمب" کي ڏسڻ عام طور تي بصري نه آهي.

پر جيتوڻيڪ اهو واضح ناهي، جيتوڻيڪ اهو مشڪل آهي، اتي وڌيڪ بنيادي مسئلا آهن:

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

اهڙين حالتن ۾، سمجھو ته "ڪير آهي ڪمزور ڪڙي؟" لڳ ڀڳ ناممڪن. تنهن ڪري، جيتوڻيڪ ڊولپر پاڻ کي "دستي" ۾ لکندا آهن "هڪ منصوبي کي سمجهڻ هڪ فن آهي جيڪو سکڻ گهرجي، تجربو ...".

پر اسان وٽ 1000 ڊولپرز آهن، ۽ توهان انهن مان هر هڪ کي اهو تجربو نه ٿا پهچائي سگهو. مان، تون، هن کي خبر آهي، پر اتي ڪنهن کي به خبر ناهي. ٿي سگهي ٿو هو سکندو، يا ٿي سگهي ٿو نه، پر هن کي هاڻي ڪم ڪرڻ جي ضرورت آهي - ۽ هن کي اهو تجربو ڪٿان حاصل ٿيندو؟

منصوبا بصري

تنهن ڪري، اسان محسوس ڪيو ته انهن مسئلن کي منهن ڏيڻ لاء، اسان کي ضرورت آهي منصوبي جي سٺي نموني. [آرٽيڪل]

اسان پهريون ڀيرو "مارڪيٽ ذريعي" ويا - اچو ته انٽرنيٽ تي ڏسو ته ڇا موجود آهي.

پر اهو ظاهر ٿيو ته تمام ٿورا نسبتاً ”رهندڙ“ حل آهن جيڪي گهٽ يا وڌ ترقي ڪري رهيا آهن - لفظي طور تي، صرف هڪ: وضاحت.depesz.com Hubert Lubaczewski طرفان. جڏهن توهان "فيڊ" فيلڊ ۾ داخل ڪريو ٿا هڪ متن جي منصوبي جي نمائندگي، اهو توهان کي ڏيکاري ٿو هڪ جدول جنهن ۾ تجزياتي ڊيٽا سان:

• نوڊ جي پنهنجي پروسيسنگ وقت
• پوري ذيلي وڻ لاءِ ڪل وقت
• رڪارڊ جو تعداد جيڪي حاصل ڪيا ويا جيڪي شمارياتي طور تي متوقع هئا
• نوڊ جسم پاڻ

هي خدمت پڻ لنڪ جي آرڪائيو کي حصيداري ڪرڻ جي صلاحيت رکي ٿي. توهان پنهنجو منصوبو اتي اڇلايو ۽ چيو: "اي، واسيا، هتي هڪ لنڪ آهي، اتي ڪجهه غلط آهي."

پر اتي پڻ ننڍا مسئلا آهن.

پهرين، هڪ وڏي رقم "ڪاپي پيسٽ". توهان لاگ جو هڪ ٽڪرو وٺو، ان کي اتي لٺ، ۽ ٻيهر، ۽ ٻيهر.

ٻيو، پڙهڻ واري ڊيٽا جي مقدار جو ڪوبه تجزيو ناهي - ساڳيا بفر جيڪي ٻاھر نڪرندا آھن EXPLAIN (ANALYZE, BUFFERS)، اسان ان کي هتي نه ٿا ڏسو. هو صرف اهو نه ٿو ڄاڻي ته انهن کي ڪيئن ڌار ڪرڻ، انهن کي سمجهڻ ۽ انهن سان ڪم ڪرڻ. جڏهن توهان تمام گهڻو ڊيٽا پڙهي رهيا آهيو ۽ محسوس ڪيو ته توهان شايد ڊسڪ ۽ ميموري ڪيش کي غلط طور تي مختص ڪري رهيا آهيو، اها معلومات تمام ضروري آهي.

ٽيون منفي نقطو هن منصوبي جي تمام ڪمزور ترقي آهي. ڪمنٽس تمام ننڍا آهن، اهو سٺو آهي جيڪڏهن هر ڇهن مهينن ۾ هڪ ڀيرو، ۽ ڪوڊ پرل ۾ آهي.

پر هي سڀ ”غزل“ آهي، اسان ڪنهن نه ڪنهن طرح ان سان گڏ رهي سگهون ٿا، پر هڪ شيءِ آهي جنهن اسان کي هن خدمت کان گهڻو پري ڪري ڇڏيو آهي. اهي غلطيون آهن تجزيي ۾ عام ٽيبل ايڪسپريس (CTE) ۽ مختلف متحرڪ نوڊس جهڙوڪ InitPlan/SubPlan.

جيڪڏهن توهان هن تصوير تي يقين رکون ٿا، ته پوء هر فرد جي نوڊ جي مجموعي عمل واري وقت پوري درخواست جي مجموعي عمل جي وقت کان وڌيڪ آهي. اهو سادو آهي - هن CTE جي نسل جو وقت CTE اسڪين نوڊ مان نه ڪڍيو ويو. تنهن ڪري، اسان هاڻي صحيح جواب نٿا ڄاڻون ته CTE اسڪين ڪيترو وقت ورتو.

پوءِ اسان محسوس ڪيو ته اهو وقت اسان جي پنهنجي لکڻ جو آهي - هري! هر ڊولپر چوي ٿو: "هاڻي اسان پنهنجو پاڻ لکنداسين، اهو تمام آسان ٿيندو!"

اسان ويب سروسز لاءِ عام اسٽيڪ ورتو: Node.js + Express تي ٻڌل هڪ بنيادي، خوبصورت ڊاگرامس لاءِ Bootstrap ۽ D3.js استعمال ڪيو ويو. ۽ اسان جون اميدون مڪمل طور تي صحيح ثابت ٿيون - اسان 2 هفتن ۾ پهريون پروٽوٽائپ حاصل ڪيو:

• حسب ضرورت منصوبه بندي
  اهو آهي، هاڻي اسان ڪنهن به منصوبي کي پارس ڪري سگهون ٿا انهن مان ٺاهيل پوسٽ گري ايس ايس ايل.
• متحرڪ نوڊس جو صحيح تجزيو - CTE اسڪين، InitPlan، SubPlan
• بفر جي ورڇ جو تجزيو - جتي ڊيٽا جا صفحا ميموري مان پڙهيا ويندا آهن، ڪٿي مقامي ڪيش مان، ڪٿي ڊسڪ مان
• وضاحت حاصل ڪئي
  جيئن ته لاگ ان ۾ اهو سڀ ڪجهه "کڻ" نه آهي، پر تصوير ۾ "ضعيف ترين لنڪ" کي ڏسڻ لاء.

اسان کي ڪجهه هن طرح مليو، نحو نمايان ڪرڻ سان گڏ. پر عام طور تي اسان جا ڊولپر هاڻي ڪم نه ڪندا آهن منصوبي جي مڪمل نمائندگي سان، پر هڪ ننڍڙي سان. آخرڪار، اسان اڳ ۾ ئي سڀني نمبرن کي پارس ڪيو آهي ۽ انهن کي کاٻي ۽ ساڄي اڇلائي ڇڏيو آهي، ۽ وچ ۾ اسان صرف پهرين لائين ڇڏيا آهن، اهو ڪهڙي قسم جو نوڊ آهي: CTE اسڪين، CTE نسل يا Seq Scan ڪجهه نشانين جي مطابق.

هي مختصر نمائندگي آهي جنهن کي اسين سڏين ٿا منصوبي جو نمونو.

ٻيو ڇا آسان ٿيندو؟ اهو ڏسڻ ۾ آسان ٿيندو ته اسان جي ڪل وقت جو ڪهڙو حصو مختص ڪيو ويو آهي ڪهڙي نوڊ ڏانهن - ۽ صرف "ان کي لٺ" پاسي ڏانهن پائي چارٽ.

اسان نوڊ ڏانهن اشارو ڪيو ۽ ڏسو - اهو ظاهر ٿئي ٿو ته سيق اسڪين ڪل وقت جي چوٿين کان به گهٽ وقت ورتو، ۽ باقي 3/4 CTE اسڪين ذريعي ورتو ويو. وحشتيني! هي CTE اسڪين جي ”باهه جي شرح“ بابت هڪ ننڍڙو نوٽ آهي جيڪڏهن توهان انهن کي پنهنجي سوالن ۾ فعال طور تي استعمال ڪندا آهيو. اهي تمام تيز نه آهن - اهي باقاعده ٽيبل اسڪيننگ کان به گهٽ آهن. [آرٽيڪل] [آرٽيڪل]

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

قدرتي طور، اتي ڪجهه "ريڪ" شامل هئا.

پهرين شيء جيڪا اسان جي وچ ۾ آئي، گولنگ جو مسئلو هو. منصوبي ۾ هر انفرادي نوڊ جو وقت 1 μs جي درستگي سان ظاهر ڪيو ويو آهي. ۽ جڏهن نوڊ سائيڪلن جو تعداد وڌي وڃي ٿو، مثال طور، 1000 - عمل ڪرڻ کان پوءِ PostgreSQL ورهايو ويو “درستگي جي اندر”، پوءِ جڏهن واپس ڳڻپ ڪريون ٿا ته اسان کي ڪل وقت ملي ٿو “ڪٿي 0.95ms ۽ 1.05ms جي وچ ۾”. جڏهن ڳڻپ مائڪرو سيڪنڊن ڏانهن وڃي ٿي، اهو ٺيڪ آهي، پر جڏهن اهو اڳ ۾ ئي [ملي] سيڪنڊن جو آهي، توهان کي هن معلومات کي اڪائونٽ ۾ رکڻو پوندو جڏهن "ڪنهن ڪيترو استعمال ڪيو" منصوبي جي نوڊس ڏانهن وسيلن کي ”اُڪلائڻ“.

ٻيو نقطو، وڌيڪ پيچيده، وسيلن جي تقسيم آهي (اهي بفرز) متحرڪ نوڊس جي وچ ۾. اهو اسان کي پروٽوٽائپ جا پهريان 2 هفتا ۽ ٻيا 4 هفتا خرچ ڪري ٿو.

هن قسم جو مسئلو حاصل ڪرڻ بلڪل آسان آهي - اسان هڪ CTE ڪندا آهيون ۽ ان ۾ ڪجهه پڙهندا آهيون. حقيقت ۾، PostgreSQL "سمارٽ" آهي ۽ سڌو سنئون اتي ڪجھ به نه پڙهي سگهندو. ان کان پوء اسان ان مان پهريون رڪارڊ وٺون ٿا، ۽ ان کي ساڳئي CTE کان هڪ سئو ۽ پهريون.

اسان منصوبي کي ڏسون ٿا ۽ سمجھون ٿا - اھو عجيب آھي، اسان وٽ 3 بفر آھن (ڊيٽا صفحا) سيڪ اسڪين ۾ "استعمال ٿيل"، 1 وڌيڪ CTE اسڪين ۾، ۽ 2 وڌيڪ ٻئي CTE اسڪين ۾. اهو آهي، جيڪڏهن اسان صرف هر شيء کي گڏ ڪريون، اسان کي 6 ملندا، پر ٽيبلٽ مان اسان صرف 3 پڙهندا آهيون! CTE اسڪين ڪنهن به هنڌ کان ڪجهه به نه پڙهي، پر پروسيس ميموري سان سڌو ڪم ڪري ٿو. اهو آهي، هتي ڪجهه واضح طور تي غلط آهي!

حقيقت ۾، اهو ظاهر ٿئي ٿو ته هتي ڊيٽا جا اهي سڀئي 3 صفحا آهن جيڪي سيق اسڪين کان درخواست ڪيا ويا آهن، پهرين 1 کي پهرين CTE اسڪين لاء چيو ويو، ۽ پوء 1، ۽ 2 وڌيڪ هن کي پڙهيا ويا. 2 صفحا پڙهيا ويا ڊيٽا، نه 3.

۽ هي تصوير اسان کي سمجھڻ جي هدايت ڪئي ته منصوبي تي عملدرآمد هاڻي هڪ وڻ نه آهي، پر صرف هڪ قسم جي ايڪيڪل گراف. ۽ اسان کي هن طرح هڪ خاڪو مليو، انهي ڪري اسان سمجھون ٿا ته "ڇا آيو آهي پهرين جڳهه ۾." يعني هتي اسان pg_class مان هڪ CTE ٺاهي، ۽ ان کي ٻه ڀيرا گهريو، ۽ جڏهن اسان ٻئي دفعي ان لاءِ پڇيو ته اسان جو سڄو وقت برانچ تي گذري ويو. اهو واضح آهي ته 2 هين داخلا پڙهڻ تمام گهڻو قيمتي آهي صرف ٽيبلٽ مان پهرين داخلا پڙهڻ کان.

اسان ٿوري دير لاءِ ساهه کنيو. چيائون: ”هاڻي، نو، تون ڪنگ فو ڄاڻين ٿو! هاڻي اسان جو تجربو توهان جي اسڪرين تي صحيح آهي. هاڻي توهان ان کي استعمال ڪري سگهو ٿا." [آرٽيڪل]

لاگ استحڪام

اسان جي 1000 ڊولپرز راحت جو ساهه کنيو. پر اسان سمجھيوسين ته اسان وٽ رڳو سوين ”جنگي“ سرور آھن، ۽ ڊولپرز جي طرفان ھي سڀ ”ڪاپي پيسٽ“ بلڪل سولو ناھي. اسان محسوس ڪيو ته اسان کي پاڻ کي گڏ ڪرڻو پوندو.

عام طور تي، ھڪڙو معياري ماڊل آھي جيڪو انگ اکر گڏ ڪري سگھي ٿو، پر ان کي پڻ ترتيب ۾ چالو ڪرڻ جي ضرورت آھي - ھي ماڊل pg_stat_statements. پر هو اسان کي سمجهه ۾ نه آيو.

پهرين، اهو ساڳيو سوالن کي تفويض ڪري ٿو ساڳئي ڊيٽابيس اندر مختلف اسڪيمن استعمال ڪندي مختلف QueryIds. اهو آهي، جيڪڏهن توهان پهرين ڪندا آهيو SET search_path = '01'; SELECT * FROM user LIMIT 1;۽ پوءِ SET search_path = '02'; ۽ ساڳي درخواست، ته پوءِ هن ماڊل جا انگ اکر مختلف رڪارڊ هوندا، ۽ مان عام انگ اکر گڏ ڪري نه سگھندس خاص طور تي هن درخواست جي پروفائيل جي حوالي سان، اسڪيمن کي حساب ۾ رکڻ کان سواءِ.

ٻيو نقطو جيڪو اسان کي استعمال ڪرڻ کان روڪيو آهي منصوبن جي کوٽ. اهو آهي، ڪو به منصوبو ناهي، اتي صرف درخواست آهي. اسان ڏسون ٿا ته ڇا سست ٿي رهيو آهي، پر اسان نه ٿا سمجهون ڇو. ۽ هتي اسان هڪ تيزيء سان تبديل ٿيندڙ ڊيٽا سيٽ جي مسئلي ڏانهن موٽون ٿا.

۽ آخري لمحو - "حقيقتن" جي کوٽ. اهو آهي، توهان سوالن جي عمل جي هڪ خاص مثال کي پتو نه ٿا سگهو - اتي ڪو به ناهي، صرف مجموعي انگ اکر آهي. جيتوڻيڪ ان سان گڏ ڪم ڪرڻ ممڪن آهي، اهو صرف تمام ڏکيو آهي.

تنهن ڪري، اسان ڪاپي پيسٽ سان وڙهڻ جو فيصلو ڪيو ۽ لکڻ شروع ڪيو جمع ڪندڙ.

ڪليڪٽر SSH ذريعي ڳنڍيندو آهي، هڪ سرٽيفڪيٽ استعمال ڪندي ڊيٽابيس سان سرور سان محفوظ ڪنيڪشن قائم ڪري ٿو، ۽ tail -F "clings" ان کي لاگ فائل ۾. تنهنڪري هن سيشن ۾ اسان کي پوري لاگ فائل جو مڪمل ”عڪس“ ملي ٿو، جيڪو سرور ٺاهي ٿو. سرور تي لوڊ پاڻ گهٽ ۾ گهٽ آهي، ڇاڪاڻ ته اسان اتي ڪجھ به پارس نه ڪندا آهيون، اسان صرف ٽرئفڪ کي آئيني ڪندا آهيون.

جڏهن ته اسان انٽرفيس کي Node.js ۾ لکڻ شروع ڪيو هو، ان ڪري اسان ان ۾ ڪليڪٽر لکڻ جاري رکيو. ۽ هن ٽيڪنالاجي پاڻ کي صحيح ثابت ڪيو آهي، ڇاڪاڻ ته اهو جاوا اسڪرپٽ استعمال ڪرڻ تمام آسان آهي ڪمزور طور تي فارميٽ ٿيل ٽيڪسٽ ڊيٽا سان ڪم ڪرڻ لاء، جيڪو لاگ ان آهي. ۽ Node.js انفراسٽرڪچر پاڻ کي هڪ پس منظر پليٽ فارم جي طور تي توهان کي آساني سان ۽ آساني سان نيٽ ورڪ ڪنيڪشن سان ڪم ڪرڻ جي اجازت ڏئي ٿو، ۽ حقيقت ۾ ڪنهن به ڊيٽا اسٽريم سان.

ان جي مطابق، اسان ٻن ڪنيڪشن کي "وڌيڪ" ڪريون ٿا: پهريون "ٻڌڻ" لاگ ان کي پاڻ ڏانهن وٺي، ۽ ٻيو وقتي طور تي بنياد کان پڇڻ لاء. "پر لاگ ڏيکاري ٿو ته oid 123 سان نشاني بند ٿيل آهي،" پر ان جو مطلب ڊولپر لاءِ ڪجهه به ناهي، ۽ اهو ڊيٽابيس کان پڇڻ سٺو لڳندو، "بهرحال OID = 123 ڇا آهي؟" ۽ تنهن ڪري اسان وقتي طور تي بنيادي طور تي پڇون ٿا جيڪي اسان اڃا تائين پنهنجي باري ۾ نٿا ڄاڻون.

”صرف هڪ شيءِ آهي جنهن تي توهان غور نه ڪيو آهي، اتي هاٿي جهڙو مکين جو هڪ قسم آهي!..“ اسان هن سسٽم کي ترقي ڪرڻ شروع ڪيو جڏهن اسان 10 سرورن جي نگراني ڪرڻ چاهيون ٿا. اسان جي سمجھ ۾ سڀ کان وڌيڪ نازڪ، جتي ڪجهه مسئلا پيدا ٿيا جن سان ڊيل ڪرڻ ڏکيو هو. پر پهرين ٽه ماهي دوران، اسان مانيٽرنگ لاءِ هڪ سئو مليا - ڇاڪاڻ ته سسٽم ڪم ڪيو، هرڪو اهو چاهيندو هو، هرڪو آرام سان هو.

اهو سڀ ڪجهه شامل ڪرڻ جي ضرورت آهي، ڊيٽا جي وهڪري وڏي ۽ فعال آهي. حقيقت ۾، جيڪو اسان مانيٽر ڪريون ٿا، جيڪو اسان ڊيل ڪري سگهون ٿا، اهو آهي جيڪو اسان استعمال ڪندا آهيون. اسان پڻ استعمال ڪندا آهيون PostgreSQL ڊيٽا اسٽوريج طور. ۽ ڪجھ به تيز نه آهي "ڊالڻ" ڊيٽا ان ۾ آپريٽر کان COPY اڃا نه.

پر صرف "ڊاهڻ" ڊيٽا واقعي اسان جي ٽيڪنالاجي ناهي. ڇو ته جيڪڏهن توهان وٽ لڳ ڀڳ 50k درخواستون في سيڪنڊ هڪ سئو سرورن تي آهن، ته پوءِ اهو پيدا ڪندو 100-150GB لاگ هر ڏينهن. تنهن ڪري، اسان کي احتياط سان "ڪٽ" جو بنياد ڪرڻو پوندو.

پهرين، اسان ڪيو ورهاڱي جو ڏينهن، ڇاڪاڻ ته، عام طور تي، ڪنهن کي به ڏينهن جي وچ ۾ رابطي ۾ دلچسپي نه آهي. ان سان ڪهڙو فرق پوي ٿو جيڪو توهان ڪالهه ڪيو هو، جيڪڏهن اڄ رات توهان ايپليڪيشن جو هڪ نئون ورزن شروع ڪيو آهي - ۽ اڳ ۾ ئي ڪجهه نوان انگ اکر.

ٻيو، اسان سکيو (مجبور ڪيو ويو) تمام گھڻو، تمام تيز استعمال ڪندي لکڻ لاء COPY. اهو آهي، نه رڳو COPYڇاڪاڻ ته هو ان کان وڌيڪ تيز آهي INSERT، ۽ اڃا به تيز.

ٽيون نقطو - مون کي ڪرڻو هو ٽريگرز کي ڇڏي ڏيو، ترتيب سان، ۽ پرڏيهي ڪنجيون. اهو آهي، اسان وٽ ڪا به حوالو سالميت ناهي. ڇو ته جيڪڏهن توهان وٽ هڪ ٽيبل آهي جنهن ۾ FKs جو هڪ جوڙو آهي، ۽ توهان ڊيٽابيس جي جوڙجڪ ۾ چوندا آهيو ته "هتي هڪ لاگ رڪارڊ آهي جيڪو FK پاران حوالو ڏنو ويو آهي، مثال طور، رڪارڊ جي هڪ گروپ ڏانهن،" پوء جڏهن توهان ان کي داخل ڪيو، PostgreSQL باقي ڪجھ به نه آهي پر ان کي ڪيئن کڻڻ ۽ ايمانداري سان ڪيو SELECT 1 FROM master_fk1_table WHERE ... سڃاڻپ ڪندڙ سان جنهن کي توهان داخل ڪرڻ جي ڪوشش ڪري رهيا آهيو - صرف اهو چيڪ ڪرڻ لاءِ ته اهو رڪارڊ اتي موجود آهي، ته توهان هن فارين ڪيئي کي پنهنجي داخل ڪرڻ سان ”ٽٽ آف“ نه ڪيو.

ھدف واري جدول ۽ ان جي انڊيڪس ۾ ھڪڙي رڪارڊ جي بدران، اسان سڀني جدولن مان پڙھڻ جو اضافو فائدو حاصل ڪريون ٿا جن جو اھو حوالو ڏئي ٿو. پر اسان کي ان جي ڪا به ضرورت نه آهي - اسان جو ڪم اهو آهي ته جيترو ٿي سگهي رڪارڊ ڪجي ۽ جيترو ٿي سگهي گهٽ ۾ گهٽ لوڊ سان. پوء FK - هيٺ!

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

هاڻي تصور ڪريو ته توهان وٽ هڪ ٽيبل آهي جنهن ۾ توهان صرف انهن درخواستن جو تعداد ڳڻيو آهي جيڪي هڪ مخصوص ميزبان ذريعي گذري ويا آهن: +1, +1, +1, ..., +1. ۽ توهان، اصول ۾، هن جي ضرورت نه آهي - اهو سڀ ممڪن آهي ڪليڪٽر تي ياداشت ۾ رقم ۽ هڪ ڀيرو ۾ ڊيٽابيس ڏانهن موڪليو +10.

ها، ڪجهه مسئلن جي صورت ۾، توهان جي منطقي سالميت "ٽٽجي سگهي ٿي"، پر اهو تقريبا غير حقيقي معاملو آهي - ڇو ته توهان وٽ هڪ عام سرور آهي، ان جي ڪنٽرولر ۾ بيٽري آهي، توهان وٽ هڪ ٽرانزيڪشن لاگ آهي، هڪ لاگ ان تي. فائيل سسٽم... عام طور تي، اهو ان جي لائق ناهي. پيداوار جو نقصان جيڪو توھان حاصل ڪندا آھيو ٽريگرز/FK کي ھلائڻ سان توھان جي خرچ جي قيمت نه آھي.

اهو ساڳيو آهي hashing سان. هڪ خاص درخواست توهان ڏانهن اڏامي، توهان ڊيٽابيس ۾ ان مان هڪ خاص سڃاڻپ ڪندڙ کي ڳڻپ ڪريو، ان کي ڊيٽابيس ۾ لکو ۽ پوء سڀني کي ٻڌايو. سڀ ڪجھ ٺيڪ آهي جيستائين، رڪارڊنگ جي وقت، هڪ ٻيو شخص توهان وٽ اچي جيڪو ساڳئي شيء کي رڪارڊ ڪرڻ چاهي ٿو - ۽ توهان کي بلاڪ ڪيو وڃي، ۽ اهو اڳ ۾ ئي خراب آهي. تنهن ڪري، جيڪڏهن توهان ڪلائنٽ ڏانهن ڪجهه IDs جي نسل کي منتقل ڪري سگهو ٿا (ڊيٽابيس سان لاڳاپيل)، اهو بهتر آهي ته اهو ڪرڻ لاء.

اهو اسان لاءِ بلڪل صحيح هو MD5 کي ٽيڪسٽ مان استعمال ڪرڻ لاءِ - درخواست، پلان، ٽيمپليٽ،... اسان ان کي ڪليڪٽر جي پاسي تي ڳڻون ٿا، ۽ ڊيٽابيس ۾ تيار ٿيل ID کي "ڊايو". MD5 جي ڊيگهه ۽ روزاني ورهاڱي اسان کي ممڪن ٽڪرن جي باري ۾ پريشان ٿيڻ جي اجازت ناهي.

پر اهو سڀ ڪجهه تيزيءَ سان رڪارڊ ڪرڻ لاءِ، اسان کي رڪارڊنگ جي طريقيڪار ۾ ئي ترميم ڪرڻي هئي.

توهان عام طور تي ڊيٽا ڪيئن لکندا آهيو؟ اسان وٽ ڪجهه قسم جو ڊيٽا سيٽ آهي، اسان ان کي ڪيترن ئي جدولن ۾ ورهايو ٿا، ۽ پوءِ ان کي ڪاپي ڪريو - پهرين پهرين ۾، پوءِ ٻئي ۾، ٽئين ۾... اهو مشڪل آهي، ڇاڪاڻ ته لڳي ٿو ته اسان هڪ ڊيٽا اسٽريم کي ٽن مرحلن ۾ لکي رهيا آهيون. تسلسل سان. اڻ وڻندڙ. ڇا اهو تيز ٿي سگهي ٿو؟ ڪري سگهان ٿو!

هن کي ڪرڻ لاء، اهو ڪافي آهي ته انهن وهڪري کي هڪ ٻئي سان متوازي ۾ ختم ڪرڻ لاء. اهو ظاهر ٿئي ٿو ته اسان وٽ غلطيون آهن، درخواستون، ٽيمپليٽس، بلاڪنگ، ... الڳ الڳ موضوعن ۾ پرواز - ۽ اسان اهو سڀ ڪجهه متوازي لکندا آهيون. ان لاءِ ڪافي آهي هڪ COPY چينل کي مسلسل هر فرد جي ٽارگيٽ ٽيبل لاءِ کليل رکو.

يعني ڪليڪٽر وٽ هميشه هڪ وهڪرو آهي، جنهن ۾ مان لکي سگهان ٿو ڊيٽا جيڪا مون کي گهربل آهي. پر انهي ڪري ته ڊيٽابيس هن ڊيٽا کي ڏسي، ۽ ڪو ماڻهو هن ڊيٽا جي لکڻ جي انتظار ۾ نه رهي، COPY کي ڪجهه وقفن تي مداخلت ڪرڻ گهرجي. اسان لاء، سڀ کان وڌيڪ مؤثر مدت 100ms بابت هئي - اسان ان کي بند ڪيو ۽ فوري طور تي ان کي ٻيهر ساڳي ميز تي کوليو. ۽ جيڪڏهن اسان وٽ ڪجهه چوٽيءَ دوران هڪ وهڪرو ڪافي نه آهي، ته پوءِ اسان هڪ خاص حد تائين پولنگ ڪندا آهيون.

اضافي طور تي، اسان اهو معلوم ڪيو ته اهڙي لوڊ پروفائل لاء، ڪنهن به مجموعي، جڏهن رڪارڊ گڏ ڪيا وڃن بيچ ۾، خراب آهي. ڪلاسيڪي برائي آهي INSERT ... VALUES ۽ وڌيڪ 1000 رڪارڊ. ڇو ته ان موقعي تي توهان وٽ ميڊيا تي لکڻ جي چوٽي آهي، ۽ هرڪو جيڪو ڊسڪ تي ڪجهه لکڻ جي ڪوشش ڪري رهيو آهي انتظار ڪيو ويندو.

اهڙين بي ضابطگين کان نجات حاصل ڪرڻ لاءِ، بس ڪجهه به نه گڏيو، هرگز بفر نه ڪريو. ۽ جيڪڏهن ڊسڪ تي بفرنگ ٿئي ٿي (خوشقسمتي سان، اسٽريم API Node.js ۾ توهان کي ڳولڻ جي اجازت ڏئي ٿي) - هن ڪنيڪشن کي ملتوي ڪريو. جڏهن توهان هڪ واقعو وصول ڪيو ته اهو ٻيهر مفت آهي، ان کي جمع ٿيل قطار مان لکو. ۽ جڏهن اهو مصروف آهي، پول مان ايندڙ مفت وٺو ۽ ان ڏانهن لکو.

ڊيٽا جي رڪارڊنگ جي هن طريقي کي متعارف ڪرائڻ کان اڳ، اسان وٽ لڳ ڀڳ 4K لکڻ جا اختيار هئا، ۽ هن طريقي سان اسان 4 ڀيرا لوڊ گھٽائي ڇڏيو. ھاڻي اھي 6 ڀيرا وڌيا آھن نوان مانيٽر ٿيل ڊيٽابيس جي ڪري - 100MB/s تائين. ۽ ھاڻي اسان 3-10TB جي مقدار ۾ گذريل 15 مھينن جا لاگ اسٽور ڪريون ٿا، اميد آھي ته صرف ٽن مھينن ۾ ڪو به ڊولپر ڪو به مسئلو حل ڪري سگھندو.

اسان مسئلن کي سمجهون ٿا

پر صرف اهو سڀ ڊيٽا گڏ ڪرڻ سٺو، مفيد، لاڳاپيل، پر ڪافي ناهي - اهو سمجهڻ جي ضرورت آهي. ڇو ته اهي روزانو لکين مختلف منصوبا آهن.

پر لکين غير منظم آهن، اسان کي پهريان ڪرڻ گهرجي ”ننڍو“. ۽، سڀ کان پهريان، توهان کي اهو فيصلو ڪرڻو پوندو ته توهان هن "ننڍي" شيء کي ڪيئن منظم ڪنداسين.

اسان ٽن اهم نقطن جي نشاندهي ڪئي آهي:

• ڪير آهي هن درخواست موڪلي
  اهو آهي، ڪهڙي ائپليڪيشن مان اهو "پهچندو": ويب انٽرفيس، پس منظر، ادائگي جو نظام يا ٻيو ڪجهه.
• جتي اهو ٿيو
  ڪهڙي مخصوص سرور تي؟ ڇو ته جيڪڏهن توهان وٽ هڪ ايپليڪيشن تحت ڪيترائي سرور آهن، ۽ اوچتو هڪ "بيوقوف ٿي وڃي ٿو" (ڇاڪاڻ ته "ڊسڪ خراب آهي"، "ميموري ليڪ"، ڪجهه ٻيو مسئلو)، پوء توهان کي خاص طور تي سرور کي پتو ڏيڻ جي ضرورت آهي.
• ڪيئن مسئلو پاڻ کي ڪنهن نه ڪنهن طريقي سان ظاهر ڪيو آهي

سمجھڻ لاءِ ”ڪير“ اسان کي درخواست موڪلي، اسان ھڪ معياري اوزار استعمال ڪندا آھيون- سيشن متغير ترتيب ڏيڻ: SET application_name = '{bl-host}:{bl-method}'; - اسان واپار جي منطق جي ميزبان جو نالو موڪليندا آهيون جتان درخواست اچي رهي آهي، ۽ طريقي يا ايپليڪيشن جو نالو جيڪو ان کي شروع ڪيو.

اسان جي درخواست جي "مالڪ" کي منظور ڪرڻ کان پوء، ان کي لاگ ان ٿيڻ گهرجي - ان لاء اسان متغير کي ترتيب ڏيون ٿا. log_line_prefix = ' %m [%p:%v] [%d] %r %a'. دلچسپي وارن لاء، شايد دستياب ۾ ڏسواهو سڀ ڇا مطلب آهي. اهو ظاهر ٿئي ٿو ته اسان لاگ ان ۾ ڏسون ٿا:

• время
• عمل ۽ ٽرانزيڪشن جي سڃاڻپ ڪندڙ
• ڊيٽابيس جو نالو
• ان شخص جو IP پتي جنهن هن درخواست موڪلي
• ۽ طريقي جو نالو

پوءِ اسان محسوس ڪيو ته مختلف سرورن جي وچ ۾ هڪ درخواست لاءِ لاڳاپو ڏسڻ لاءِ اهو تمام دلچسپ ناهي. اهو اڪثر نه آهي ته توهان وٽ هڪ اهڙي صورتحال آهي جتي هڪ ايپليڪيشن هتي ۽ اتي جي برابر آهي. پر جيتوڻيڪ اهو ساڳيو آهي، انهن مان ڪنهن به سرور کي ڏسو.

تنهنڪري هتي کٽ آهي "هڪ سرور - هڪ ڏينهن" اهو ڪنهن به تجزيي لاءِ اسان لاءِ ڪافي ثابت ٿيو.

پهريون تجزياتي حصو ساڳيو آهي "نموني" - منصوبي جي پيشڪش جو هڪ مختصر روپ، سڀني عددي اشارن کان صاف. ٻيو ڪٽ ايپليڪيشن يا طريقو آهي، ۽ ٽيون ڪٽ مخصوص پلان نوڊ آهي جيڪو اسان کي مسئلا پيدا ڪري ٿو.

جڏهن اسان مخصوص مثالن کان ٽيمپليٽس ڏانهن منتقل ڪيو، اسان کي هڪ ڀيرو ٻه فائدا مليا:

• تجزيي لاءِ شين جي تعداد ۾ گھڻا گھٽتائي
  اسان کي ھاڻي ھزارين سوالن يا منصوبن سان نه پر ڪيترن ئي ٽيمپليٽس ذريعي مسئلي جو تجزيو ڪرڻو پوندو.
• ٽائيم لائن
  اھو آھي، ھڪڙي خاص حصي ۾ "حقيقتن" کي اختصار ڪرڻ سان، توھان ڏينھن ۾ انھن جي ظاھر کي ڏيکاري سگھو ٿا. ۽ هتي توهان سمجهي سگهو ٿا ته جيڪڏهن توهان وٽ ڪجهه قسم جو نمونو آهي، مثال طور، هڪ ڪلاڪ ۾ هڪ ڀيرو، پر اهو هڪ ڏينهن ۾ هڪ ڀيرو ٿيڻ گهرجي، توهان کي سوچڻ گهرجي ته ڇا غلط ٿيو - ڪير اهو ڪيو ۽ ڇو، شايد اهو هتي هجڻ گهرجي. نه گهرجي. هي هڪ ٻيو غير عددي، خالص بصري، تجزيو جو طريقو آهي.

باقي طريقا انهن اشارن تي ٻڌل آهن جيڪي اسان پلان مان ڪڍون ٿا: ڪيترا ڀيرا اهڙي نموني واقع ٿي، مجموعي ۽ سراسري وقت، ڊسڪ مان ڪيترو ڊيٽا پڙهيو ويو، ۽ ميموري مان ڪيترو ...

ڇو ته، مثال طور، توهان ميزبان لاء تجزياتي صفحي تي ايندا آهيو، ڏسو - ڪجهه ڊسڪ تي تمام گهڻو پڙهڻ شروع ڪري رهيو آهي. سرور تي ڊسڪ ان کي سنڀالي نٿو سگهي - ڪير ان مان پڙهي ٿو؟

۽ توهان ڪنهن به ڪالمن سان ترتيب ڏئي سگهو ٿا ۽ اهو فيصلو ڪري سگهو ٿا ته توهان هن وقت ڇا سان ڊيل ڪندا - پروسيسر يا ڊسڪ تي لوڊ، يا درخواستن جو ڪل تعداد... اسان ان کي ترتيب ڏنو، "مٿين" وارن کي ڏٺو، ان کي درست ڪيو ۽ ايپليڪيشن جو هڪ نئون ورزن جاري ڪيو.
[ويڊيو ليڪچر]

۽ فوري طور تي توهان مختلف ايپليڪيشنون ڏسي سگهو ٿا جيڪي هڪ ئي ٽيمپليٽ سان گڏ اچن ٿيون جهڙوڪ درخواست کان SELECT * FROM users WHERE login = 'Vasya'. فرنٽ اينڊ، پس منظر، پروسيسنگ... ۽ توهان حيران ٿي رهيا آهيو ته پروسيسنگ استعمال ڪندڙ کي پڙهندو ڇو ته هو ان سان رابطو نه ڪندو.

سامهون طريقو اهو آهي ته فوري طور تي ايپليڪيشن مان ڏسو ته اهو ڇا ڪري ٿو. مثال طور، فرنٽ اينڊ هي آهي، هي، هي، ۽ هي هڪ ڪلاڪ ۾ هڪ ڀيرو (ٽائم لائن مدد ڪري ٿي). ۽ سوال فوري طور تي پيدا ٿئي ٿو: اهو لڳي ٿو ته اهو هڪ ڪلاڪ ۾ هڪ ڀيرو ڪجهه ڪرڻ فرنٽ اينڊ جو ڪم ناهي ...

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

توهان وٽ پليٽ تي مناسب انڊيڪس نه آهي، توهان ان لاءِ درخواست ڪريو ٿا، اهو انڊيڪس مان گذري ٿو، سيڪ اسڪين ۾ اچي ٿو... توهان هڪ کان سواءِ سڀئي رڪارڊ فلٽر ڪري ڇڏيا آهن. توهان کي هر روز 100M فلٽر ٿيل رڪارڊ جي ضرورت ڇو آهي؟ ڇا اهو بهتر ناهي ته انڊيڪس کي رول ڪيو وڃي؟

سڀني منصوبن جي نوڊ جي نوڊ جو تجزيو ڪرڻ کان پوءِ، اسان محسوس ڪيو ته منصوبن ۾ ڪجھ عام جوڙجڪ آھن جيڪي مشڪوڪ نظر اچن ٿا. ۽ اهو ڊولپر کي ٻڌائڻ لاء سٺو لڳندو: "دوست، هتي توهان پهرين انڊيڪس ذريعي پڙهو، پوء ترتيب ڏيو، ۽ پوء ڪٽي ڇڏيو" - ضابطي جي طور تي، هڪ رڪارڊ آهي.

هرڪو جيڪو سوال لکيو آهي شايد هن نموني سان منهن ڪيو آهي: "مون کي واسيا لاء آخري آرڊر ڏيو، ان جي تاريخ." ۽ جيڪڏهن توهان وٽ تاريخ طرفان ڪا انڊيڪس نه آهي، يا توهان جي استعمال ڪيل انڊيڪس ۾ ڪا تاريخ ناهي، ته پوء توهان بلڪل ساڳي "ريڪ" تي قدم.

پر اسان ڄاڻون ٿا ته هي هڪ "ريڪ" آهي - پوء ڇو نه فوري طور تي ڊولپر کي ٻڌايو ته هن کي ڇا ڪرڻ گهرجي. تنهن ڪري، جڏهن هاڻي هڪ منصوبي کي کوليو، اسان جي ڊولپر کي فوري طور تي هڪ خوبصورت تصوير ڏسڻ ۾ اچي ٿي، جتي اهي فوري طور تي کيس چوندا آهن: "توهان کي هتي ۽ اتي مسئلا آهن، پر اهي هن طريقي سان حل ڪيا ويا آهن."

نتيجي طور، تجربو جو مقدار جيڪو شروع ۾ مسئلا حل ڪرڻ جي ضرورت هئي ۽ هاڻي تمام گهڻو گهٽجي ويو آهي. هي هڪ قسم جو اوزار آهي جيڪو اسان وٽ آهي.

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