Google Cloud Spanner: კარგი, ცუდი, მახინჯი

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

თავდაპირველად გამოქვეყნდა ქ Lightspeed HQ ბლოგი.

როგორც კომპანია, რომელიც სთავაზობს ღრუბელზე დაფუძნებულ POS-ის მრავალფეროვან გადაწყვეტილებებს საცალო ვაჭრობისთვის, რესტავრატორებისთვის და ონლაინ გამყიდველებისთვის მთელს მსოფლიოში, Lightspeed იყენებს რამდენიმე სხვადასხვა ტიპის მონაცემთა ბაზის პლატფორმას ტრანზაქციის, ანალიტიკური და საძიებო გამოყენების შემთხვევებისთვის. თითოეულ ამ მონაცემთა ბაზის პლატფორმას აქვს თავისი ძლიერი და სუსტი მხარეები. ამიტომ, როდესაც Google-მა წარადგინა Cloud Spanner ბაზარზე - პერსპექტიული ფუნქციები, რომლებიც არ ჩანს რელაციური მონაცემთა ბაზების სამყაროში, როგორიცაა პრაქტიკულად შეუზღუდავი ჰორიზონტალური მასშტაბირება და 99,999% სერვისის დონის შეთანხმება (SLA), — ჩვენ ხელიდან არ გავუშვით შესაძლებლობა!

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

1. ჩვენი შეფასების კრიტერიუმები
2. Cloud Spanner მოკლედ
3. ჩვენი შეფასება
4. ჩვენი დასკვნები

1. ჩვენი შეფასების კრიტერიუმები

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

• როგორც ჩანაცვლება (უპირატესი) ტრადიციული SQL მონაცემთა ბაზის გადაწყვეტისთვის
• როგორ მივიღოთ OLTP გადაწყვეტა OLAP მხარდაჭერით

შენიშვნა: სიმარტივისა და შედარებისთვის, ეს სტატია ადარებს Cloud Spanner-ს GCP Cloud SQL და Amazon AWS RDS გადაწყვეტილებების ოჯახების MySQL ვარიანტებთან.

Cloud Spanner-ის გამოყენება ტრადიციული SQL მონაცემთა ბაზის გადაწყვეტის შემცვლელად

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

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

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

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

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

მეორეს მხრივ, თავისი ბუნებიდან გამომდინარე, Cloud Spanner ადვილად შეუძლია ჰორიზონტალურად მასშტაბირება მინიმალური ჩარევით.

სრულად გამორჩეული DBMS, როგორც სერვისი უნდა შეფასდეს სხვადასხვა კუთხით. როგორც საფუძველი, ჩვენ ავიღეთ ყველაზე პოპულარული DBMS ღრუბელში - Google-ისთვის, GCP Cloud SQL და Amazon-ისთვის, AWS RDS. ჩვენი შეფასებისას ყურადღება გავამახვილეთ შემდეგ კატეგორიებზე:

• მახასიათებლის რუქა: SQL, DDL, DML გაფართოება; კავშირი ბიბლიოთეკები/კონექტორები, ტრანზაქციის მხარდაჭერა და ა.შ.
• განვითარების მხარდაჭერა: მარტივი განვითარება და ტესტირება.
• ადმინისტრაციის მხარდაჭერა: ინსტანციის მენეჯმენტი - მაგალითად, ინსტანციების გაზრდა/დაწევა და განახლება; SLA, სარეზერვო და აღდგენა; უსაფრთხოება/წვდომის კონტროლი.

Cloud Spanner-ის გამოყენება, როგორც OLAP ჩართული OLTP გადაწყვეტა

მიუხედავად იმისა, რომ Google პირდაპირ არ აცხადებს, რომ Cloud Spanner შექმნილია ანალიტიკური დამუშავებისთვის, ის იზიარებს ზოგიერთ ატრიბუტს სხვა ძრავებთან, როგორიცაა Apache Impala & Kudu და YugaByte, რომლებიც შექმნილია OLAP დატვირთვისთვის.

