განახლება ზარმაცებისთვის: როგორ აუმჯობესებს PostgreSQL 12 შესრულებას

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

ჩემი აზრით, წინა გამოშვებებისგან განსხვავებით, PostgreSQL 12 არ შეიცავს ერთ ან ორ რევოლუციურ მახასიათებელს (როგორიცაა დაყოფა ან შეკითხვის პარალელიზმი). ერთხელ ვიხუმრე, რომ PostgreSQL 12-ის მთავარი მახასიათებელია უფრო დიდი სტაბილურობა. ეს არ არის ის, რაც გჭირდებათ, როდესაც მართავთ თქვენი ბიზნესის კრიტიკულ მონაცემებს?

მაგრამ PostgreSQL 12 აქ არ ჩერდება: ახალი ფუნქციებითა და გაუმჯობესებებით, აპლიკაციები უკეთესად იმუშავებენ, და ყველაფერი რაც თქვენ უნდა გააკეთოთ არის განახლება!

(კარგი, შესაძლოა ინდექსების აღდგენა, მაგრამ ამ გამოშვებაში ეს არ არის ისეთი საშინელი, როგორც ჩვენ მიჩვეული.)

მშვენიერი იქნება PostgreSQL-ის განახლება და დაუყოვნებლივ ისარგებლეთ მნიშვნელოვანი გაუმჯობესებით ზედმეტი აურზაურის გარეშე. რამდენიმე წლის წინ გადავხედე PostgreSQL 9.4-დან PostgreSQL 10-მდე განახლებას და დავინახე, როგორ აჩქარდა აპლიკაცია PostgreSQL 10-ში გაუმჯობესებული შეკითხვის პარალელურობის წყალობით. და, რაც მთავარია, ჩემგან თითქმის არაფერი იყო საჭირო (უბრალოდ დააყენეთ კონფიგურაციის პარამეტრი max_parallel_workers).

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

როგორ შეიძლება PostgreSQL 12-ის უბრალო განახლებამ გაგახაროთ? ახლავე გეტყვი.

ინდექსირების ძირითადი გაუმჯობესება

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

ჩვენ უბრალოდ ვიყენებთ ოპერატორს CREATE INDEX ON some_table (some_column)და PostgreSQL ბევრს აკეთებს ინდექსის განახლების შესანარჩუნებლად, სანამ ჩვენ მუდმივად ვსვამთ, ვაახლებთ და ვშლით მნიშვნელობებს. ყველაფერი თავისთავად მუშაობს, თითქოს ჯადოსნურად.

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

PostgreSQL 12 მნიშვნელოვნად აუმჯობესებს B-ხის ინდექსების მუშაობას და ექსპერიმენტებმა ბენჩმარკებით, როგორიცაა TPC-C, აჩვენა, რომ ახლა საშუალოდ 40%-ით ნაკლები სივრცეა გამოყენებული. ახლა ნაკლებ დროს ვხარჯავთ არა მხოლოდ B-ხის ინდექსების შენარჩუნებაზე (ანუ ჩაწერის ოპერაციებზე), არამედ მონაცემების მოპოვებაზეც, რადგან ინდექსები გაცილებით მცირეა.

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

ზოგიერთი განახლების სტრატეგია მოითხოვს B-ხის ინდექსების აღდგენას, რათა ისარგებლოს ამ უპირატესობებით (მაგ. pg_upgrade არ აღადგენს ინდექსებს ავტომატურად). PostgreSQL-ის წინა ვერსიებში, ცხრილებზე დიდი ინდექსების აღდგენამ გამოიწვია მნიშვნელოვანი შეფერხება, რადგან ცვლილებები მანამდე ვერ განხორციელდა. მაგრამ PostgreSQL 12-ს აქვს კიდევ ერთი მაგარი ფუნქცია: ახლა თქვენ შეგიძლიათ აღადგინოთ ინდექსები ბრძანების პარალელურად. REINDEX პარალელურადრომ მთლიანად თავიდან აიცილოთ შეფერხება.

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

