PostgreSQL და JDBC გამოწურავს მთელ წვენს. ვლადიმერ სიტნიკოვი

გირჩევთ, წაიკითხოთ ვლადიმერ სიტნიკოვის 2016 წლის დასაწყისის მოხსენების ტრანსკრიპტი „PostgreSQL და JDBC მთელ წვენს ასხამენ“

Საღამო მშვიდობისა მე მქვია ვლადიმერ სიტნიკოვი. 10 წელია ვმუშაობ NetCracker-ში. და მე ძირითადად პროდუქტიულობაში ვარ. ყველაფერი რაც ჯავასთან არის დაკავშირებული, ყველაფერი SQL-თან არის ის, რაც მე მიყვარს.

დღეს კი ვისაუბრებ იმაზე, თუ რა შეგვხვდა კომპანიაში, როდესაც დავიწყეთ PostgreSQL მონაცემთა ბაზის სერვერად გამოყენება. და ჩვენ ძირითადად Java-სთან ვმუშაობთ. მაგრამ ის, რასაც დღეს მოგიყვებით, მხოლოდ ჯავას არ ეხება. როგორც პრაქტიკამ აჩვენა, ეს სხვა ენებშიც ხდება.

Ვილაპარაკებთ:

• მონაცემთა შერჩევის შესახებ.
• მონაცემთა შენახვის შესახებ.
• და ასევე შესრულების შესახებ.
• და რაც შეეხება წყალქვეშა რაფებს, რომლებიც იქ არის დაკრძალული.

დავიწყოთ მარტივი კითხვით. ცხრილიდან ვირჩევთ ერთ რიგს პირველადი გასაღების საფუძველზე.

მონაცემთა ბაზა მდებარეობს იმავე ჰოსტზე. და მთელი ეს მეურნეობა იღებს 20 მილიწამს.

ეს 20 მილიწამი ბევრია. თუ თქვენ გაქვთ 100 ასეთი მოთხოვნა, მაშინ ხარჯავთ დროს წამში ამ მოთხოვნების გადახვევაში, ანუ ჩვენ ვკარგავთ დროს.

ჩვენ არ გვიყვარს ამის გაკეთება და ვნახოთ, რას გვთავაზობს ბაზა ამისთვის. მონაცემთა ბაზა გვთავაზობს მოთხოვნების შესრულების ორ ვარიანტს.

პირველი ვარიანტი არის მარტივი მოთხოვნა. რა არის ამაში კარგი? ის, რომ ვიღებთ და ვაგზავნით და მეტი არაფერი.

https://github.com/pgjdbc/pgjdbc/pull/478

მონაცემთა ბაზას ასევე აქვს მოწინავე მოთხოვნა, რომელიც უფრო რთული, მაგრამ უფრო ფუნქციონალურია. თქვენ შეგიძლიათ ცალ-ცალკე გაგზავნოთ მოთხოვნა გაანალიზების, შესრულების, ცვლადის დაკავშირების და ა.შ.

სუპერ გაფართოებული მოთხოვნა არის ის, რასაც ჩვენ არ გავაშუქებთ მიმდინარე ანგარიშში. ჩვენ, ალბათ, რაღაც გვინდა მონაცემთა ბაზიდან და არის სურვილების სია, რომელიც რაღაც ფორმით არის ჩამოყალიბებული, ანუ ეს არის ის, რაც ჩვენ გვინდა, მაგრამ ეს შეუძლებელია ახლა და მომავალ წელს. ასე რომ, ჩვენ უბრალოდ ჩავწერეთ ეს და ჩვენ შემოვივლით მთავარ ადამიანთა შერყევას.

და რაც შეგვიძლია გავაკეთოთ არის მარტივი შეკითხვა და გაფართოებული შეკითხვა.

რა არის განსაკუთრებული თითოეულ მიდგომაში?

მარტივი შეკითხვა კარგია ერთჯერადი შესრულებისთვის. ერთხელ დასრულებული და დავიწყებული. და პრობლემა ის არის, რომ ის არ უჭერს მხარს ორობითი მონაცემთა ფორმატს, ანუ ის არ არის შესაფერისი ზოგიერთი მაღალი ხარისხის სისტემისთვის.