მაშინაც კი, თუ არსებობდა მხოლოდ მცირე შანსი, რომ Cloud Spanner-მა მოიცავდა თანმიმდევრული მასშტაბური HTAP (ჰიბრიდული ტრანზაქციის/ანალიტიკის დამუშავება) ძრავას (მეტ-ნაკლებად) გამოსაყენებელი OLAP ფუნქციების ნაკრებით, ვფიქრობთ, რომ ეს ჩვენი ყურადღების ღირსი იქნებოდა.

ამის გათვალისწინებით, ჩვენ განვიხილეთ შემდეგი კატეგორიები:

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

2. Cloud Spanner მოკლედ

Google Spanner არის კლასტერული ურთიერთობითი მონაცემთა მართვის სისტემა (RDBMS), რომელსაც Google იყენებს რამდენიმე საკუთარი სერვისისთვის. Google-მა ის ზოგადად ხელმისაწვდომი გახადა Google Cloud Platform-ის მომხმარებლებისთვის 2017 წლის დასაწყისში.

აქ არის Cloud Spanner-ის რამდენიმე ატრიბუტი:

• უაღრესად თანმიმდევრული მასშტაბირებადი RDBMS კლასტერი: იყენებს ტექნიკის დროის სინქრონიზაციას მონაცემთა თანმიმდევრულობის უზრუნველსაყოფად.
• ჯვარედინი ტრანზაქციის მხარდაჭერა: ტრანზაქციებს შეიძლება მოიცავდეს რამდენიმე ცხრილი - არ შემოიფარგლება მხოლოდ ერთი ცხრილით (განსხვავებით Apache HBase ან Apache Kudu-სგან).
• ძირითადი გასაღების დაფუძნებული ცხრილები: ყველა ცხრილს უნდა ჰქონდეს დეკლარირებული პირველადი გასაღები (PC), რომელიც შეიძლება შედგებოდეს ცხრილის რამდენიმე სვეტისგან. ცხრილის მონაცემები ინახება კომპიუტერის თანმიმდევრობით, რაც მას ძალიან ეფექტურს და სწრაფს ხდის კომპიუტერის საძიებლად. კომპიუტერზე დაფუძნებული სხვა სისტემების მსგავსად, განხორციელება უნდა იყოს მოდელირებული წინასწარ შემუშავებული გამოყენების შემთხვევების გათვალისწინებით საუკეთესო შესრულება.
• ზოლიანი მაგიდები: მაგიდებს შეიძლება ჰქონდეთ ფიზიკური დამოკიდებულება ერთმანეთზე. ბავშვის ცხრილის რიგები შეიძლება შეესაბამებოდეს მშობლის ცხრილის რიგებს. ეს მიდგომა აჩქარებს ისეთი ურთიერთობების ძიებას, რომელთა იდენტიფიცირებაც შესაძლებელია მონაცემთა მოდელირების ფაზაში, როგორიცაა კლიენტების თანამონაწილეობა და მათი ინვოისები.
• ინდექსები: Cloud Spanner მხარს უჭერს მეორად ინდექსებს. ინდექსი შედგება ინდექსირებული სვეტებისგან და კომპიუტერის ყველა სვეტისგან. თუ სასურველია, ინდექსი შეიძლება შეიცავდეს სხვა არაინდექსირებულ სვეტებსაც. ინდექსი შეიძლება ჩაერთოს მშობლის ცხრილში, რათა დააჩქაროს მოთხოვნები. ინდექსებზე ვრცელდება რამდენიმე შეზღუდვა, როგორიცაა ინდექსში შენახული დამატებითი სვეტების მაქსიმალური რაოდენობა. ასევე, მოთხოვნები ინდექსების მეშვეობით შეიძლება არ იყოს ისეთი მარტივი, როგორც სხვა RDBMS-ებში.

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

• სერვისის დონის ხელშეკრულება (SLA): განლაგება ერთ რეგიონში SLA 99,99%-ით; მრავალრეგიონული განლაგება 99,999% SLA-ით. მიუხედავად იმისა, რომ SLA თავისთავად არის მხოლოდ შეთანხმება და არა რაიმე სახის გარანტია, მე მჯერა, რომ Google-ის ხალხს აქვს მყარი მონაცემები ასეთი ძლიერი პრეტენზიის გასაკეთებლად. (ცნობისთვის, 99,999% ნიშნავს 26,3 წამის სერვისის მიუწვდომლობას თვეში.)
• სხვა: https://cloud.google.com/spanner/

