როგორ გადავრჩეთ SQL მონაცემთა ბაზას 21-ე საუკუნეში: ღრუბლები, Kubernetes და PostgreSQL multimaster

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

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

ვებინარი გაიმართა ვალერი ბეზრუკოვი, Google Cloud Practice Delivery Manager EPAM Systems-ში.

როცა ხეები პატარა იყო...

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

90-იანი წლების ბოლოს და 2-იანი წლების დასაწყისში, არსებითად არ იყო არჩევანი, როდესაც საქმე ეხება ინდუსტრიულ მასშტაბურ მონაცემთა ბაზებს. დიახ, იყო IBM DBXNUMX, Sybase და კიდევ რამდენიმე მონაცემთა ბაზა, რომელიც მოდიოდა და წავიდა, მაგრამ ზოგადად ისინი არც ისე შესამჩნევი იყო Oracle-ის ფონზე. შესაბამისად, იმდროინდელი ინჟინრების უნარები ერთგვარად იყო მიბმული ერთადერთ არჩევანთან, რომელიც არსებობდა.

Oracle DBA-ს უნდა შეეძლოს:

• დააინსტალირეთ Oracle სერვერი სადისტრიბუციო ნაკრებიდან;
• Oracle სერვერის კონფიგურაცია:

• init.ora;
• მსმენელი.ორა;

- შექმნა:

• მაგიდის ფართები;
• სქემა;
• მომხმარებლები;

- შეასრულეთ სარეზერვო და აღდგენა;
- განახორციელოს მონიტორინგი;
- გაუმკლავდეთ არაოპტიმალურ მოთხოვნებს.

ამავდროულად, არ იყო სპეციალური მოთხოვნა Oracle DBA-სგან:

• შეძლოს მონაცემთა შენახვისა და დამუშავების ოპტიმალური DBMS ან სხვა ტექნოლოგიის არჩევა;
• უზრუნველყოს მაღალი ხელმისაწვდომობა და ჰორიზონტალური მასშტაბურობა (ეს ყოველთვის არ იყო DBA საკითხი);
• საგნის, ინფრასტრუქტურის, აპლიკაციის არქიტექტურის, ოპერაციული სისტემის კარგი ცოდნა;
• მონაცემთა ჩატვირთვა და გადმოტვირთვა, მონაცემთა მიგრაცია სხვადასხვა DBMS-ებს შორის.

ზოგადად, თუ ვისაუბრებთ იმ დღეებში არჩევანზე, ეს წააგავს არჩევანს საბჭოთა მაღაზიაში 80-იანი წლების ბოლოს:

ჩვენი დრო

მას შემდეგ, რა თქმა უნდა, ხეები გაიზარდა, სამყარო შეიცვალა და გახდა მსგავსი:

DBMS ბაზარი ასევე შეიცვალა, როგორც აშკარად ჩანს Gartner-ის უახლესი ანგარიშიდან:

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

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

Ახლა რა?

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

არჩევანის კითხვებთან ერთად არის ასევე შემზღუდველი ფაქტორები:

• ფასი. ბევრი ტექნოლოგია ჯერ კიდევ ფული ღირს;
• უნარები. თუ ვსაუბრობთ თავისუფალ პროგრამულ უზრუნველყოფაზე, მაშინ ჩნდება უნარების საკითხი, ვინაიდან თავისუფალი პროგრამული უზრუნველყოფა მოითხოვს საკმარის კომპეტენციას იმ ადამიანებისგან, ვინც მას ავრცელებს და ახორციელებს მას;
• ფუნქციური. ყველა სერვისს, რომელიც ხელმისაწვდომია ღრუბელში და აშენებულია, ვთქვათ, იმავე Postgres-ზეც კი, არ აქვს იგივე ფუნქციები, როგორც Postgres On-premises. ეს არის მნიშვნელოვანი ფაქტორი, რომელიც უნდა ვიცოდეთ და გავიგოთ. უფრო მეტიც, ეს ფაქტორი უფრო მნიშვნელოვანი ხდება, ვიდრე ერთი DBMS-ის ზოგიერთი ფარული შესაძლებლობების ცოდნა.