გაფართოებული შეკითხვა - საშუალებას გაძლევთ დაზოგოთ დრო ანალიზის დროს. ეს არის ის, რაც ჩვენ გავაკეთეთ და დავიწყეთ გამოყენება. ეს ნამდვილად დაგვეხმარა. დანაზოგი არ არის მხოლოდ გარჩევაზე. არის დაზოგვა მონაცემთა გადაცემაზე. მონაცემების ორობით ფორმატში გადატანა ბევრად უფრო ეფექტურია.

მოდით გადავიდეთ პრაქტიკაზე. ასე გამოიყურება ტიპიური აპლიკაცია. ეს შეიძლება იყოს ჯავა და ა.შ.

ჩვენ შევქმენით განცხადება. შეასრულა ბრძანება. შეიქმნა ახლოს. სად არის აქ შეცდომა? Რა არის პრობლემა? Არაა პრობლემა. ასე წერია ყველა წიგნში. ასე უნდა დაიწეროს. თუ გსურთ მაქსიმალური შესრულება, დაწერეთ ასე.

მაგრამ პრაქტიკამ აჩვენა, რომ ეს არ მუშაობს. რატომ? რადგან ჩვენ გვაქვს „დახურული“ მეთოდი. და როცა ამას ვაკეთებთ, მონაცემთა ბაზის თვალსაზრისით გამოდის, რომ ეს ჰგავს მწეველს, რომელიც მუშაობს მონაცემთა ბაზასთან. ჩვენ ვთქვით: „დაამოწმეთ EXECUTE DEALLOCATE“.

რატომ არის განცხადებების ეს ზედმეტი შექმნა და განტვირთვა? არავის სჭირდება ისინი. მაგრამ რაც ჩვეულებრივ ხდება PreparedStatements-ში არის ის, რომ როდესაც ჩვენ ვხურავთ მათ, ისინი ხურავენ ყველაფერს მონაცემთა ბაზაში. ეს არ არის ის, რაც ჩვენ გვინდა.

ჩვენ გვინდა, როგორც ჯანსაღი ადამიანები, ვიმუშაოთ ბაზასთან. ერთხელ ავიღეთ და მოვამზადეთ ჩვენი განცხადება, შემდეგ ბევრჯერ ვასრულებთ. სინამდვილეში, ბევრჯერ - ეს არის ერთხელ აპლიკაციების მთელი ცხოვრების განმავლობაში - ისინი გაანალიზებულია. და ჩვენ ვიყენებთ იგივე განცხადების id-ს სხვადასხვა REST-ებზე. ეს არის ჩვენი მიზანი.

როგორ მივაღწიოთ ამას?

ეს ძალიან მარტივია - არ არის საჭირო განცხადებების დახურვა. ჩვენ ვწერთ ასე: "მოამზადე" "შეასრულე".

თუ მსგავს რამეს გავუშვებთ, მაშინ გასაგებია, რომ სადღაც რაღაც გადმოიღვრება. თუ გაუგებარია, შეგიძლიათ სცადოთ. მოდით დავწეროთ ბენჩმარკი, რომელიც იყენებს ამ მარტივ მეთოდს. შექმენით განცხადება. ჩვენ მას გავუშვით დრაივერის ზოგიერთ ვერსიაზე და აღმოვაჩენთ, რომ ის საკმაოდ სწრაფად იშლება მთელი მეხსიერების დაკარგვით, რაც ჰქონდა.

ნათელია, რომ ასეთი შეცდომები ადვილად გამოსწორდება. მათზე არ ვისაუბრებ. მაგრამ მე ვიტყვი, რომ ახალი ვერსია ბევრად უფრო სწრაფად მუშაობს. მეთოდი სულელურია, მაგრამ მაინც.

როგორ ვიმუშაოთ სწორად? რა უნდა გავაკეთოთ ამისთვის?

სინამდვილეში, აპლიკაციები ყოველთვის ხურავს განცხადებებს. ყველა წიგნში ამბობენ, დახურეთ, თორემ მეხსიერება გაჟონავს.

და PostgreSQL-მა არ იცის როგორ მოახდინოს მოთხოვნების ქეშირება. აუცილებელია, რომ თითოეულმა სესიამ შექმნას ეს ქეში თავისთვის.

და ჩვენ არ გვინდა დროის დაკარგვა გარჩევაზეც.

და როგორც ყოველთვის გვაქვს ორი ვარიანტი.

