توهان کي ياد آهي ته اهو سڀ ڪيئن شروع ٿيو. سڀ ڪجهه پهريون ڀيرو ۽ ٻيهر هو

انهي بابت اسان کي ڪيئن بهتر ڪرڻي هئي PostgreSQL سوال ۽ ان مان ڇا نڪتو.
توهان کي ڇو ڪرڻو پيو؟ ها، ڇاڪاڻ ته گذريل 4 سالن تائين هر شيء خاموشيء سان ڪم ڪيو، آرام سان، هڪ ڪلاڪ جي ٽڪنگ وانگر.
هڪ epigraph جي طور تي.

حقيقي واقعن جي بنياد تي.
سڀئي نالا تبديل ڪيا ويا آهن، اتفاقات بي ترتيب آهن.

جڏهن توهان هڪ خاص نتيجو حاصل ڪندا آهيو، اهو هميشه ياد رکڻ لاء دلچسپ آهي ته شروعات لاء محرک ڇا هو، جتي اهو سڀ ڪجهه شروع ٿيو.

تنهن ڪري، نتيجي طور ڇا ٿيو، مختصر طور تي مضمون ۾ بيان ڪيو ويو آهي "PostgreSQL ڪارڪردگي کي بهتر ڪرڻ جي طريقن مان هڪ جي طور تي Synthesis».

اهو شايد دلچسپ هوندو ته گذريل واقعن جي زنجير کي ٻيهر ٺاهڻ.
تاريخ محفوظ ڪئي صحيح شروعاتي تاريخ - 2018-09-10 18:02:48.
گڏوگڏ، ڪهاڻي ۾ هڪ درخواست آهي جنهن مان اهو سڀ ڪجهه شروع ڪيو ويو آهي:
مسئلو درخواستچونڊيو
p. "PARAMETER_ID" بطور parameter_id،
pd."PD_NAME" AS pd_name،
pd."CUSTOMER_PARTNUMBER" AS ڪسٽمر_حصو نمبر،
w. "LRM" AS LRM،
w. "LOTID" جيئن لوٽيڊ،
w.“RTD_VALUE” AS RTD_value،
w.“LOWER_SPEC_LIMIT” AS low_spec_limit،
w.“UPPER_SPEC_LIMIT” AS upper_spec_limit،
p. "TYPE_CALCUL" AS type_calcul،
s."SPENT_NAME" AS spent_name،
s. "SPENT_DATE" AS spent_date،
ڪڍيو (سال "SPENT_DATE" کان) AS سال،
ڪڍيو ("SPENT_DATE" کان مهينو) مهيني طور،
s."REPORT_NAME" AS report_name،
p."STPM_NAME" AS stpm_name،
p. “CUSTOMERPARAM_NAME” as customerparam_name
wdata w کان،
خرچ ڪيو،
پي ايم ٽي آر پي،
خرچ_پي ڊي ايس پي،
pd pd
ڪٿي s. "SPENT_ID" = w. "SPENT_ID"
۽ p."PARAMETER_ID" = w."PARAMETER_ID"
۽ s.“SPENT_ID” = sp.“SPENT_ID”
۽ pd."PD_ID" = sp."PD_ID"
۽ s.“SPENT_DATE” >= '2018-07-01' ۽ s. “SPENT_DATE” <= '2018-09-30'
۽ s.“SPENT_DATE” = (SELECT MAX(s2. “SPENT_DATE”)
خرچ ڪيل s2 کان،
wdata w2
ڪٿي s2. "SPENT_ID" = w2. "SPENT_ID"
۽ w2. "LRM" = w. "LRM")؛

مسئلي جي وضاحت متوقع طور تي معياري آهي - "سڀ ڪجھ خراب آهي. مون کي ٻڌايو ته مسئلو ڇا آهي؟"
مون کي فوري طور تي ساڍا 3 انچ ڊرائيو جي وقت کان هڪ قصو ياد آيو:

لامر هيڪر وٽ اچي ٿو.
- مون لاءِ ڪجھ به ڪم نٿو ڪري، مون کي ٻڌايو ته مسئلو ڪٿي آھي.
- ڊي اين اي ۾ ...

