DBA ბოტი ჯო. ანატოლი სტენსლერი (Postgres.ai)

როგორ ესმის backend-ის დეველოპერი, რომ SQL მოთხოვნა კარგად იმუშავებს „პროდზე“? დიდ ან სწრაფად მზარდ კომპანიებში ყველას არ აქვს წვდომა „პროდუქტზე“. და წვდომით, ყველა მოთხოვნა არ შეიძლება უმტკივნეულოდ შემოწმდეს და მონაცემთა ბაზის ასლის შექმნას ხშირად საათები სჭირდება. ამ პრობლემების გადასაჭრელად შევქმენით ხელოვნური DBA – ჯო. ის უკვე წარმატებით იქნა დანერგილი რამდენიმე კომპანიაში და ეხმარება ათზე მეტ დეველოპერს.

ვიდეო:

Სალამი ყველას! მე მქვია ანატოლი სტენსლერი. ვმუშაობ კომპანიაში პოსტგრესი.აი. ჩვენ მზად ვართ დავაჩქაროთ განვითარების პროცესი Postgres-ის მუშაობასთან დაკავშირებული შეფერხებების მოხსნით დეველოპერებისგან, DBA-ებიდან და QA-ებიდან.

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

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

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

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

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

მტკივა, ძვირია. ალბათ ჯობია არა.

და რა არის ამის საუკეთესო გზა?

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

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

რა პრობლემებია?

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

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

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

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

ვის აქვს მონაცემთა ბაზა ტერაბაიტზე დიდი? ოთახის ნახევარზე მეტი.

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

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

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

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

რა ვქნათ აქ? მოდით გავხადოთ სატესტო სკამი იაფი და მივცეთ ყველა დეველოპერს საკუთარი სატესტო სკამი.

და ეს შესაძლებელია.

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

რეალური მაგალითი:

• DB - 4,5 ტერაბაიტი.

• ჩვენ შეგვიძლია მივიღოთ დამოუკიდებელი ასლები 30 წამში.

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

Მაგარია. აქ საუბარია მაგიაზე და პარალელურ სამყაროზე.

ჩვენს შემთხვევაში, ეს მუშაობს OpenZFS სისტემის გამოყენებით.

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

არის სხვა ვარიანტებიც:

• lvm,

• შენახვა (მაგალითად, Pure Storage).

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

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

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

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

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

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

• პირველი არის მონაცემთა წყარო, საიდანაც მას აიღებთ. თქვენ შეგიძლიათ დააყენოთ რეპლიკაცია წარმოებასთან ერთად. თქვენ უკვე შეგიძლიათ გამოიყენოთ სარეზერვო ასლები, რომლებიც დააკონფიგურირეთ, იმედი მაქვს. WAL-E, WAL-G ან Barman. და მაშინაც კი, თუ იყენებთ რაიმე სახის Cloud გადაწყვეტას, როგორიცაა RDS ან Cloud SQL, შეგიძლიათ გამოიყენოთ ლოგიკური ნაგავსაყრელები. მაგრამ ჩვენ მაინც გირჩევთ გამოიყენოთ სარეზერვო ასლები, რადგან ამ მიდგომით თქვენ ასევე შეინარჩუნებთ ფაილების ფიზიკურ სტრუქტურას, რაც საშუალებას მოგცემთ იყოთ უფრო ახლოს იმ მეტრიკებთან, რომლებსაც წარმოებისას ნახავთ, რათა დაიჭიროთ არსებული პრობლემები.

• მეორე არის ის, სადაც გსურთ მონაცემთა ბაზის ლაბორატორიის მასპინძლობა. ეს შეიძლება იყოს Cloud, ეს შეიძლება იყოს On-premise. აქ მნიშვნელოვანია იმის თქმა, რომ ZFS მხარს უჭერს მონაცემთა შეკუმშვას. და ამას საკმაოდ კარგად აკეთებს.

წარმოიდგინეთ, რომ თითოეული ასეთი კლონისთვის, იმის მიხედვით, თუ რა ოპერაციებს ვაკეთებთ ბაზასთან, გაიზრდება რაიმე სახის დევი. ამისთვის Dev-ს ასევე დასჭირდება სივრცე. მაგრამ იმის გამო, რომ ჩვენ ავიღეთ ბაზა 4,5 ტერაბაიტი, ZFS შეკუმშავს მას 3,5 ტერაბაიტამდე. ეს შეიძლება განსხვავდებოდეს პარამეტრების მიხედვით. და ჩვენ ჯერ კიდევ გვაქვს ადგილი დეველოპერებისთვის.

ასეთი სისტემა შეიძლება გამოყენებულ იქნას სხვადასხვა შემთხვევისთვის.