პირველი ვარიანტი არის ის, რომ ავიღოთ და ვიტყვით, რომ მოდი ყველაფერი PgSQL-ში გავაფუჭოთ. იქ არის ქეში. ის ინახავს ყველაფერს. მშვენივრად გამოვა. ჩვენ ვნახეთ ეს. ჩვენ გვაქვს 100500 მოთხოვნა. Არ მუშაობს. ჩვენ არ ვეთანხმებით მოთხოვნების ხელით გადაქცევას პროცედურებად. Არა არა.

ჩვენ გვაქვს მეორე ვარიანტი - აიღეთ და თავად დავჭრათ. ვხსნით წყაროებს და ვიწყებთ ჭრას. ვნახეთ და ვნახეთ. აღმოჩნდა, რომ ამის გაკეთება არც ისე რთულია.

https://github.com/pgjdbc/pgjdbc/pull/319

ეს გამოჩნდა 2015 წლის აგვისტოში. ახლა არის უფრო თანამედროვე ვერსია. და ყველაფერი შესანიშნავია. ის იმდენად კარგად მუშაობს, რომ აპლიკაციაში არაფერს ვცვლით. ჩვენ კი შევწყვიტეთ ფიქრი PgSQL-ის მიმართულებით, ანუ ეს სავსებით საკმარისი იყო იმისათვის, რომ ყველა ზედნადები ხარჯები თითქმის ნულამდე შეგვეყვანა.

შესაბამისად, სერვერის მიერ მომზადებული განცხადებები გააქტიურებულია მე-5 შესრულებაზე, რათა თავიდან იქნას აცილებული მეხსიერების დაკარგვა მონაცემთა ბაზაში ყოველი ერთჯერადი მოთხოვნით.

შეიძლება გკითხოთ - სად არის ნომრები? რას იღებთ? და აქ მე არ მივცემ ციფრებს, რადგან თითოეულ მოთხოვნას აქვს თავისი.

ჩვენი მოთხოვნები ისეთი იყო, რომ დაახლოებით 20 მილიწამი დავხარჯეთ OLTP შეკითხვებზე ანალიზზე. შესრულებისთვის იყო 0,5 მილიწამი, გარჩევისთვის 20 მილიწამი. მოთხოვნა - 10 KiB ტექსტი, 170 სტრიქონი გეგმა. ეს არის OLTP მოთხოვნა. ის ითხოვს 1, 5, 10 ხაზს, ზოგჯერ მეტს.

მაგრამ ჩვენ საერთოდ არ გვინდოდა 20 მილიწამის დაკარგვა. 0-მდე შევამცირეთ. ყველაფერი მშვენიერია.

რისი წაღება შეგიძლიათ აქედან? თუ ჯავა გაქვს, მაშინ აიღე დრაივერის თანამედროვე ვერსია და გაიხარე.

თუ სხვა ენაზე საუბრობთ, მაშინ დაფიქრდით - იქნებ ეს თქვენც გჭირდებათ? რადგან საბოლოო ენის თვალსაზრისით, მაგალითად, თუ PL 8 ან გაქვთ LibPQ, მაშინ თქვენთვის აშკარა არ არის, რომ დროს ხარჯავთ არა შესრულებაზე, პარსირებაზე და ამის შემოწმება ღირს. Როგორ? ყველაფერი უფასოა.

გარდა იმისა, რომ არის შეცდომები და გარკვეული თავისებურებები. და ჩვენ ახლა ვისაუბრებთ მათზე. უმეტესობა იქნება ინდუსტრიულ არქეოლოგიაზე, იმაზე, რაც აღმოვაჩინეთ, რასაც წავაწყდით.

თუ მოთხოვნა გენერირებულია დინამიურად. Ხდება ხოლმე. ვიღაც აწებებს სტრიქონებს, რის შედეგადაც ხდება SQL მოთხოვნა.

რატომ არის ის ცუდი? ეს ცუდია, რადგან ყოველ ჯერზე ჩვენ სხვადასხვა სტრიქონს ვხვდებით.

და ამ განსხვავებული სტრიქონის ჰეშკოდი ხელახლა უნდა წაიკითხოთ. ეს ნამდვილად CPU ამოცანაა - მოთხოვნის გრძელი ტექსტის პოვნა არსებულ ჰეშშიც კი არც ისე ადვილია. აქედან გამომდინარე, დასკვნა მარტივია - არ შექმნათ მოთხოვნები. შეინახეთ ისინი ერთ ცვლადში. და გაიხარე.