پر يقينا، اهو ڪارڪردگي جي واقعن کي حل ڪرڻ جو طريقو ناهي. "اهي شايد اسان کي سمجهي نه سگھندا"(سان). اسان کي ان کي سمجهڻ جي ضرورت آهي.
خير، اچو ته کوٽائي. ٿي سگهي ٿو نتيجي طور ڪجهه جمع ٿيندو.

تحقيق شروع ٿي وئي

تنهن ڪري، ننگي اک سان فوري طور تي ڇا ڏسي سگهجي ٿو، بغير وضاحت ڪرڻ کان سواء.
1) JOIN استعمال نه ڪيا ويا آهن. اهو خراب آهي، خاص طور تي جيڪڏهن ڪنيڪشن جو تعداد هڪ کان وڌيڪ آهي.
2) پر ڇا ان کان به وڌيڪ خراب آهي لاڳاپيل ذيلي سوال، ان کان علاوه، مجموعي سان. هي تمام خراب آهي.
اهو يقيناً خراب آهي. پر اهو صرف هڪ طرف آهي. ٻئي طرف، اهو تمام سٺو آهي، ڇاڪاڻ ته مسئلو واضح طور تي هڪ حل آهي ۽ هڪ درخواست جيڪا بهتر ٿي سگهي ٿي.
خوشخبري ڏيندڙ (سي) وٽ نه وڃو.
سوال جو منصوبو ايترو پيچيده نه آهي، پر اهو ڪافي اشارو آهي:
عملدرآمد پلان

سڀ کان وڌيڪ دلچسپ ۽ مفيد، عام طور تي، شروعات ۽ آخر ۾ آهي.
نيسٽ ٿيل لوپ (قيمت = 935.84..479763226.18 قطار = 3322 ويڪر = 135) (اصل وقت = 31.536..8220420.295 قطار = 8111656 لوپس = 1)
منصوبه بندي جو وقت: 3.807 ايم ايس
عمل جو وقت: 8222351.640 ايم ايس
مڪمل ٿيڻ جو وقت 2 ڪلاڪن کان وڌيڪ آهي.

غلط مفروضا جن وقت ورتو

مفروضو 1 - اصلاح ڪندڙ غلطي ڪري ٿو ۽ غلط منصوبو ٺاھي ٿو.

عمل جي منصوبي کي ڏسڻ لاء، اسان سائيٽ استعمال ڪنداسين https://explain.depesz.com/. بهرحال، سائيٽ ڪجھ به دلچسپ يا مفيد نه ڏيکاريو. پهرين ۽ ٻي نظر ۾، ڪجھ به نه آهي جيڪو واقعي مدد ڪري سگهي ٿو. ڇا اهو ممڪن آهي ته مڪمل اسڪين گهٽ ۾ گهٽ آهي. اڳتي وڃو.

Hypothesis 2-اثر جي بنياد تي autovacuum پاسي کان، توهان brakes کان نجات حاصل ڪرڻ جي ضرورت آهي.

پر آٽو ويڪيوم ڊيمون سٺو ڪم ڪن ٿا، اتي ڪو ڊگھو پھانسي وارو عمل نه آھي. ڪو به سنجيده لوڊ. اسان کي ٻيو ڪجهه ڳولڻ جي ضرورت آهي.

مفروضو 3 - انگ اکر پراڻا آهن، هر شي کي ٻيهر ڳڻڻ جي ضرورت آهي

ٻيهر، اهو نه. انگ اکر تازو آهن. جنهن کي، autovacuum سان مسئلن جي کوٽ ڏني، حيرت انگيز نه آهي.

اچو ته اصلاح شروع ڪريون

مکيه جدول 'wdata' يقيني طور تي ننڍڙو نه آهي، تقريبن 3 ملين رڪارڊ.
۽ اھو ھي ٽيبل آھي جنھن کي مڪمل اسڪين ھيٺ ڏنل آھي.