რა არის მოსალოდნელი DA/DE-სგან ახლა:

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

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

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

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

სულ:

1. რაც უფრო წინ მიდიხართ, მით უფრო აქტუალური ხდება არჩევანის საკითხი. და მაშინაც კი, თუ მხოლოდ GCP-ს, მართულ სერვისებს და SaaS-ს უყურებთ, მაშინ RDBMS-ის ზოგიერთი ხსენება მხოლოდ მე-4 საფეხურზე გამოჩნდება (და იქ Spanner არის ახლოს). გარდა ამისა, მე-5 საფეხურზე ჩნდება PostgreSQL-ის არჩევანი და მის გვერდით არის ასევე MySQL და SQL Server, ანუ ყველაფერი ბევრია, მაგრამ თქვენ უნდა აირჩიოთ.
2. არ უნდა დავივიწყოთ შეზღუდვები ცდუნების ფონზე. ძირითადად ყველას უნდა სპანერი, მაგრამ ეს ძვირია. შედეგად, ტიპიური მოთხოვნა ასე გამოიყურება: „გთხოვთ, გაგვაჩინეთ Spanner, მაგრამ Cloud SQL-ის ფასად, თქვენ პროფესიონალები ხართ!

Რა უნდა გავაკეთოთ?

საბოლოო ჭეშმარიტებაზე პრეტენზიის გარეშე, მოდით ვთქვათ შემდეგი:

ჩვენ უნდა შევცვალოთ სწავლისადმი მიდგომა:

• აზრი არ აქვს სწავლებას ისე, როგორც ადრე სწავლობდნენ DBA-ებს;
• ერთი პროდუქტის ცოდნა აღარ არის საკმარისი;
• მაგრამ ერთის დონეზე ათეულების ცოდნა შეუძლებელია.

თქვენ უნდა იცოდეთ არა მხოლოდ და არა რამდენად არის პროდუქტი, არამედ:

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

თქვენ ასევე უნდა გქონდეთ მონაცემების მიგრაცია და გაიგოთ ETL-თან ინტეგრაციის ძირითადი პრინციპები.

რეალური შემთხვევა

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

• CI/CD აშენება;
• არქიტექტურის მიმოხილვა;
• ამოქმედდეს ეს ყველაფერი.

თავად აპლიკაცია იყო მიკროსერვისები, ხოლო Python/Django კოდი შეიქმნა ნულიდან და პირდაპირ GCP-ში. რაც შეეხება სამიზნე აუდიტორიას, ვარაუდობდნენ, რომ იქნებოდა ორი რეგიონი - აშშ და ევროკავშირი და ტრაფიკი ნაწილდებოდა გლობალური დატვირთვის ბალანსერით. ყველა დატვირთვა და გამოთვლითი დატვირთვა გაშვებული იყო Google Kubernetes Engine-ზე.

რაც შეეხება მონაცემებს, იყო 3 სტრუქტურა:

• ღრუბლოვანი საცავი;
• მონაცემთა მაღაზია;
• Cloud SQL (PostgreSQL).

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

რაც შეეხება ჩვენს შემთხვევას, Cloud SQL შეირჩა შემდეგი მიზეზების გამო:

1. როგორც აღვნიშნეთ, აპლიკაცია შემუშავდა Django-ს გამოყენებით და მას აქვს მოდელი SQL მონაცემთა ბაზიდან Python-ის ობიექტებზე მუდმივი მონაცემების შესატანად (Django ORM).
2. თავად ჩარჩო მხარს უჭერდა DBMS-ების საკმაოდ სასრულ ჩამონათვალს:

• PostgreSQL;
• MariaDB;
• MySQL
• ორაკულები;
• SQLite.

შესაბამისად, PostgreSQL აირჩიეს ამ სიიდან საკმაოდ ინტუიციურად (კარგად, Oracle-ის არჩევა ნამდვილად არ არის).