შენიშვნა: Apache Tephra პროექტი ამატებს ტრანზაქციის გაძლიერებულ მხარდაჭერას Apache HBase-ს (ასევე დანერგილია Apache Phoenix-ში ბეტა სახით).

3. ჩვენი შეფასება

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

ჩვენ შევაფასეთ Cloud Spanner, როგორც Sharded MySQL-ის შემცვლელი

Google Cloud SQL და Amazon AWS RDS, ორი ყველაზე პოპულარული OLTP DBMS ღრუბლოვან ბაზარზე, აქვთ ფუნქციების ძალიან დიდი ნაკრები. ამასთან, ამ მონაცემთა ბაზების ერთი კვანძის ზომის მიღმა გასადიდებლად, თქვენ უნდა შეასრულოთ აპლიკაციის დაყოფა. ეს მიდგომა ქმნის დამატებით სირთულეს როგორც აპლიკაციებისთვის, ასევე ადმინისტრაციისთვის. ჩვენ შევხედეთ, თუ როგორ ჯდება Spanner რამდენიმე ფრაგმენტის ერთ ეგზემპლარად გაერთიანების სცენარში და რა ფუნქციების (ასეთის არსებობის შემთხვევაში) შეწირვა შეიძლება საჭირო გახდეს.

SQL, DML და DDL მხარდაჭერა, ასევე კონექტორი და ბიბლიოთეკები?

პირველ რიგში, ნებისმიერი მონაცემთა ბაზის დაწყებისას, თქვენ უნდა შექმნათ მონაცემთა მოდელი. თუ ფიქრობთ, რომ შეგიძლიათ დააკავშიროთ JDBC Spanner თქვენს საყვარელ SQL ინსტრუმენტთან, აღმოაჩენთ, რომ თქვენ შეგიძლიათ მოიძიოთ თქვენი მონაცემები მისი საშუალებით, მაგრამ არ შეგიძლიათ გამოიყენოთ იგი ცხრილის შესაქმნელად ან შესაცვლელად (DDL) ან რაიმე ჩასართავად/განახლება/წაშლაში. ოპერაციები (DML). Google-ის ოფიციალური JDBC არცერთს არ უჭერს მხარს.

"დრაივერები ამჟამად არ უჭერენ მხარს DML ან DDL განცხადებებს."
სპანერის დოკუმენტაცია

სიტუაცია არ არის უკეთესი GCP კონსოლთან დაკავშირებით - შეგიძლიათ მხოლოდ SELECT მოთხოვნების გაგზავნა. საბედნიეროდ, არსებობს JDBC დრაივერი DML-ისა და DDL-ის მხარდაჭერით საზოგადოებისგან, ტრანზაქციების ჩათვლით github.com/olavloite/spanner-jdbc. მიუხედავად იმისა, რომ ეს დრაივერი ძალიან სასარგებლოა, Google-ის საკუთარი JDBC დრაივერის ნაკლებობა გასაკვირია. საბედნიეროდ, Google გთავაზობთ საკმაოდ ფართო მხარდაჭერას კლიენტების ბიბლიოთეკებისთვის (gRPC-ზე დაყრდნობით): C#, Go, Java, node.js, PHP, Python და Ruby.

Cloud Spanner მორგებული API-ების თითქმის სავალდებულო გამოყენება (JDBC-ში DDL-ისა და DML-ის არარსებობის გამო) იწვევს გარკვეულ შეზღუდვებს შესაბამისი კოდის სფეროებისთვის, როგორიცაა კავშირის პულები ან მონაცემთა ბაზის სავალდებულო ჩარჩოები (მაგ. Spring MVC). როგორც წესი, JDBC-ის გამოყენებისას თქვენ თავისუფლად შეგიძლიათ აირჩიოთ თქვენი საყვარელი კავშირის აუზი (მაგ. HikariCP, DBCP, C3PO და ა.შ.), რომელიც გამოცდილია და კარგად მუშაობს. მორგებული Spanner API-ების შემთხვევაში, ჩვენ უნდა დავეყრდნოთ ჩარჩოებს/სავალდებულო აუზებს/სესიებს, რომლებიც ჩვენ თვითონ შევქმენით.

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

