NoSQL-ისთვის მონაცემთა მოდელის დიზაინის მახასიათებლები

შესავალი

"რაც შეიძლება სწრაფად უნდა ირბინო, რომ ადგილზე დარჩე,
და სადმე რომ მოხვდე, ორჯერ მაინც უნდა ირბინო!”
(გ) ალისა საოცრებათა ქვეყანაში

რამდენიმე ხნის წინ ლექციის წაკითხვა მთხოვეს ანალიტიკოსები ჩვენი კომპანია მონაცემთა მოდელების დიზაინის თემაზე, რადგან პროექტებზე დიდხანს ჯდომისას (ზოგჯერ რამდენიმე წლის განმავლობაში) თვალს ვკარგავთ იმაზე, რაც ხდება ჩვენს ირგვლივ IT ტექნოლოგიების სამყაროში. ჩვენს კომპანიაში (ეს ასეც ხდება) ბევრი პროექტი არ იყენებს NoSQL მონაცემთა ბაზებს (ყოველ შემთხვევაში, ახლა), ასე რომ, ჩემს ლექციაზე ცალკე მივაქციე ყურადღება მათ HBase-ის მაგალითის გამოყენებით და შევეცადე მასალის პრეზენტაცია ამ თემაზე ორიენტირებულიყო. ვინც არასდროს გამოუყენებია ისინი მუშაობდნენ. კერძოდ, მე ვაჩვენე მონაცემთა მოდელის დიზაინის ზოგიერთი მახასიათებელი რამდენიმე წლის წინ წაკითხული მაგალითის გამოყენებით ამანდიპ ხურანას სტატიაში „HB ase Schema Design-ის შესავალი“.. მაგალითების გაანალიზებისას შევადარე ერთიდაიგივე პრობლემის გადაჭრის რამდენიმე ვარიანტი, რათა ძირითადი იდეები აუდიტორიამდე უკეთ გადმომეცა.

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

მაგალითი ანალიზი

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

განვიხილოთ შემდეგი „სინთეზური“ პრობლემა, რომლითაც ჩვენ გავაგრძელებთ მუშაობას:

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

• უპასუხეთ კითხვას, კითხულობს თუ არა მომხმარებელი B მომხმარებელს (კითხვის ნიმუში)
• დაუშვით კავშირების დამატება/წაშლა A მომხმარებლის B მომხმარებლისგან გამოწერის/გამოწერის შემთხვევაში (მონაცემთა ცვლილების შაბლონი)

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

მომხმარებლის იდენტიფიკაცია
friend_id

Vasya
პეტია

Vasya
Оля

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

HBase-ის შემთხვევაში ჩვენ ვიცით, რომ:

• შესაძლებელია ეფექტური ძიება, რომელიც არ იწვევს ცხრილის სრულ სკანირებას ექსკლუზიურად გასაღებით
  • ფაქტობრივად, სწორედ ამიტომ, ასეთი მონაცემთა ბაზებისთვის ბევრისთვის ნაცნობი SQL მოთხოვნების დაწერა ცუდი იდეაა; ტექნიკურად, რა თქმა უნდა, შეგიძლიათ გაგზავნოთ SQL მოთხოვნა Joins-ით და სხვა ლოგიკით HBase-ზე იმავე Impala-დან, მაგრამ რამდენად ეფექტური იქნება ეს...

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

RowKey
დინამიკები

Vasya
1: პეტია
2: ოლია
3: დაშა

პეტია
1: მაშა
2: ვასია

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

• სვეტების შემადგენლობის დინამიურად შეცვლის შესაძლებლობა (მეგობრის დამატება -> სვეტის დამატება, მეგობრის წაშლა -> სვეტის წაშლა)
• სხვადასხვა სტრიქონს შეიძლება ჰქონდეს სხვადასხვა სვეტის კომპოზიცია

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