რა აკლდა:

• აპლიკაცია განთავსდა მხოლოდ 2 რეგიონში, ხოლო მესამე გამოჩნდა გეგმებში (აზია);
• მონაცემთა ბაზა მდებარეობდა ჩრდილოეთ ამერიკის რეგიონში (აიოვა);
• მომხმარებლის მხრიდან იყო შეშფოთება შესაძლო წვდომის შეფერხებები ევროპიდან და აზიიდან და შეფერხებები სამსახურში DBMS შეფერხების შემთხვევაში.

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

სირთულე ის იყო, რომ მომხმარებელს არ სურდა უარი ეთქვა მართული სერვისებისა და Cloud SQL-ის გამოყენებაზე. და Cloud SQL-ის შესაძლებლობები ამჟამად შეზღუდულია. Cloud SQL მხარს უჭერს მაღალი ხელმისაწვდომობის (HA) და Read Replica (RR), მაგრამ იგივე RR მხარდაჭერილია მხოლოდ ერთ რეგიონში. ამერიკის რეგიონში მონაცემთა ბაზის შექმნის შემდეგ, თქვენ ვერ გააკეთებთ წაკითხულ რეპლიკას ევროპის რეგიონში Cloud SQL-ის გამოყენებით, თუმცა თავად Postgres არ გიშლით ხელს ამის გაკეთებაში. Google-ის თანამშრომლებთან მიმოწერა არსად მიგვიყვანდა და მთავრდებოდა დაპირებებით „ჩვენ ვიცით პრობლემა და ვმუშაობთ მასზე, ოდესმე ეს საკითხი მოგვარდება“.

თუ მოკლედ ჩამოვთვლით Cloud SQL-ის შესაძლებლობებს, ის ასე გამოიყურება:

1. მაღალი ხელმისაწვდომობა (HA):

• ერთი რეგიონის ფარგლებში;
• დისკის რეპლიკაციის საშუალებით;
• PostgreSQL ძრავები არ გამოიყენება;
• შესაძლებელია ავტომატური და ხელით კონტროლი - failover/failback;
• გადართვისას, DBMS მიუწვდომელია რამდენიმე წუთის განმავლობაში.

2. წაიკითხეთ რეპლიკა (RR):

• ერთი რეგიონის ფარგლებში;
• ცხელი ლოდინი;
• PostgreSQL ნაკადის რეპლიკაცია.

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

• მომხმარებელს არ სურდა ერთეულების შექმნა და IaaS-ის გამოყენება, გარდა GKE-ის მეშვეობით;
• მომხმარებელს არ სურს განათავსოს თვითმომსახურება PostgreSQL/MySQL;
• ზოგადად, Google Spanner საკმაოდ შესაფერისი იქნებოდა, რომ არა მისი ფასი, თუმცა Django ORM ვერ იმუშავებს, მაგრამ ეს კარგია.

სიტუაციის გათვალისწინებით, მომხმარებელმა მიიღო შემდეგი შეკითხვა: „შეგიძლიათ გააკეთოთ მსგავსი რამ ისე, რომ ის იყოს Google Spanner-ის მსგავსი, მაგრამ ასევე იმუშაოს Django ORM-თან?

გადაწყვეტის ვარიანტი No0

პირველი რაც გამახსენდა:

• დარჩით CloudSQL-ში;
• არ იქნება ჩაშენებული რეპლიკაცია რეგიონებს შორის რაიმე ფორმით;
• შეეცადეთ მიამაგროთ რეპლიკა არსებულ Cloud SQL-ზე PostgreSQL-ის მიერ;
• გაუშვით PostgreSQL ინსტანცია სადმე და როგორმე, მაგრამ მაინც ნუ შეეხებით მასტერს.

სამწუხაროდ, აღმოჩნდა, რომ ამის გაკეთება შეუძლებელია, რადგან არ არის წვდომა ჰოსტზე (ის სულ სხვა პროექტშია) - pg_hba და ასე შემდეგ, ასევე არ არის წვდომა სუპერმომხმარებლის ქვეშ.