• თქვენ არ შეგიძლიათ განაახლოთ პირველადი გასაღების მნიშვნელობა; ჯერ უნდა წაშალოთ ჩანაწერი ორიგინალური კომპიუტერიდან და ხელახლა ჩასვათ ახალი მნიშვნელობით. (ეს მსგავსია სხვა კომპიუტერზე ორიენტირებული მონაცემთა ბაზის/შენახვის ძრავებთან.)
• ნებისმიერ განახლების და DELETE განცხადებებში WHERE-ში უნდა იყოს მითითებული PC, ამიტომ არ შეიძლება იყოს ცარიელი DELETE ყველა განცხადება - ყოველთვის უნდა იყოს ქვემოთხოვნა, მაგალითად: განაახლეთ xxx WHERE id IN (SELECT id FROM table1)
• ავტომატური გაზრდის ოფციის ნაკლებობა ან რაიმე მსგავსი, რომელიც ადგენს კომპიუტერის ველის თანმიმდევრობას. იმისათვის, რომ ეს იმუშაოს, შესაბამისი მნიშვნელობა უნდა შეიქმნას განაცხადის მხარეს.

მეორადი ინდექსები?

Google Cloud Spanner-ს აქვს ჩაშენებული მხარდაჭერა მეორადი ინდექსებისთვის. ეს არის ძალიან კარგი ფუნქცია, რომელიც ყოველთვის არ არის წარმოდგენილი სხვა ტექნოლოგიებში. Apache Kudu ამჟამად საერთოდ არ უჭერს მხარს მეორად ინდექსებს და Apache HBase არ უჭერს მხარს ინდექსებს პირდაპირ, მაგრამ შეუძლია მათი დამატება Apache Phoenix-ის საშუალებით.

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

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

წარმომადგენლობა?

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

იხილეთ Cloud Spanner დოკუმენტაცია განყოფილებისთვის, რომელიც დეტალურადაა კვოტები და შეზღუდვები (ქუდი/კვოტები), არის ერთი, რომელიც შეიძლება იყოს პრობლემური ზოგიერთი აპლიკაციისთვის: Cloud Spanner out of box-ს აქვს მაქსიმუმ 100 მონაცემთა ბაზის ლიმიტი თითო მაგალითზე. ცხადია, ეს შეიძლება იყოს ძირითადი დაბრკოლება მონაცემთა ბაზისთვის, რომელიც შექმნილია 100-ზე მეტი მონაცემთა ბაზისთვის. საბედნიეროდ, Google-ის ჩვენს ტექნიკურ წარმომადგენელთან საუბრის შემდეგ, აღმოვაჩინეთ, რომ ეს ლიმიტი შეიძლება გაიზარდოს თითქმის ნებისმიერ მნიშვნელობამდე Google Support-ის მეშვეობით.

განვითარების მხარდაჭერა?

Cloud Spanner გთავაზობთ საკმაოდ ღირსეულ პროგრამირების ენის მხარდაჭერას თავის API-სთან მუშაობისთვის. ოფიციალურად მხარდაჭერილი ბიბლიოთეკები არის C#, Go, Java, node.js, PHP, Python და Ruby სფეროებში. დოკუმენტაცია საკმაოდ დეტალურია, მაგრამ როგორც სხვა მოწინავე ტექნოლოგიების შემთხვევაში, საზოგადოება საკმაოდ მცირეა მონაცემთა ბაზის ყველაზე პოპულარულ ტექნოლოგიებთან შედარებით, რამაც შეიძლება გამოიწვიოს უფრო მეტი დრო დახარჯოს ნაკლებად გავრცელებული შემთხვევების ან პრობლემების გადაჭრაზე.

რაც შეეხება ადგილობრივი განვითარების მხარდაჭერას?

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

ადმინისტრაციის მხარდაჭერა?

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

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

რესურსებზე წვდომა?