შემდეგი პრობლემა. მონაცემთა ტიპები მნიშვნელოვანია. არის ORM-ები, რომლებიც ამბობენ, რომ არ აქვს მნიშვნელობა როგორი NULL არის, მოდით იყოს რაიმე. თუ Int, მაშინ ჩვენ ვამბობთ setInt. და თუ NULL, მაშინ ის ყოველთვის იყოს VARCHAR. და რა განსხვავებაა საბოლოოდ რა არის NULL? მონაცემთა ბაზა თავად მიხვდება ყველაფერს. და ეს სურათი არ მუშაობს.

პრაქტიკაში, მონაცემთა ბაზას საერთოდ არ აინტერესებს. თუ პირველად თქვით, რომ ეს არის რიცხვი, ხოლო მეორედ თქვით, რომ ეს არის VARCHAR, მაშინ შეუძლებელია სერვერის მიერ მომზადებული განცხადებების ხელახლა გამოყენება. და ამ შემთხვევაში, ჩვენ ხელახლა უნდა შევქმნათ ჩვენი განცხადება.

თუ თქვენ ასრულებთ იმავე მოთხოვნას, დარწმუნდით, რომ თქვენს სვეტში მონაცემთა ტიპები არ არის დაბნეული. თქვენ უნდა გაუფრთხილდეთ NULL-ს. ეს არის ჩვეულებრივი შეცდომა, რომელიც გვქონდა მას შემდეგ, რაც დავიწყეთ PreparedStatements-ის გამოყენება

კარგი, ჩართულია. იქნებ მძღოლი წაიყვანეს. და პროდუქტიულობა დაეცა. საქმე ცუდად გახდა.

როგორ ხდება ეს? ეს შეცდომაა თუ ფუნქცია? სამწუხაროდ, შეუძლებელი გახდა იმის გაგება, არის ეს შეცდომა თუ ფუნქცია. მაგრამ არსებობს ძალიან მარტივი სცენარი ამ პრობლემის რეპროდუცირებისთვის. მან სრულიად მოულოდნელად დაგვაჩასაფრა. და ის შედგება სიტყვასიტყვით ერთი ცხრილიდან შერჩევისგან. ჩვენ, რა თქმა უნდა, უფრო მეტი ასეთი მოთხოვნა გვქონდა. როგორც წესი, მათ მოიცავდა ორი ან სამი მაგიდა, მაგრამ არსებობს ასეთი დაკვრის სცენარი. აიღეთ ნებისმიერი ვერსია თქვენი მონაცემთა ბაზიდან და ითამაშეთ.

https://gist.github.com/vlsi/df08cbef370b2e86a5c1

საქმე იმაშია, რომ გვაქვს ორი სვეტი, რომელთაგან თითოეული ინდექსირებულია. ერთ NULL სვეტში მილიონი მწკრივია. ხოლო მეორე სვეტი შეიცავს მხოლოდ 20 ხაზს. როდესაც ვასრულებთ შეკრული ცვლადების გარეშე, ყველაფერი კარგად მუშაობს.

თუ ჩვენ დავიწყებთ შესრულებას შეკრული ცვლადებით, ანუ ვასრულებთ "?" ან „$1“ ჩვენი მოთხოვნისთვის, რას მივიღებთ საბოლოოდ?

https://gist.github.com/vlsi/df08cbef370b2e86a5c1

პირველი აღსრულება როგორც მოსალოდნელი იყო. მეორე ცოტა უფრო სწრაფია. რაღაც შენახული იყო. მესამე, მეოთხე, მეხუთე. მაშინ bang - და რაღაც მსგავსი. და ყველაზე ცუდი ის არის, რომ ეს ხდება მეექვსე აღსრულებაზე. ვინ იცოდა, რომ საჭირო იყო ზუსტად ექვსი სიკვდილით დასჯა, რათა გაერკვია, რა იყო რეალური აღსრულების გეგმა?