• მონაცემების კითხვა: იმისათვის, რომ გავიგოთ, არის თუ არა გამოწერილი ვასია ოლიას, დაგვჭირდება გამოკლება მთელი ხაზი RowKey = "Vasya" გასაღებით და დაალაგეთ სვეტის მნიშვნელობების მიხედვით, სანამ მათში ოლიას "შევხვდებით". ან გაიმეორეთ ყველა სვეტის მნიშვნელობებით, „არ შეხვდეთ“ ოლიას და დააბრუნეთ პასუხი False;
• მონაცემების რედაქტირება: მეგობრის დამატება: მსგავსი ამოცანისთვის ასევე უნდა გამოვაკლოთ მთელი ხაზი კლავიშის გამოყენებით RowKey = „Vasya“ მისი მეგობრების საერთო რაოდენობის დასათვლელად. ჩვენ გვჭირდება მეგობრების ეს საერთო რაოდენობა, რათა განვსაზღვროთ იმ სვეტის რაოდენობა, რომელშიც უნდა ჩავწეროთ ახალი მეგობრის ID.
• მონაცემების შეცვლა: მეგობრის წაშლა:
  • საჭიროა გამოკლება მთელი ხაზი გასაღებით RowKey = „Vasya“ და დაალაგეთ სვეტების მიხედვით, რათა იპოვოთ ის, რომელშიც ჩაიწერა წასაშლელი მეგობარი;
  • შემდეგი, მეგობრის წაშლის შემდეგ, ჩვენ უნდა "გადავიტანოთ" ყველა მონაცემი ერთ სვეტში, რათა არ მივიღოთ "ხარვეზები" მათ ნუმერაციაში.

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

• მონაცემების კითხვა: აუცილებელია მთელი ხაზის გამოკლება და მისი ყველა სვეტის გამეორება ლიმიტში. ეს ნიშნავს, რომ ხარჯების ზედა შეფასება იქნება დაახლოებით O(n)
• მონაცემების რედაქტირება: მეგობრის დამატება: მეგობრების რაოდენობის დასადგენად, თქვენ უნდა გაიმეოროთ მწკრივის ყველა სვეტი და შემდეგ ჩადეთ ახალი სვეტი => O(n)
• მონაცემების შეცვლა: მეგობრის წაშლა:
  • დამატების მსგავსად - თქვენ უნდა გაიაროთ ყველა სვეტი ლიმიტში => O(n)
  • სვეტების ამოღების შემდეგ საჭიროა მათი „გადატანა“. თუ თქვენ განახორციელებთ ამ "პირდაპირს", მაშინ ლიმიტში დაგჭირდებათ (n-1) ოპერაციები. მაგრამ აქ და შემდგომ პრაქტიკულ ნაწილში ჩვენ გამოვიყენებთ განსხვავებულ მიდგომას, რომელიც განახორციელებს "ფსევდო ცვლას" ოპერაციების ფიქსირებული რაოდენობისთვის - ანუ მასზე დაიხარჯება მუდმივი დრო, მიუხედავად n. ეს მუდმივი დრო (O(2) უფრო ზუსტად) შეიძლება უგულებელყო O(n-თან შედარებით). მიდგომა ილუსტრირებულია ქვემოთ მოცემულ ფიგურაში: ჩვენ უბრალოდ ვაკოპირებთ მონაცემებს „ბოლო“ სვეტიდან იმ სვეტში, საიდანაც გვინდა წაშალოთ მონაცემები და შემდეგ ვშლით ბოლო სვეტს:
    

საერთო ჯამში, ყველა სცენარში მივიღეთ O(n) ასიმპტოტური გამოთვლითი სირთულე.
თქვენ ალბათ უკვე შენიშნეთ, რომ ჩვენ თითქმის ყოველთვის გვიწევს მონაცემთა ბაზიდან მთელი რიგის წაკითხვა და სამიდან ორ შემთხვევაში, მხოლოდ ყველა სვეტის გასავლელად და მეგობრების საერთო რაოდენობის გამოთვლა. ამიტომ, როგორც ოპტიმიზაციის მცდელობა, შეგიძლიათ დაამატოთ "დათვლა" სვეტი, რომელიც ინახავს ქსელის თითოეული მომხმარებლის მეგობრების საერთო რაოდენობას. ამ შემთხვევაში, ჩვენ არ შეგვიძლია წავიკითხოთ მთელი რიგი მეგობრების საერთო რაოდენობის გამოსათვლელად, მაგრამ წავიკითხოთ მხოლოდ ერთი სვეტი "დათვლა". მთავარია, არ დაგავიწყდეთ „რიცხვის“ განახლება მონაცემების მანიპულირებისას. რომ. ჩვენ გავუმჯობესდებით ვარიანტი 2 (თვლა):