MySQL გთავაზობთ ფართო და ძალიან მარცვლოვან პარამეტრებს მომხმარებლის ნებართვებისთვის/როლებისთვის. თქვენ შეგიძლიათ მარტივად დააკონფიგურიროთ წვდომა კონკრეტულ ცხრილზე, ან თუნდაც მხოლოდ მისი სვეტების ქვეჯგუფზე. Cloud Spanner იყენებს Google-ის Identity & Access Management (IAM) ხელსაწყოს, რომელიც მხოლოდ საშუალებას გაძლევთ დააყენოთ წესები და ნებართვები ძალიან მაღალ დონეზე. ყველაზე მარცვლოვანი ვარიანტია მონაცემთა ბაზის დონის გარჩევადობა, რომელიც არ ჯდება წარმოების გამოყენების უმეტეს შემთხვევებში. ეს შეზღუდვა გაიძულებთ, დაამატოთ დამატებითი უსაფრთხოების ზომები თქვენს კოდს, ინფრასტრუქტურას ან ორივეს, რათა თავიდან აიცილოთ Spanner რესურსების არაავტორიზებული გამოყენება.

სარეზერვო ასლები?

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

შეკითხვის შესრულება?

ჩვენ გამოვიყენეთ Yahoo! მონაცემების ჩასატვირთად და მოთხოვნების შესამოწმებლად. Cloud Serving Benchmark. ქვემოთ მოყვანილი ცხრილი გვიჩვენებს YCSB დატვირთვას B 95% წაკითხვის და 5% ჩაწერის თანაფარდობით.

* ჩატვირთვის ტესტი ჩატარდა n1-სტანდარტის 32 გამოთვლით ძრავზე (CE) (32 vCPU, 120 GB მეხსიერება) და ტესტის მაგალითი არასოდეს ყოფილა საცობები ტესტებში.
** ძაფების მაქსიმალური რაოდენობა ერთ YCSB ინსტანციაში არის 400. სულ 2400 თემის მისაღებად YCSB ტესტების ექვსი პარალელური ინსტანცია უნდა გაშვებულიყო.

თუ გადავხედავთ საორიენტაციო შედეგებს, განსაკუთრებით CPU დატვირთვისა და TPS-ის კომბინაციას, ჩვენ ნათლად დავინახავთ, რომ Cloud Spanner საკმაოდ კარგად მასშტაბებს. ძაფების დიდი რაოდენობით შექმნილი მძიმე დატვირთვა კომპენსირდება Cloud Spanner კლასტერში კვანძების დიდი რაოდენობით. მიუხედავად იმისა, რომ შეყოვნება საკმაოდ მაღალი ჩანს, განსაკუთრებით 2400 ძაფით მუშაობისას, შესაძლოა საჭირო გახდეს გამოთვლითი ძრავის 6 პატარა ინსტანციის ხელახალი ტესტირება უფრო ზუსტი რიცხვების მისაღებად. თითოეული ინსტანცია ჩაატარებს ერთ YCSB ტესტს ერთი დიდი CE ინსტანციის ნაცვლად 6 პარალელური ტესტით. ამგვარად, გაგიადვილდებათ Cloud Spanner-ის მოთხოვნის შეყოვნება და შეყოვნება, რომელიც დამატებულია ქსელური კავშირით Cloud Spanner-სა და ტესტის გაშვებულ CE მაგალითს შორის.

როგორ მუშაობს Cloud Spanner, როგორც OLAP?

დაყოფა?

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

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

იტვირთება მონაცემები?

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

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

მონაცემთა ეს ჩატვირთვა იყენებს Cloud Spanner-ის ყველა კვანძს.

ჩვენ გამოვიყენეთ YCSB დატვირთვა A 10M მწკრივის მონაცემთა ნაკრების შესაქმნელად.

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

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

სკალირება?

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

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

ჩვენ მოვახერხეთ 25-დან 2 შემთხვევამდე შემცირება, მაგრამ დავრჩით ორ კვანძზე.

Cloud Spanner კლასტერში კვანძების რაოდენობის გაზრდა და შემცირება შესაძლებელია ავტომატიზირებული იყოს REST API-ის გამოყენებით. ეს განსაკუთრებით სასარგებლოა დატვირთული სამუშაო საათების დროს სისტემის გაზრდილი დატვირთვის შესამცირებლად.

OLAP მოთხოვნების შესრულება?