გადაწყვეტის ვარიანტი No1

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

• ჩვენ კვლავ ვცდილობთ დარჩეს CloudSQL-ში, მაგრამ გადავდივართ MySQL-ზე, რადგან MySQL-ის Cloud SQL-ს აქვს გარე მასტერი, რომელიც:

— არის გარე MySQL-ის პროქსი;
- ჰგავს MySQL მაგალითს;
- გამოიგონეს მონაცემების სხვა ღრუბლებიდან ან შიდა შენობაში გადასატანად.

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

სინამდვილეში, ამ ეტაპზე გაირკვა, რომ Cloud SQL საერთოდ არ არის შესაფერისი. როგორც ამბობენ, ყველაფერი გავაკეთეთ, რაც შეგვეძლო.

გადაწყვეტის ვარიანტი No2

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

• მუშაობა Kubernetes-ში, Kubernetes-ის (DCS, ...) და GCP (LB, ...) რესურსებისა და შესაძლებლობების მაქსიმალური გამოყენება;
• ბალასტის ნაკლებობა ღრუბელში არასაჭირო ნივთებისგან, როგორიცაა HA პროქსი;
• PostgreSQL ან MySQL HA მთავარ რეგიონში გაშვების შესაძლებლობა; სხვა რეგიონებში - HA მთავარი რეგიონის RR-დან პლუს მისი ასლი (სანდოობისთვის);
• multi master (არ მინდოდა მასთან დაკავშირება, მაგრამ ეს არ იყო ძალიან მნიშვნელოვანი)

.
ამ მოთხოვნების შედეგად პშესაფერისი DBMS და სავალდებულო პარამეტრები:

• MySQL Galera;
• ტარაკანიDB;
• PostgreSQL ინსტრუმენტები

:
- pgpool-II;
- პატრონი.

MySQL Galera

MySQL Galera ტექნოლოგია შეიქმნა Codership-ის მიერ და არის მოდული InnoDB-სთვის. თავისებურებები:

• მრავალ ოსტატი;
• სინქრონული რეპლიკაცია;
• ნებისმიერი კვანძიდან კითხვა;
• ჩაწერა ნებისმიერ კვანძზე;
• ჩაშენებული HA მექანიზმი;
• არსებობს Helm ჩარტი Bitnami-დან.

ტარაკანი DB

აღწერილობის მიხედვით, ნივთი არის აბსოლუტურად ბომბი და არის Go-ში დაწერილი ღია კოდის პროექტი. მთავარი მონაწილე არის Cockroach Labs (დაარსებული Google-ის ხალხის მიერ). ეს რელაციური DBMS თავდაპირველად შექმნილი იყო დისტრიბუციული (ჰორიზონტალური სკალირების გარეშე) და შეცდომის ტოლერანტობისთვის. კომპანიის ავტორებმა გამოკვეთეს მიზანი "SQL ფუნქციონალობის სიმდიდრის გაერთიანება NoSQL გადაწყვეტილებებისთვის ნაცნობ ჰორიზონტალურ ხელმისაწვდომობასთან".

კარგი ბონუსი არის პოსტ-გრესი კავშირის პროტოკოლის მხარდაჭერა.

pgpool

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

პატრონი

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

ბოლოს რა აირჩიე?

არჩევანი ადვილი არ იყო:

1. ტარაკანი DB - ცეცხლი, მაგრამ ბნელი;
2. MySQL Galera - ასევე ცუდი არ არის, ბევრგან გამოიყენება, მაგრამ MySQL;
3. pgpool - ბევრი არასაჭირო ობიექტი, ასე რომ ინტეგრაცია ღრუბელთან და K8-ებთან;
4. პატრონი - შესანიშნავი ინტეგრაცია K8-ებთან, არასაჭირო ერთეულების გარეშე, კარგად ინტეგრირდება GCP LB-თან.

ამრიგად, არჩევანი პატრონზე შეჩერდა.

დასკვნები

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

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

წყარო: www.habr.com