RowKey
დინამიკები

Vasya
1: პეტია
2: ოლია
3: დაშა
რაოდენობა: 3

პეტია
1: მაშა
2: ვასია

რაოდენობა: 2

პირველ ვარიანტთან შედარებით:

• მონაცემების კითხვა: პასუხის მისაღებად კითხვაზე "კითხულობს თუ არა ვასია ოლიას?" არაფერი შეცვლილა => O(n)
• მონაცემების რედაქტირება: მეგობრის დამატება: ჩვენ გავამარტივეთ ახალი მეგობრის ჩასმა, რადგან ახლა არ გვჭირდება მთელი ხაზის წაკითხვა და მის სვეტებზე გამეორება, მაგრამ შეგვიძლია მივიღოთ მხოლოდ სვეტის „დათვლის“ მნიშვნელობა და ა.შ. დაუყოვნებლივ განსაზღვრეთ სვეტის ნომერი ახალი მეგობრის ჩასასმელად. ეს იწვევს გამოთვლითი სირთულის შემცირებას O(1)-მდე
• მონაცემების შეცვლა: მეგობრის წაშლა: მეგობრის წაშლისას ასევე შეგვიძლია გამოვიყენოთ ეს სვეტი, რათა შევამციროთ I/O ოპერაციების რაოდენობა მონაცემთა ერთი უჯრედის მარცხნივ „გადატანისას“. მაგრამ სვეტების მეშვეობით გამეორების აუცილებლობა, რომ იპოვოთ ის, რომელიც უნდა წაიშალოს, კვლავ რჩება, ასე რომ => O(n)
• მეორეს მხრივ, ახლა მონაცემთა განახლებისას ჩვენ გვჭირდება ყოველ ჯერზე განაახლოთ სვეტი "დათვლა", მაგრამ ამას მუდმივი დრო სჭირდება, რაც შეიძლება უგულებელვყოთ O-სიმბოლოების ფარგლებში.

ზოგადად, ვარიანტი 2 ცოტა უფრო ოპტიმალური ჩანს, მაგრამ ის უფრო ჰგავს „ევოლუციას რევოლუციის ნაცვლად“. "რევოლუციის" გასაკეთებლად დაგვჭირდება ვარიანტი 3 (col).
მოდით, ყველაფერი "თავდაყირა" გადავდოთ: ჩვენ დავავალებთ სვეტის სახელი მომხმარებლის ID! რა ჩაიწერება თავად სვეტში, ჩვენთვის აღარ არის მნიშვნელოვანი, ეს იყოს ნომერი 1 (ზოგადად, იქ შეიძლება სასარგებლო ნივთების შენახვა, მაგალითად, ჯგუფი "ოჯახი/მეგობრები/ა.შ."). ამ მიდგომამ შეიძლება გააკვირვოს მოუმზადებელი „ერისკაცი“, რომელსაც არ აქვს NoSQL მონაცემთა ბაზებთან მუშაობის გამოცდილება, მაგრამ სწორედ ეს მიდგომა საშუალებას გაძლევთ გამოიყენოთ HBase-ის პოტენციალი ამ ამოცანაში ბევრად უფრო ეფექტურად:

RowKey
დინამიკები

Vasya
პეტია: 1
ოლია: 1
დაშა: 1

პეტია
მაშა: 1
ვასია: 1

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

• მონაცემების კითხვა: იმისათვის, რომ უპასუხოთ კითხვას, არის თუ არა ვასია გამოწერილი ოლიას, საკმარისია წაიკითხოთ ერთი სვეტი "ოლია": თუ ის იქ არის, მაშინ პასუხი მართალია, თუ არა - მცდარი => O(1)
• მონაცემების რედაქტირება: მეგობრის დამატება: მეგობრის დამატება: უბრალოდ დაამატეთ ახალი სვეტი „Friend ID“ => O(1)
• მონაცემების შეცვლა: მეგობრის წაშლა: უბრალოდ ამოიღეთ მეგობრის ID სვეტი => O(1)

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