هيش ڪنڊ: ((w."SPENT_ID" = s."SPENT_ID") ۽ ((SubPlan 1) = s."SPENT_DATE"))
-> سيڪ اسڪين wdata w تي (قيمت = 0.00..574151.49 قطار = 26886249 ويڪر = 46) (اصل وقت = 0.005..8153.565 قطار = 26873950 لوپس = 1)
اسان معياري ڪم ڪندا آهيون: "اچو، اچو ته هڪ انڊيڪس ٺاهيو ۽ سڀ ڪجهه اڏامي ويندو."
"SPENT_ID" فيلڊ تي هڪ انڊيڪس ٺاهيو
نتيجي طور:
انڊيڪس استعمال ڪندي پڇا ڳاڇا ڪرڻ وارو منصوبو

خير، ان جي مدد ڪئي؟
هو: 8 222 351.640 ايم ايس (2 ڪلاڪ کان ٿورو وڌيڪ)
اهو ٿيو: 6 985 431.575 ms (تقريبن 2 ڪلاڪ)
عام طور تي، ساڳيو انب، پاسي جو ڏيک.
اچو ته ڪلاسيڪل ياد رکون:
”ڇا توهان وٽ ساڳيو آهي، پر پنن کان سواءِ؟ ڳوليندو“.

اصول ۾، اهو هڪ سٺو نتيجو سڏيو وڃي ٿو، سٺو، سٺو نه، پر قابل قبول. گهٽ ۾ گهٽ، گراهڪ کي هڪ وڏي رپورٽ مهيا ڪريو بيان ڪيو ويو آهي ڪيترو ڪيو ويو آهي ۽ ڇو ڪيو ويو سٺو هو.
پر اڃا تائين، حتمي فيصلو اڃا پري آهي. تمام پري.

۽ هاڻي سڀ کان وڌيڪ دلچسپ شيء - اسان کي بهتر ڪرڻ لاء جاري آهي، اسان کي درخواست پالش ڪنداسين

قدم هڪ - شامل ڪريو استعمال ڪريو

ٻيهر لکيل درخواست هاڻي هن طرح نظر اچي ٿي (گهٽ ۾ گهٽ وڌيڪ خوبصورت):
JOIN استعمال ڪندي سوالچونڊيو
p. "PARAMETER_ID" بطور parameter_id،
pd."PD_NAME" AS pd_name،
pd."CUSTOMER_PARTNUMBER" AS ڪسٽمر_حصو نمبر،
w. "LRM" AS LRM،
w. "LOTID" جيئن لوٽيڊ،
w.“RTD_VALUE” AS RTD_value،
w.“LOWER_SPEC_LIMIT” AS low_spec_limit،
w.“UPPER_SPEC_LIMIT” AS upper_spec_limit،
p. "TYPE_CALCUL" AS type_calcul،
s."SPENT_NAME" AS spent_name،
s. "SPENT_DATE" AS spent_date،
ڪڍيو (سال "SPENT_DATE" کان) AS سال،
ڪڍيو ("SPENT_DATE" کان مهينو) مهيني طور،
s."REPORT_NAME" AS report_name،
p."STPM_NAME" AS stpm_name،
p. “CUSTOMERPARAM_NAME” as customerparam_name
اندرون شامل ٿيڻ جي ڊيٽا سان گڏ خرچ ڪيو ويو w.“SPENT_ID”=s.” “SPENT_ID”
اندروني شموليت pmtr p on p. “PARAMETER_ID” = w. “PARAMETER_ID”
اندروني شموليت spent_pd sp ON s. "SPENT_ID" = sp. "SPENT_ID"
اندروني شموليت pd pd ON pd. "PD_ID" = sp. "PD_ID"
جڏهن
s. “SPENT_DATE” >= '2018-07-01' ۽ s. “SPENT_DATE” <= '2018-09-30'AND
s. "SPENT_DATE" = (MAX کي چونڊيو (s2. "SPENT_DATE")
w2 w2 اندروني شامل ٿيڻ کان wdata s2 تي w2.“SPENT_ID”=sXNUMX.“SPENT_ID”
اندروني شموليت wdata w
ON w2. "LRM" = w. "LRM" );
منصوبه بندي جو وقت: 2.486 ايم ايس
عمل جو وقت: 1223680.326 ايم ايس