• ესენი არიან დეველოპერები, DBA შეკითხვის ვალიდაციისთვის, ოპტიმიზაციისთვის.

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

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

ამ მიდგომით:

1. შეცდომების დაბალი ალბათობა "პროდზე", რადგან ჩვენ ყველა ცვლილება შევამოწმეთ სრული ზომის მონაცემებზე.

2. ჩვენ გვაქვს ტესტირების კულტურა, რადგან ახლა თქვენ არ გჭირდებათ საათობით ელოდოთ საკუთარ სტენდს.

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

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

• ჩვენ შეგვიძლია შევაბრუნოთ შეუქცევადი ცვლილებები. ეს არ არის სტანდარტული მიდგომა.

1. ეს მომგებიანია, რადგან ჩვენ ვიზიარებთ საგამოცდო სკამების რესურსებს.

უკვე კარგია, მაგრამ კიდევ რისი დაჩქარება შეიძლება?

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

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

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

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

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

და ასევე Slack გვაძლევს შესაძლებლობებს თანამშრომლობისთვის. ვინაიდან ეს მხოლოდ არხია, შეგიძლიათ დაიწყოთ ამ მოთხოვნის განხილვა სწორედ იქ, თემაში ასეთი მოთხოვნისთვის, პინგი თქვენს კოლეგებს, DBA-ებს, რომლებიც კომპანიის შიგნით არიან.

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

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

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

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

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

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

და მეორე ქეში იყენებს მთელ ხელმისაწვდომ ადგილს.

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

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

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

მაგალითად, თუ ჩვენ გვაქვს დიდი ქეში პროდზე, მაშინ Postgres ურჩევნია გამოიყენოს ინდექსი. და თუ არა, მაშინ იქნება SeqScan. და რა აზრი ექნება, ჩვენი გეგმები რომ არ დაემთხვა?

მაგრამ აქ მივდივართ დასკვნამდე, რომ რეალურად გეგმა Postgres-ში არ არის დამოკიდებული გეგმის Shared Buffer-ში მითითებულ კონკრეტულ ზომაზე, ეს დამოკიდებულია effect_cache_size-ზე.

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

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

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

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

• ეს დამოკიდებულია თავად აპარატის მახასიათებლებზე.

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

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

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

ავიღოთ მოთხოვნა რეალური სისტემისგან. ამ შემთხვევაში მონაცემთა ბაზა არის 1 ტერაბაიტი. და ჩვენ გვინდა დავთვალოთ ახალი პოსტების რაოდენობა, რომლებსაც ჰქონდათ 10-ზე მეტი მოწონება.

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

B Joe გაჩვენებთ ავტომატურ რეკომენდაციებს გეგმისა და მეტრიკის საფუძველზე.

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

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

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

და ეს მოხდა გეგმაში იმის გამო, რომ მოთხოვნების პირობები და ინდექსში პირობები ნაწილობრივ არ ემთხვევა.

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

ინდექსის შექმნას საკმაოდ დიდი დრო დასჭირდა, მაგრამ ახლა ჩვენ ვამოწმებთ შეკითხვას და ვხედავთ, რომ დრო 2,5 წუთის ნაცვლად მხოლოდ 156 მილიწამია, რაც საკმარისად კარგია. და ჩვენ ვკითხულობთ მხოლოდ 6 მეგაბაიტიან მონაცემს.

და ახლა ჩვენ ვიყენებთ მხოლოდ ინდექსის სკანირებას.

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

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

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

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

და დეველოპერები, რომლებიც ჯერ არ ჩაუვლიათ ამ თემას, ასევე სარგებლობენ shpjegim.depesz.com-ით, რადგან მათთვის უფრო ადვილია იმის გარკვევა, თუ რომელი მეტრიკაა მნიშვნელოვანი და რომელი არა.

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

თანამშრომლობა

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

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

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

აი აქ ვამთავრებ. Გმადლობთ!

კითხვები

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

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

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

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

თითოეული კლონისთვის არის გარკვეული ttl. ძირითადად, ჩვენ გვაქვს ფიქსირებული ttl.

რა, თუ საიდუმლო არა?

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

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

რა არის ZFS-ის მთავარი პრობლემა? ის ფაქტი, რომ თქვენ უნდა იმუშაოთ იმავე ჰოსტზე, ანუ ყველა ინსტანცია იცხოვრებს იმავე OS-ში. შენახვის შემთხვევაში კი შეგიძლიათ დააკავშიროთ სხვადასხვა აღჭურვილობა. და bottleneck არის მხოლოდ ის ბლოკები, რომლებიც ინახება შენახვის სისტემაში. და საინტერესოა ტექნოლოგიების არჩევის საკითხი. რატომ არა LVM?

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

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

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