თქვენ შეგიძლიათ გაგიჟდეთ და ცოტა უფრო შორს წახვიდეთ შესრულების ოპტიმიზაციისა და I/O ოპერაციების შემცირების გზაზე მონაცემთა ბაზაში წვდომისას. რა მოხდება, თუ ჩვენ შევინახავთ ურთიერთობის შესახებ სრულ ინფორმაციას პირდაპირ მწკრივის კლავიშში? ანუ, გააკეთეთ გასაღების კომპოზიტი, როგორიცაა userID.friendID? ამ შემთხვევაში, ჩვენ საერთოდ არ უნდა წავიკითხოთ ხაზის სვეტები (ვარიანტი 4 (სტრიქონი)):

RowKey
დინამიკები

ვასია.პეტია
პეტია: 1

ვასია.ოლია
ოლია: 1

ვასია.დაშა
დაშა: 1

პეტია.მაშა
მაშა: 1

პეტია.ვასია
ვასია: 1

ცხადია, მონაცემთა მანიპულირების ყველა სცენარის შეფასება ასეთ სტრუქტურაში, როგორც წინა ვერსიაში, იქნება O(1). მე-3 ვარიანტთან განსხვავება იქნება მხოლოდ მონაცემთა ბაზაში I/O ოპერაციების ეფექტურობაში.

ისე, ბოლო "მშვილდი". ადვილი მისახვედრია, რომ მე-4 ვარიანტში მწკრივის კლავიშს ექნება ცვლადი სიგრძე, რამაც შესაძლოა გავლენა მოახდინოს შესრულებაზე (აქ ჩვენ გვახსოვს, რომ HBase ინახავს მონაცემებს, როგორც ბაიტების ერთობლიობას და ცხრილებში რიგები დალაგებულია გასაღების მიხედვით). გარდა ამისა, ჩვენ გვაქვს გამყოფი, რომელიც შეიძლება საჭირო გახდეს ზოგიერთ სცენარში. ამ გავლენის აღმოსაფხვრელად, შეგიძლიათ გამოიყენოთ ჰეშები userID-დან და friendID-დან, და რადგან ორივე ჰეშს ექნება მუდმივი სიგრძე, შეგიძლიათ უბრალოდ დააკავშიროთ ისინი გამყოფის გარეშე. შემდეგ ცხრილში მოცემული მონაცემები ასე გამოიყურება (ვარიანტი 5 (ჰეში)):

RowKey
დინამიკები

dc084ef00e94aef49be885f9b01f51c01918fa783851db0dc1f72f83d33a5994
პეტია: 1

dc084ef00e94aef49be885f9b01f51c0f06b7714b5ba522c3cf51328b66fe28a
ოლია: 1

dc084ef00e94aef49be885f9b01f51c00d2c2e5d69df6b238754f650d56c896a
დაშა: 1

1918fa783851db0dc1f72f83d33a59949ee3309645bd2c0775899fca14f311e1
მაშა: 1

1918fa783851db0dc1f72f83d33a5994dc084ef00e94aef49be885f9b01f51c0
ვასია: 1

ცხადია, ასეთ სტრუქტურასთან მუშაობის ალგორითმული სირთულე ჩვენს განხილულ სცენარებში იგივე იქნება, რაც მე-4 ვარიანტის - ანუ O(1).
მთლიანობაში, მოდით შევაჯამოთ გამოთვლითი სირთულის ყველა შეფასება ერთ ცხრილში:

მეგობრის დამატება
მეგობრის შემოწმება
მეგობრის მოცილება

ვარიანტი 1 (ნაგულისხმევი)
O (n)
O (n)
O (n)

ვარიანტი 2 (თვლა)
O (1)
O (n)
O (n)

ვარიანტი 3 (სვეტი)
O (1)
O (1)
O (1)

ვარიანტი 4 (რიგით)
O (1)
O (1)
O (1)

ვარიანტი 5 (ჰეში)
O (1)
O (1)
O (1)

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

ექსპერიმენტის მომზადება

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

• ერთი ახალი მეგობრის დამატება
• ამოწმებს, არის თუ არა მომხმარებელი B მომხმარებლის მეგობარი
• ერთი მეგობრის მოცილება

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