PostgreSQL 12-მა შეამცირა WAL ჩანაწერების ზედნადები, რომლებიც იქმნება GiST, GIN და SP-GiST ინდექსებით ინდექსის მშენებლობის დროს. ეს უზრუნველყოფს რამდენიმე ხელშესახებ სარგებელს: WAL ჩანაწერები იკავებს ნაკლებ ადგილს დისკზე და მონაცემები უფრო სწრაფად ითამაშება, მაგალითად, კატასტროფის აღდგენის ან დროული აღდგენის დროს. თუ იყენებთ ასეთ ინდექსებს თქვენს აპლიკაციებში (მაგალითად, PostGIS-ზე დაფუძნებული გეოსივრცული აპლიკაციები ხშირად იყენებენ GiST ინდექსს), ეს არის კიდევ ერთი ფუნქცია, რომელიც მნიშვნელოვნად გააუმჯობესებს გამოცდილებას თქვენი მხრიდან ძალისხმევის გარეშე.

დანაყოფი - უფრო დიდი, უკეთესი, სწრაფი

დაინერგა PostgreSQL 10 დეკლარაციული დანაყოფი. PostgreSQL 11-ში მისი გამოყენება ბევრად უფრო ადვილი გახდა. PostgreSQL 12-ში შეგიძლიათ შეცვალოთ სექციების მასშტაბი.

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

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

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

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

შეკითხვებთან ერთად ბევრად უკეთესი გახდა

როდესაც პატჩი გამოყენებული იყო ჩაშენებული ცხრილის საერთო გამონათქვამებისთვის (aka CTE, aka WITH queries), ვერ ვიტანდი სტატიის დაწერას რამდენად კმაყოფილი იყვნენ აპლიკაციების დეველოპერები PostgreSQL-ით. ეს არის ერთ-ერთი იმ თვისება, რომელიც დააჩქარებს აპლიკაციას. თუ, რა თქმა უნდა, არ იყენებთ CTE-ს.

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

PostgreSQL 12 საშუალებას გაძლევთ შეიყვანოთ კონკრეტული ტიპის CTE გვერდითი ეფექტების გარეშე (SELECT), რომელიც გამოიყენება მხოლოდ ერთხელ მოთხოვნის ბოლოს. თუ მე თვალყურს ვადევნებდი ჩემს მიერ ხელახლა დაწერილი CTE შეკითხვებს, მათი უმეტესობა ამ კატეგორიაში მოხვდებოდა. ეს ეხმარება დეველოპერებს დაწერონ მკაფიო კოდი, რომელიც ახლა ასევე სწრაფად მუშაობს.

უფრო მეტიც, PostgreSQL 12 ოპტიმიზირებს SQL-ის შესრულებას, თქვენ არაფრის გაკეთების გარეშე. და მიუხედავად იმისა, რომ ახლა ალბათ არ დამჭირდება ასეთი მოთხოვნების ოპტიმიზაცია, მშვენიერია, რომ PostgreSQL აგრძელებს მუშაობას შეკითხვის ოპტიმიზაციაზე.

Just-in-Time (JIT) - ახლა ნაგულისხმევი

PostgreSQL 12 სისტემებზე მხარდაჭერით ლვ JIT კომპილაცია ჩართულია ნაგულისხმევად. პირველ რიგში, თქვენ მიიღებთ მხარდაჭერას JIT ზოგიერთი შიდა ოპერაციებისთვის და მეორეც, გამონათქვამებით (უმარტივესი მაგალითია x + y) შერჩეულ სიებში (რომლებიც გაქვთ SELECT-ის შემდეგ), აგრეგატები, გამონათქვამები WHERE პუნქტებით და სხვებს შეუძლიათ გამოიყენონ JIT შესრულების გასაუმჯობესებლად.

ვინაიდან JIT ჩართულია ნაგულისხმევად PostgreSQL 12-ში, შესრულება თავისთავად გაუმჯობესდება, მაგრამ მე გირჩევთ აპლიკაციის ტესტირებას PostgreSQL 11-ში, რომელმაც შემოიღო JIT, შეკითხვის შესრულების გასაზომად და თუ გჭირდებათ რაიმეს დარეგულირება.

რაც შეეხება დანარჩენ ახალ ფუნქციებს PostgreSQL 12-ში?

PostgreSQL 12-ს აქვს უამრავი მაგარი ახალი ფუნქცია, JSON მონაცემების შემოწმების უნარიდან სტანდარტული SQL/JSON მარშრუტის გამონათქვამების გამოყენებით, პარამეტრით მრავალფაქტორიანი ავთენტიფიკაციამდე. clientcert=verify-full, შექმნა სვეტები და მრავალი სხვა. საკმარისია ცალკე პოსტისთვის.

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

წყარო: www.habr.com