تنهن ڪري، پهريون نتيجو.
هو: 6 ms (اٽڪل 985 ڪلاڪ).
اهو ٿيو: 1 223 680.326 ms (صرف 20 منٽ کان وڌيڪ).
سٺو نتيجو. اصول ۾، ٻيهر، اسان اتي روڪي سگهون ٿا. پر اهو تمام دلچسپ آهي، توهان روڪي نه ٿا سگهو.
لاءِ

ٻه قدم - لاڳاپيل ذيلي سوالن کان نجات حاصل ڪريو

تبديل ٿيل درخواست متن:
بغير لاڳاپيل ذيلي سوال جيچونڊيو
p. "PARAMETER_ID" بطور parameter_id،
pd."PD_NAME" AS pd_name،
pd."CUSTOMER_PARTNUMBER" AS ڪسٽمر_حصو نمبر،
w. "LRM" AS LRM،
w. "LOTID" جيئن لوٽيڊ،
w.“RTD_VALUE” AS RTD_value،
w.“LOWER_SPEC_LIMIT” AS low_spec_limit،
w.“UPPER_SPEC_LIMIT” AS upper_spec_limit،
p. "TYPE_CALCUL" AS type_calcul،
s."SPENT_NAME" AS spent_name،
s. "SPENT_DATE" AS spent_date،
ڪڍيو (سال "SPENT_DATE" کان) AS سال،
ڪڍيو ("SPENT_DATE" کان مهينو) مهيني طور،
s."REPORT_NAME" AS report_name،
p."STPM_NAME" AS stpm_name،
p. “CUSTOMERPARAM_NAME” as customerparam_name
WDATA FROM INNER JOIN خرچ s ON s. "SPENT_ID" = w. "SPENT_ID"
اندروني شموليت pmtr p on p. “PARAMETER_ID” = w. “PARAMETER_ID”
اندروني شموليت spent_pd sp ON s. "SPENT_ID" = sp. "SPENT_ID"
اندروني شموليت pd pd ON pd. "PD_ID" = sp. "PD_ID"
اندروني شموليت (چونڊيو w2. ​​"LRM"، MAX (s2. "SPENT_DATE")
خرچ ٿيل s2 اندران شامل ٿيو w2 ڊيٽا w2 تي s2. “SPENT_ID” = wXNUMX. “SPENT_ID”
گروپ پاران w2. "LRM"
) md on w. "LRM" = md. "LRM"
جڏهن
s."SPENT_DATE" >= '2018-07-01' ۽ s."SPENT_DATE" <= '2018-09-30';
منصوبه بندي جو وقت: 2.291 ايم ايس
عمل جو وقت: 165021.870 ايم ايس

هو: 1 223 680.326 ms (صرف 20 منٽ کان وڌيڪ).
اهو ٿيو: 165 021.870 ms (صرف 2 منٽ کان وڌيڪ).
اهو اڳ ۾ ئي تمام سٺو آهي.
بهرحال، جيئن انگريزن جو چوڻ آهي ته "پر، اتي هميشه هڪ پر آهي" ھڪڙو نتيجو جيڪو تمام سٺو آھي، خود بخود شڪ پيدا ڪرڻ گھرجي. هتي ڪجهه غلط آهي.