ვინ არის დამნაშავე? Რა მოხდა? მონაცემთა ბაზა შეიცავს ოპტიმიზაციას. და როგორც ჩანს, ის ოპტიმიზებულია ზოგადი შემთხვევისთვის. და, შესაბამისად, რაღაც მომენტიდან დაწყებული, ის გადადის ზოგად გეგმაზე, რომელიც, სამწუხაროდ, შეიძლება განსხვავებული აღმოჩნდეს. შეიძლება აღმოჩნდეს იგივე, ან შეიძლება განსხვავებული იყოს. და არის გარკვეული ზღვრული მნიშვნელობა, რომელიც იწვევს ამ ქცევას.

რა შეგიძლიათ ამის გაკეთება? აქ, რა თქმა უნდა, უფრო რთულია რაიმეს ვარაუდი. არსებობს მარტივი გამოსავალი, რომელსაც ჩვენ ვიყენებთ. ეს არის +0, OFFSET 0. რა თქმა უნდა, თქვენ იცით ასეთი გადაწყვეტილებები. ჩვენ უბრალოდ ვიღებთ მას და ვამატებთ "+0" მოთხოვნას და ყველაფერი კარგადაა. მოგვიანებით გაჩვენებ.

და არის კიდევ ერთი ვარიანტი - შეხედეთ გეგმებს უფრო ყურადღებით. დეველოპერმა არა მხოლოდ უნდა დაწეროს მოთხოვნა, არამედ უნდა თქვას "ახსნა ანალიზი" 6-ჯერ. თუ 5-ია, არ იმუშავებს.

და არის მესამე ვარიანტი - დაწერეთ წერილი pgsql-ჰაკერებს. მე დავწერე, თუმცა, ჯერ არ არის ნათელი, არის ეს შეცდომა თუ ფუნქცია.

https://gist.github.com/vlsi/df08cbef370b2e86a5c1

სანამ ჩვენ ვფიქრობთ არის ეს შეცდომა თუ ფუნქცია, მოდით გამოვასწოროთ იგი. ავიღოთ ჩვენი მოთხოვნა და დავამატოთ "+0". Ყველაფერი კარგადაა. ორი სიმბოლო და არც კი უნდა იფიქრო როგორ არის ან რა არის. Ძალიან მარტივი. ჩვენ უბრალოდ აუკრძალეთ მონაცემთა ბაზას ამ სვეტის ინდექსის გამოყენება. ჩვენ არ გვაქვს ინდექსი "+0" სვეტზე და ეს არის ის, მონაცემთა ბაზა არ იყენებს ინდექსს, ყველაფერი კარგადაა.

ეს არის 6-ის ახსნის წესი. ახლა მიმდინარე ვერსიებში თქვენ უნდა გააკეთოთ ეს 6-ჯერ, თუ გაქვთ შეკრული ცვლადები. თუ არ გაქვთ შეკრული ცვლადები, ჩვენ ამას ვაკეთებთ. და ბოლოს სწორედ ეს თხოვნა მარცხდება. ეს არ არის სახიფათო რამ.

როგორც ჩანს, რამდენად შესაძლებელია? შეცდომა აქ, შეცდომა იქ. სინამდვილეში, შეცდომა ყველგან არის.

მოდით უფრო ახლოს მივხედოთ. მაგალითად, ჩვენ გვაქვს ორი სქემა. სქემა A ცხრილით S და დიაგრამა B ცხრილით S. შეკითხვა - აირჩიეთ მონაცემები ცხრილიდან. რა გვექნება ამ შემთხვევაში? ჩვენ გვექნება შეცდომა. ჩვენ გვექნება ყოველივე ზემოთქმული. წესია - ბუგი ყველგანაა, ზემოთ ჩამოთვლილი გვექნება.

ახლა ჩნდება კითხვა: "რატომ?" როგორც ჩანს, არსებობს დოკუმენტაცია, რომ თუ ჩვენ გვაქვს სქემა, მაშინ არის "search_path" ცვლადი, რომელიც გვეუბნება სად უნდა ვეძებოთ ცხრილი. როგორც ჩანს, არსებობს ცვლადი.

Რა არის პრობლემა? პრობლემა ის არის, რომ სერვერის მიერ მომზადებული განცხადებები არ ეჭვობენ, რომ search_path შეიძლება ვინმემ შეიცვალოს. ეს მნიშვნელობა, როგორც იყო, მუდმივი რჩება მონაცემთა ბაზისთვის. და ზოგიერთმა ნაწილმა შეიძლება არ მიიღოს ახალი მნიშვნელობა.