ჩვენ თავდაპირველად ვგეგმავდით მნიშვნელოვანი დროის დახარჯვას ამ ნაწილზე Spanner-ის შეფასებაში. რამდენიმე SELECT COUNT-ის შემდეგ, ჩვენ მაშინვე მივხვდით, რომ ტესტირება ხანმოკლე იქნებოდა და რომ Spanner არ იქნებოდა შესაფერისი ძრავა OLAP-ისთვის. კლასტერში კვანძების რაოდენობის მიუხედავად, 10M მწკრივის ცხრილში მწკრივების უბრალოდ არჩევას 55-დან 60 წამამდე დასჭირდა. გარდა ამისა, ნებისმიერი მოთხოვნა, რომელიც საჭიროებდა მეტ მეხსიერებას შუალედური შედეგების შესანახად, ვერ მოხერხდა OOM შეცდომით.

SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.

TPC-H მოთხოვნების ზოგიერთი ნომერი შეგიძლიათ იხილოთ ტოდ ლიპკონის სტატიაში Nosql-kudu-spanner-slides.html, სლაიდები 42 და 43. ეს რიცხვები შეესაბამება ჩვენს შედეგებს (სამწუხაროდ).

4. ჩვენი დასკვნები

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

როდესაც ჩვენ დავიწყეთ Cloud Spanner-ის შეფასება, ველოდით, რომ მისი მართვის ფუნქციები იქნებოდა Google SQL-ის სხვა გადაწყვეტილებებისგან, ან სულ მცირე, არც ისე შორს. მაგრამ ჩვენ გაგვიკვირდა სარეზერვო ასლების სრული ნაკლებობა და რესურსებზე წვდომის ძალიან შეზღუდული კონტროლი. რომ აღარაფერი ვთქვათ ხედებზე, ლოკალური განვითარების გარემოზე, მხარდაჭერილ თანმიმდევრობებზე, JDBC DML და DDL მხარდაჭერის გარეშე და ა.შ.

მაშ, სად მიდის ადამიანი, რომელსაც სჭირდება ტრანზაქციების მონაცემთა ბაზის მასშტაბირება? როგორც ჩანს, ბაზარზე არ არის ერთი გამოსავალი, რომელიც მოერგება ყველა გამოყენების შემთხვევას. არსებობს მრავალი დახურული და ღია კოდის გადაწყვეტა (ზოგიერთი ნახსენებია ამ სტატიაში), თითოეულს აქვს საკუთარი ძლიერი და სუსტი მხარეები, მაგრამ არცერთი მათგანი არ გვთავაზობს SaaS-ს 99,999% SLA-ით და მაღალი თანმიმდევრულობით. თუ მაღალი SLA არის თქვენი მთავარი მიზანი და არ ხართ მიდრეკილი პერსონალური მრავალ ღრუბლოვანი გადაწყვეტის შესაქმნელად, Cloud Spanner შეიძლება იყოს გამოსავალი, რომელსაც ეძებთ. მაგრამ თქვენ უნდა იცოდეთ მისი ყველა შეზღუდვა.

სამართლიანი რომ ვიყოთ, Cloud Spanner მხოლოდ 2017 წლის გაზაფხულზე გამოვიდა საზოგადოებისთვის, ასე რომ, გონივრული იქნება იმის მოლოდინი, რომ მისი ამჟამინდელი ხარვეზები საბოლოოდ გაქრება (იმედია) და როდესაც ისინი გაქრება, ეს შეიძლება იყოს თამაშის შეცვლა. ყოველივე ამის შემდეგ, Cloud Spanner არ არის მხოლოდ გვერდითი პროექტი Google-ისთვის. Google იყენებს მას, როგორც Google-ის სხვა პროდუქტების საფუძველს. და როდესაც Google-მა ცოტა ხნის წინ შეცვალა Megastore Google Cloud Storage-ში Cloud Spanner-ით, ამან საშუალება მისცა Google Cloud Storage გამხდარიყო უაღრესად თანმიმდევრული გლობალური მასშტაბის ობიექტების სიებისთვის (რაც ჯერ კიდევ არ არის ასე Amazon- ის S3).

ასე რომ, იმედი ჯერ კიდევ არის... იმედი გვაქვს.

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

ყველას გეპატიჟებით ეწვიოთ ჩვენს უფასო ვებინარი რომლის ფარგლებშიც დეტალურად მოგიყვებით კურსის შესახებ "AWS დეველოპერებისთვის" OTUS-დან.

წყარო: www.habr.com