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

ჰეი ჰაბრ.

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

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

კიდევ რაშია ის კარგი? საუბარია ბევრი მოთხოვნის დამუშავებაზე. მაგრამ რამდენია ბევრი? 10, 20, 30, 40 ათასი მოთხოვნა წამში ბევრი არ არის. 100 ათასი მოთხოვნა წამში ჩაწერისთვის - ძალიან. არის კომპანიები, რომლებმაც განაცხადეს, რომ წამში 2 მილიონ მოთხოვნას ინახავენ. მათ ალბათ მოუწევთ ამის დაჯერება.

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

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

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

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

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

Map<RowKey, SortedMap<ColumnKey, ColumnValue>>

ანუ რუკა, რომელიც ასევე შეიცავს დახარისხებულ რუკას. ამ რუქის პირველი გასაღები არის Row key ან Partition key - დანაყოფის გასაღები. მეორე გასაღები, რომელიც უკვე დახარისხებული რუკის გასაღებია, არის Clustering გასაღები.

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

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

CREATE TABLE users (
	user_id uu id,
	name text,
	year int,
	salary float,
	PRIMARY KEY(user_id)

)

ძირითადი გასაღები ამ შემთხვევაში შედგება ერთი სვეტისაგან და ის ასევე არის დანაყოფის გასაღები.

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

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

მოდით დავწეროთ რამდენიმე შერჩეული განცხადება: select * from users where, userid = . გამოდის, როგორც Oracle-ში: ჩვენ ვწერთ Select, ვაზუსტებთ პირობებს და ყველაფერი მუშაობს, მომხმარებლები იღებენ მას. მაგრამ თუ აირჩევთ, მაგალითად, მომხმარებლის დაბადების გარკვეული წლის მქონე მომხმარებელს, კასანდრა ჩივის, რომ მას არ შეუძლია შეასრულოს მოთხოვნა. იმის გამო, რომ მან საერთოდ არაფერი იცის იმის შესახებ, თუ როგორ ვანაწილებთ მონაცემებს დაბადების წლის შესახებ - მას აქვს მხოლოდ ერთი სვეტი მითითებული გასაღებად. შემდეგ ის ამბობს: „კარგი, მე მაინც შემიძლია ამ თხოვნის შესრულება. დაამატეთ ნებადართული ფილტრაცია." ჩვენ დავამატებთ დირექტივას, ყველაფერი მუშაობს. და ამ დროს რაღაც საშინელება ხდება.

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

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

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

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

CREATE TABLE users_by_year_salary_id (
	user_id uuid,
	name text,
	year int,
	salary float,
	PRIMARY KEY((year), salary, user_id)

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

ჩვენ ვაყენებთ დახარისხებას და ვაწესებთ შეზღუდვებს

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

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

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

ნებისმიერ გაურკვეველ სიტუაციაში შექმენით ახალი ცხრილი

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

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

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

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

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

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

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

წყარო: www.habr.com