მაგრამ ZFS ყველასთვის ხელმისაწვდომია. DelPhix უკვე საკმარისია, მათ ჰყავთ 300 კლიენტი. აქედან Fortune 100-ს ჰყავს 50 კლიენტი, ანუ ისინი გამიზნულია NASA-ზე და ა.შ. დროა ყველამ მიიღოს ეს ტექნოლოგია. და ამიტომ გვაქვს ღია კოდის Core. ჩვენ გვაქვს ინტერფეისის ნაწილი, რომელიც არ არის ღია წყარო. ეს არის პლატფორმა, რომელსაც ჩვენ ვაჩვენებთ. მაგრამ ჩვენ გვინდა, რომ ის ყველასთვის ხელმისაწვდომი იყოს. ჩვენ გვინდა რევოლუცია მოვახდინოთ ისე, რომ ყველა ტესტერმა შეწყვიტოს ლეპტოპებზე გამოცნობა. უნდა დავწეროთ SELECT და მაშინვე დავინახოთ, რომ ნელია. შეწყვიტეთ ლოდინი DBA-ს გეტყვით ამის შესახებ. აქ არის მთავარი მიზანი. და მე ვფიქრობ, რომ ჩვენ ყველა მივალთ ამას. და ჩვენ ვაკეთებთ ამ ნივთს ყველასთვის. ამიტომ ZFS, რადგან ის ყველგან იქნება ხელმისაწვდომი. მადლობა საზოგადოებას პრობლემების გადაჭრისთვის და ღია კოდის ლიცენზიისთვის და ა.შ.*

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

და მეორე შეკითხვა ეხება სტენდების განსხვავებულობას. ვთქვათ, მე მაქვს ZFS აქ და ყველაფერი მაგარია, მაგრამ კლიენტს prod-ზე არა აქვს ZFS, არამედ ext4, მაგალითად. როგორ ამ შემთხვევაში?

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

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

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

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

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

მაგრამ რადგან სისტემა გაფართოებულია, ის ასევე შეიძლება გამოყენებულ იქნას MySQL-სთვის. და არის ასეთი მაგალითები. Yandex-ს აქვს მსგავსი რამ, მაგრამ არსად არ აქვეყნებენ. ისინი იყენებენ Yandex.Metrica-ს შიგნით. და არის მხოლოდ ამბავი MySQL-ის შესახებ. მაგრამ ტექნოლოგიები იგივეა, ZFS.

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

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

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

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

ინდექსი შეიქმნება ყოველ ჯერზე?

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

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

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

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

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

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

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

წინა ფენებიდან, რომლებიც წინა რეპლიკაციებიდან იყო.

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

ზოგადად, დიახ.

შემდეგ შედეგად გვექნება ფენების ლეღვამდე. და დროთა განმავლობაში მათი შეკუმშვა დასჭირდება?

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

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

ასეა. მაგალითად, ჩვენ შეგვიძლია დავწეროთ: "SELECT FROM WHERE ელფოსტა = რომ". ანუ ჩვენ თვითონ ვერ დავინახავთ მონაცემებს, მაგრამ შეგვიძლია დავინახოთ რაღაც არაპირდაპირი ნიშნები. ეს უნდა გაიგოს. მაგრამ მეორეს მხრივ, ეს ყველაფერი იქ არის. ჩვენ გვაქვს ჟურნალის აუდიტი, ჩვენ გვაქვს კონტროლი სხვა კოლეგებზე, რომლებიც ასევე ხედავენ რას აკეთებენ დეველოპერები. და თუ ვინმე შეეცდება ამის გაკეთებას, მაშინ უსაფრთხოების სამსახური მოვა მათთან და იმუშავებს ამ საკითხზე.

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

ახლა არის Slack-ის ბმული, ანუ სხვა მესინჯერი არ არის, მაგრამ მე ნამდვილად მინდა მხარდაჭერა სხვა მესინჯერებისთვისაც. Რა შეგიძლია? შეგიძლიათ განათავსოთ DB Lab ჯოს გარეშე, წახვიდეთ REST API-ს ან ჩვენი პლატფორმის დახმარებით და შექმნათ კლონები და დაუკავშირდეთ PSQL-ს. მაგრამ ეს შეიძლება გაკეთდეს, თუ მზად ხართ თქვენს დეველოპერებს მისცეთ წვდომა მონაცემებზე, რადგან ეკრანი აღარ იქნება.

მე არ მჭირდება ეს ფენა, მაგრამ მჭირდება ასეთი შესაძლებლობა.

მაშინ დიახ, ეს შეიძლება გაკეთდეს.

წყარო: www.habr.com