لاڳاپيل ذيلي پڇا ڳاڇا مان نجات حاصل ڪرڻ لاءِ سوال کي درست ڪرڻ بابت مفروضو صحيح آهي. پر حتمي نتيجو صحيح ٿيڻ لاءِ توھان کي ٿورڙي ٽوڪ ڪرڻ جي ضرورت آھي.
نتيجي طور، پهريون وچولي نتيجو:
تبديل ٿيل سوال بغير لاڳاپيل ذيلي سوال جيچونڊيو
p. "PARAMETER_ID" بطور parameter_id،
pd."PD_NAME" AS pd_name،
pd."CUSTOMER_PARTNUMBER" AS ڪسٽمر_حصو نمبر،
w. "LRM" AS LRM،
w. "LOTID" جيئن لوٽيڊ،
w.“RTD_VALUE” AS RTD_value،
w.“LOWER_SPEC_LIMIT” AS low_spec_limit،
w.“UPPER_SPEC_LIMIT” AS upper_spec_limit،
p. "TYPE_CALCUL" AS type_calcul،
s."SPENT_NAME" AS spent_name،
s. "SPENT_DATE" AS spent_date،
ڪڍيو (سال کان s. “SPENT_DATE”) AS سال،
ڪڍيو (s. “SPENT_DATE” کان مهينو) مهيني طور،
s."REPORT_NAME" AS report_name،
p."STPM_NAME" AS stpm_name،
p. “CUSTOMERPARAM_NAME” as customerparam_name
WDATA FROM INNER JOIN خرچ s ON s. "SPENT_ID" = w. "SPENT_ID"
اندروني شموليت pmtr p on p. “PARAMETER_ID” = w. “PARAMETER_ID”
اندروني شموليت spent_pd sp ON s. "SPENT_ID" = sp. "SPENT_ID"
اندروني شموليت pd pd ON pd. "PD_ID" = sp. "PD_ID"
اندروني شموليت (چونڊيو w2. ​​"LRM"، MAX(s2. "SPENT_DATE") AS "SPENT_DATE"
خرچ ٿيل s2 اندران شامل ٿيو w2 ڊيٽا w2 تي s2. “SPENT_ID” = wXNUMX. “SPENT_ID”
گروپ پاران w2. "LRM"
) md ON md. "SPENT_DATE" = s. "SPENT_DATE" ۽ md. "LRM" = w. "LRM"
جڏهن
s."SPENT_DATE" >= '2018-07-01' ۽ s."SPENT_DATE" <= '2018-09-30';
منصوبه بندي جو وقت: 3.192 ايم ايس
عمل جو وقت: 208014.134 ايم ايس

تنهن ڪري، جيڪو اسان ختم ڪريون ٿا اهو پهريون قابل قبول نتيجو آهي، جيڪو گراهڪ کي ڏيکارڻ لاء شرم نه آهي:
سان شروع ڪيو: 8 222 351.640 ms (2 ڪلاڪ کان وڌيڪ)
اسان حاصل ڪرڻ ۾ ڪامياب ٿي ويا: 1 ms (223 منٽ کان ٿورو وڌيڪ).
نتيجو (عبوري): 208 014.134 ms (صرف 3 منٽ کان وڌيڪ).

شاندار نتيجو.

نتيجو

اسان اتي روڪي سگهون ها.
پر…
کائڻ سان بک اچي ٿي. جيڪو ھلندو اھو ئي رستو ٺاھيندو. ڪو به نتيجو وچڙ آهي. بند ٿي ويو ۽ مري ويو. وغيره.
اچو ته اصلاح جاري رکون.
عظيم خيال. خاص طور تي غور ڪيو ته گراهڪ به ڌيان نه ڏنو. ۽ ان لاءِ به سخت.

تنهن ڪري، اهو وقت آهي ڊيٽابيس کي ٻيهر ڊزائين ڪرڻ لاء. سوال جي جوڙجڪ پاڻ کي وڌيڪ بهتر نه ٿو ڪري سگهجي (جيتوڻيڪ، جيئن اهو بعد ۾ نڪتو، اتي هڪ اختيار آهي انهي کي يقيني بڻائڻ ته هر شيء اصل ۾ ناڪام ٿئي ٿي). پر ڊيٽابيس ڊيزائن کي بهتر ڪرڻ ۽ ترقي ڪرڻ شروع ڪرڻ لاءِ اڳ ۾ ئي هڪ تمام پرجوش خيال آهي. ۽ سڀ کان اهم دلچسپ. ٻيهر، پنهنجي جوانيء کي ياد ڪريو. مان فوري طور تي ڊي بي اي نه بڻجي ويو آهيان، مان هڪ پروگرامر جي حيثيت سان وڏو ٿيس (BASIC، assembler، C، Double-plus C، Oracle، plsql). هڪ دلچسپ موضوع، يقينا، هڪ الڳ يادگار لاء ؛-).
بهرحال، اچو ته پريشان نه ٿي وڃو.

۽ ائين،

يا ٿي سگهي ٿو ورهاڱي اسان جي مدد ڪندو؟
اسپائلر - "ها، اها مدد ڪئي، بشمول ڪارڪردگي کي بهتر ڪرڻ ۾."

پر اها هڪ مڪمل طور تي مختلف ڪهاڻي آهي ...

جاري رکڻ گهرجي…

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