• მონაცემთა ჩაწერა. შემთხვევით გენერირება საწყისი ქსელი ზომის n. „რეალურ სამყაროსთან“ დასაახლოებლად, თითოეულ მომხმარებელს ჰყავს მეგობრების რაოდენობა ასევე შემთხვევითი ცვლადი. გაზომეთ დრო, რომლის დროსაც ჩვენი „პირობითი აპლიკაცია“ წერს ყველა გენერირებულ მონაცემს HBase-ში. შემდეგ გაყავით მიღებული დრო დამატებული მეგობრების საერთო რაოდენობაზე - ასე ვიღებთ საშუალო დროს ერთი „საქმიანი ოპერაციისთვის“
• მონაცემების კითხვა. თითოეული მომხმარებლისთვის შექმენით „პიროვნებების“ სია, რომელზედაც თქვენ უნდა მიიღოთ პასუხი, არის თუ არა მომხმარებელი მათზე გამოწერილი. სიის სიგრძე = დაახლოებით მომხმარებლის მეგობრების რაოდენობა, ხოლო შემოწმებული მეგობრების ნახევარზე პასუხი უნდა იყოს „დიახ“, ხოლო მეორე ნახევრისთვის – „არა“. შემოწმება ხდება ისე, რომ პასუხები "დიახ" და "არა" მონაცვლეობით ხდება (ანუ ყოველ მეორე შემთხვევაში ჩვენ მოგვიწევს ხაზის ყველა სვეტის გავლა 1 და 2 ვარიანტებისთვის). სკრინინგის მთლიანი დრო იყოფა მეგობრების რაოდენობაზე, რომლებიც ტესტირებულ იქნა, რათა მიიღოთ საშუალო სკრინინგის დრო თითო სუბიექტზე.
• მონაცემების წაშლა. წაშალეთ ყველა მეგობარი მომხმარებლისგან. უფრო მეტიც, წაშლის თანმიმდევრობა არის შემთხვევითი (ანუ ჩვენ „არევთ“ თავდაპირველ სიას, რომელიც გამოიყენება მონაცემთა ჩასაწერად). შემოწმების მთლიანი დრო იყოფა წაშლილი მეგობრების რაოდენობაზე, რათა მიიღოთ საშუალო დრო თითო შემოწმებაზე.

სცენარები უნდა განხორციელდეს 5 მონაცემთა მოდელის თითოეული ვარიანტისთვის და სოციალური ქსელის სხვადასხვა ზომისთვის, რათა ნახოთ, როგორ იცვლება დრო მისი ზრდის დროს. ერთი n-ის ფარგლებში, ქსელში კავშირები და შესამოწმებელი მომხმარებლების სია, რა თქმა უნდა, ერთნაირი უნდა იყოს ხუთივე ვარიანტისთვის.
უკეთესი გაგებისთვის, ქვემოთ მოცემულია n= 5-ისთვის გენერირებული მონაცემების მაგალითი. დაწერილი „გენერატორი“ აწარმოებს სამ ID ლექსიკონს გამოსავალად:

• პირველი არის ჩასართავად
• მეორე არის შესამოწმებლად
• მესამე - წაშლისთვის

{0: [1], 1: [4, 5, 3, 2, 1], 2: [1, 2], 3: [2, 4, 1, 5, 3], 4: [2, 1]} # всего 15 друзей

{0: [1, 10800], 1: [5, 10800, 2, 10801, 4, 10802], 2: [1, 10800], 3: [3, 10800, 1, 10801, 5, 10802], 4: [2, 10800]} # всего 18 проверяемых субъектов

{0: [1], 1: [1, 3, 2, 5, 4], 2: [1, 2], 3: [4, 1, 2, 3, 5], 4: [1, 2]} # всего 15 друзей

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

ექსპერიმენტი ჩატარდა ლეპტოპზე Windows 10-ით, სადაც HBase მუშაობდა Docker-ის ერთ კონტეინერში, ხოლო Python Jupyter Notebook-ით მეორეში. Docker-ს გამოეყო 2 CPU ბირთვი და 2 GB ოპერატიული მეხსიერება. მთელი ლოგიკა, როგორც "პირობითი აპლიკაციის" ემულაცია და "მილები" ტესტის მონაცემების გენერირებისთვის და დროის გაზომვისთვის, დაიწერა პითონში. ბიბლიოთეკა გამოიყენებოდა HBase-თან სამუშაოდ ბედნიერი ბაზა, ჰეშების (MD5) გამოსათვლელად მე-5 ვარიანტისთვის - ჰეშლიბი