რა თქმა უნდა, ეს დამოკიდებულია ვერსიაზე, რომელზეც ცდები. დამოკიდებულია იმაზე, თუ რამდენად სერიოზულად განსხვავდება თქვენი მაგიდები. და ვერსია 9.1 უბრალოდ შეასრულებს ძველ შეკითხვებს. ახალმა ვერსიებმა შეიძლება დაიჭიროს შეცდომა და გითხრათ, რომ ხარვეზი გაქვთ.

დააყენეთ search_path + სერვერის მიერ მომზადებული განცხადებები =
ქეშირებული გეგმა არ უნდა შეცვალოს შედეგის ტიპი

როგორ ვუმკურნალოთ? არსებობს მარტივი რეცეპტი - არ გააკეთოთ ეს. აპლიკაციის მუშაობისას არ არის საჭირო search_path-ის შეცვლა. თუ შეცვლით, უმჯობესია შექმნათ ახალი კავშირი.

შეგიძლიათ განიხილოთ, ანუ გახსნათ, განიხილოთ, დაამატოთ. შესაძლოა, ჩვენ შეგვიძლია დავარწმუნოთ მონაცემთა ბაზის დეველოპერები, რომ როდესაც ვინმე ცვლის მნიშვნელობას, მონაცემთა ბაზამ კლიენტს უნდა უთხრას ამის შესახებ: „აჰა, თქვენი მნიშვნელობა აქ განახლებულია. იქნებ დაგჭირდეთ განცხადებების გადატვირთვა და ხელახლა შექმნა?” ახლა მონაცემთა ბაზა ფარულად იქცევა და არანაირად არ იუწყება, რომ განცხადებები შეიცვალა სადღაც შიგნით.

და კიდევ ერთხელ ხაზგასმით აღვნიშნავ - ეს არის ის, რაც ჯავისთვის არ არის დამახასიათებელი. ჩვენ იგივეს დავინახავთ PL/pgSQL-ში ერთი ერთზე. მაგრამ იქ გამრავლდება.

მოდით ვცადოთ სხვა მონაცემების შერჩევა. ჩვენ ვირჩევთ და ვირჩევთ. ჩვენ გვაქვს მაგიდა მილიონი მწკრივით. თითოეული ხაზი არის კილობაიტი. დაახლოებით გიგაბაიტი მონაცემები. და ჩვენ გვაქვს სამუშაო მეხსიერება Java მანქანაში 128 მეგაბაიტი.

ჩვენ, როგორც რეკომენდებულია ყველა წიგნში, ვიყენებთ ნაკადის დამუშავებას. ანუ ვხსნით resultSet-ს და იქიდან ვკითხულობთ მონაცემებს ნელ-ნელა. იმუშავებს? ამოვარდება მეხსიერებიდან? ცოტას წაიკითხავ? მოდით ვენდოთ მონაცემთა ბაზას, ვენდოთ Postgres-ს. ჩვენ არ გვჯერა. გამოვვარდებით მეხსიერებიდან? ვინ გამოსცადა OutOfMemory? ვინ მოახერხა ამის გამოსწორება? ვიღაცამ მოახერხა ამის გამოსწორება.

თუ თქვენ გაქვთ მილიონი სტრიქონი, თქვენ არ შეგიძლიათ უბრალოდ აირჩიოთ და აირჩიოთ. საჭიროა OFFSET/LIMIT. ვინ არის ამ ვარიანტის მომხრე? და ვინ არის მომხრე autoCommit-ით თამაშისას?

აქ, როგორც ყოველთვის, ყველაზე მოულოდნელი ვარიანტი სწორი აღმოჩნდება. და თუ მოულოდნელად გამორთავთ autoCommit, ეს დაგეხმარებათ. Რატომ არის, რომ? მეცნიერებამ არ იცის ამის შესახებ.

მაგრამ ნაგულისხმევად, ყველა კლიენტი, რომელიც უკავშირდება Postgres მონაცემთა ბაზას, იღებს მთელ მონაცემებს. PgJDBC არ არის გამონაკლისი ამ მხრივ, ის ირჩევს ყველა მწკრივს.

არსებობს ვარიაცია FetchSize თემასთან დაკავშირებით, ანუ ცალკე განცხადების დონეზე შეგიძლიათ თქვათ, რომ აქ, გთხოვთ, აირჩიოთ მონაცემები 10, 50-ით. მაგრამ ეს არ მუშაობს მანამ, სანამ არ გამორთავთ ავტომატურ დასრულებას. გამორთულია autoCommit - ის იწყებს მუშაობას.

მაგრამ კოდის გავლა და setFetchSize ყველგან დაყენება მოუხერხებელია. ამიტომ, ჩვენ შევქმენით პარამეტრი, რომელიც იტყვის ნაგულისხმევ მნიშვნელობას მთელი კავშირისთვის.

სწორედ ეს ვთქვით. პარამეტრი დაკონფიგურირებულია. და რა მივიღეთ? თუ ჩვენ ვირჩევთ მცირე რაოდენობას, თუ, მაგალითად, ავირჩევთ 10 რიგს ერთდროულად, მაშინ გვაქვს ძალიან დიდი ზედნადები ხარჯები. ამიტომ, ეს მნიშვნელობა უნდა იყოს დაყენებული დაახლოებით ასამდე.

იდეალურ შემთხვევაში, რა თქმა უნდა, თქვენ ჯერ კიდევ უნდა ისწავლოთ მისი შეზღუდვა ბაიტებში, მაგრამ რეცეპტი ასეთია: დააყენეთ defaultRowFetchSize ასზე მეტზე და იყავით ბედნიერი.

მოდით გადავიდეთ მონაცემების ჩასმაზე. ჩასმა უფრო ადვილია, არსებობს სხვადასხვა ვარიანტი. მაგალითად, INSERT, VALUES. ეს კარგი ვარიანტია. შეგიძლიათ თქვათ „INSERT SELECT“. პრაქტიკაში იგივეა. შესრულებაში განსხვავება არ არის.

წიგნებში ნათქვამია, რომ თქვენ უნდა შეასრულოთ Batch განცხადება, წიგნებში ნათქვამია, რომ შეგიძლიათ შეასრულოთ უფრო რთული ბრძანებები რამდენიმე ფრჩხილით. და Postgres-ს აქვს შესანიშნავი ფუნქცია - შეგიძლიათ გააკეთოთ COPY, ანუ გააკეთოთ ეს უფრო სწრაფად.

თუ გაზომავთ, შეგიძლიათ კვლავ გააკეთოთ რამდენიმე საინტერესო აღმოჩენა. როგორ გვინდა, რომ ეს იმუშაოს? ჩვენ გვინდა არ გავაანალიზოთ და არ შევასრულოთ არასაჭირო ბრძანებები.

პრაქტიკაში, TCP არ გვაძლევს ამის საშუალებას. თუ კლიენტი დაკავებულია მოთხოვნის გაგზავნით, მაშინ მონაცემთა ბაზა არ კითხულობს მოთხოვნებს ჩვენთვის პასუხების გაგზავნის მცდელობაში. საბოლოო შედეგი არის ის, რომ კლიენტი ელოდება მონაცემთა ბაზას მოთხოვნის წაკითხვას, ხოლო მონაცემთა ბაზა ელოდება კლიენტს პასუხის წაკითხვას.

და ამიტომ კლიენტი იძულებულია პერიოდულად გაგზავნოს სინქრონიზაციის პაკეტი. დამატებითი ქსელის ურთიერთქმედება, დამატებითი დროის დაკარგვა.

და რაც უფრო მეტს ვამატებთ მათ, მით უფრო უარესდება. მძღოლი საკმაოდ პესიმისტურია და საკმაოდ ხშირად ამატებს მათ, დაახლოებით 200 ხაზზე ერთხელ, ხაზების ზომის მიხედვით და ა.შ.

https://github.com/pgjdbc/pgjdbc/pull/380

ეს ხდება, რომ შეასწორებ მხოლოდ ერთ ხაზს და ყველაფერი 10-ჯერ დაჩქარდება. Ხდება ხოლმე. რატომ? ჩვეულებისამებრ, მსგავსი მუდმივი სადღაც უკვე გამოყენებულია. და მნიშვნელობა „128“ ნიშნავდა არ გამოეყენებინა სერიული.

ჯავის მიკრობენჩმარკის აღკაზმულობა

კარგია, რომ ეს არ იყო შეტანილი ოფიციალურ ვერსიაში. აღმოჩენილი გამოშვების დაწყებამდე. ყველა მნიშვნელობა, რომელსაც მე ვაძლევ, ეფუძნება თანამედროვე ვერსიებს.