კონკრეტული ლეპტოპის გამოთვლითი სიმძლავრის გათვალისწინებით, ექსპერიმენტულად შეირჩა გაშვება n = 10, 30, …. 170 – როდესაც სრული ტესტირების ციკლის მთლიანი ოპერაციული დრო (ყველა სცენარი ყველა n-ისთვის ყველა ვარიანტისთვის) კიდევ მეტ-ნაკლებად გონივრული იყო და ჯდებოდა ერთი ჩაის დროს (საშუალოდ 15 წუთი).

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

ექსპერიმენტის შედეგი

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

3-5 ვარიანტები, როგორც მოსალოდნელი იყო, აჩვენებს თითქმის მუდმივ „ბიზნეს ტრანზაქციის“ დროს, რომელიც არ არის დამოკიდებული ქსელის ზომის ზრდაზე და შესრულების განუყოფელ განსხვავებაზე.
ვარიანტი 2 ასევე აჩვენებს მუდმივ, მაგრამ ოდნავ უარეს შესრულებას, თითქმის ზუსტად 2-ჯერ 3-5 ვარიანტებთან შედარებით. და ეს არ შეიძლება არ გაახაროს, რადგან ის კორელაციაშია თეორიასთან - ამ ვერსიაში I/O ოპერაციების რაოდენობა HBase-დან/დან ზუსტად 2-ჯერ მეტია. ეს შეიძლება იყოს არაპირდაპირი მტკიცებულება იმისა, რომ ჩვენი ტესტის სკამი, პრინციპში, უზრუნველყოფს კარგ სიზუსტეს.
ვარიანტი 1 ასევე, როგორც მოსალოდნელი იყო, აღმოჩნდება ყველაზე ნელი და აჩვენებს დროის ხაზოვან ზრდას, რომელიც დახარჯულია ქსელის ზომაზე ერთმანეთის დამატებაზე.
ახლა გადავხედოთ მეორე ტესტის შედეგებს.

3-5 ვარიანტები ისევ ისე იქცევა, როგორც მოსალოდნელია - მუდმივი დრო, ქსელის ზომისგან დამოუკიდებლად. 1 და 2 ვარიანტები აჩვენებენ დროის წრფივ ზრდას ქსელის ზომის გაზრდით და მსგავს შესრულებას. უფრო მეტიც, ვარიანტი 2 აღმოჩნდება ოდნავ ნელი - როგორც ჩანს, დამატებითი "დათვლის" სვეტის კორექტირებისა და დამუშავების აუცილებლობის გამო, რომელიც უფრო შესამჩნევი ხდება, როგორც n იზრდება. მაგრამ მე მაინც თავს შევიკავებ რაიმე დასკვნის გამოტანისგან, ვინაიდან ამ შედარების სიზუსტე შედარებით დაბალია. გარდა ამისა, ეს კოეფიციენტები (რომელიც ვარიანტი, 1 ან 2, უფრო სწრაფია) იცვლებოდა რბენიდან რბენამდე (ამას შენარჩუნდა დამოკიდებულების ბუნება და „კისერი და კისერი“).

ისე, ბოლო გრაფიკი არის მოხსნის ტესტირების შედეგი.

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

1 და 2 ვარიანტები, როგორც მოსალოდნელი იყო, აჩვენებს დროის წრფივ ზრდას. ამავდროულად, ვარიანტი 2 თანმიმდევრულად უფრო ნელია ვიდრე ვარიანტი 1 - დამატებითი I/O ოპერაციის გამო დათვლის სვეტის „შენარჩუნებისთვის“.

ექსპერიმენტის ზოგადი დასკვნები:

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

ეპილოგი

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

დასასრულს, რეკომენდაციები ყველასთვის, ვინც ახლახან იწყებს მონაცემთა მოდელების შექმნას HBase-ში: აბსტრაქტული წინა გამოცდილებიდან, რომელიც მუშაობდა ურთიერთობით მონაცემთა ბაზებთან და დაიმახსოვრე „მცნებები“:

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

წყარო: www.habr.com