მოდი ვცადოთ. ჩვენ ვზომავთ InsertBatch მარტივია. ჩვენ ვზომავთ InsertBatch-ს რამდენჯერმე, ანუ ერთი და იგივე, მაგრამ ბევრი მნიშვნელობაა. სახიფათო ნაბიჯი. ყველას არ შეუძლია ამის გაკეთება, მაგრამ ეს ისეთი მარტივი ნაბიჯია, ბევრად უფრო ადვილია, ვიდრე COPY.

შეგიძლიათ გააკეთოთ COPY.

და ამის გაკეთება შეგიძლიათ სტრუქტურებზე. გამოაცხადეთ მომხმარებლის ნაგულისხმევი ტიპი, გადაიტანეთ მასივი და ჩადეთ პირდაპირ ცხრილში.

თუ გახსნით ბმულს: pgjdbc/ubenchmsrk/InsertBatch.java, მაშინ ეს კოდი არის GitHub-ზე. თქვენ შეგიძლიათ ნახოთ კონკრეტულად რა მოთხოვნები იქმნება იქ. არ აქვს მნიშვნელობა.

გავუშვით. და პირველი, რაც მივხვდით, იყო ის, რომ სურათების გამოუყენებლობა უბრალოდ შეუძლებელია. შეკრების ყველა ვარიანტი ნულოვანია, ანუ შესრულების დრო პრაქტიკულად ნულის ტოლია ერთჯერად შესრულებასთან შედარებით.

ჩვენ ვამატებთ მონაცემებს. ძალიან მარტივი მაგიდაა. სამი სვეტი. და რას ვხედავთ აქ? ჩვენ ვხედავთ, რომ სამივე ეს ვარიანტი დაახლოებით შესადარებელია. და COPY, რა თქმა უნდა, უკეთესია.

ამ დროს ჩვენ ნაწილებს ჩავსვამთ. როდესაც ჩვენ ვთქვით, რომ ერთი VALUES მნიშვნელობა, ორი VALUES მნიშვნელობა, სამი VALUES მნიშვნელობა, ან მივუთითეთ 10 მათგანი გამოყოფილი მძიმით. ეს ახლა მხოლოდ ჰორიზონტალურია. 1, 2, 4, 128. ჩანს, რომ Batch Insert, რომელიც ლურჯად არის დახატული, მას ბევრად უკეთესად გრძნობს თავს. ანუ, როდესაც თქვენ ჩასვით ერთ დროს ან თუნდაც ოთხის ჩასმა ერთდროულად, ის ორჯერ უკეთესი ხდება, უბრალოდ იმიტომ, რომ ჩვენ ცოტა მეტი ჩავდეთ VALUES-ში. ნაკლები EXECUTE ოპერაციები.

COPY-ის გამოყენება მცირე მოცულობებზე უკიდურესად არაპერსპექტიულია. პირველ ორზე არც დავხატე. ისინი მიდიან სამოთხეში, ანუ ეს მწვანე ნომრები COPY-სთვის.

COPY უნდა იქნას გამოყენებული, როდესაც თქვენ გაქვთ მონაცემების მინიმუმ ასი მწკრივი. ამ კავშირის გახსნის ზედნადები დიდია. და, მართალი გითხრათ, ამ მიმართულებით არ ვთხრიდი. მე გავაუმჯობესე Batch, მაგრამ არა COPY.

რა ვქნათ შემდეგ? ჩვენ ვცადეთ. ჩვენ გვესმის, რომ ჩვენ უნდა გამოვიყენოთ ან სტრუქტურები ან ჭკვიანი ბაქო, რომელიც აერთიანებს რამდენიმე მნიშვნელობას.

რა უნდა წაართვათ დღევანდელ მოხსენებას?

• PreparedStatement არის ჩვენი ყველაფერი. ეს ბევრს იძლევა პროდუქტიულობისთვის. ის აწარმოებს მალამოში დიდ ნაპრალს.
• და თქვენ უნდა გააკეთოთ EXPLAIN ANALYZE 6-ჯერ.
• და ჩვენ უნდა გავაზავოთ OFFSET 0 და ისეთი ხრიკები, როგორიცაა +0, რათა გამოვასწოროთ ჩვენი პრობლემური მოთხოვნების დარჩენილი პროცენტი.

წყარო: www.habr.com