რომელია უკეთესი - Oracle ან Redis ან როგორ გავამართლოთ პლატფორმის არჩევანი

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

იული დუბოვი, "მცირე ბოროტება"

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

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

მოტივაცია

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

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

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

ჭრის პირობები

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

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

• ACID გარანტიები;
• რელაციური მონაცემთა მოდელი;
• SQL ენის მხარდაჭერა (გაითვალისწინეთ, ეს არ არის იგივე, რაც "რელაციური მოდელი");
• ჰორიზონტალური სკალირების შესაძლებლობა.

შეიძლება არსებობდეს ზოგადი კრიტერიუმები:

• კომერციული მხარდაჭერის ხელმისაწვდომობა რუსეთში;
• საჯარო წყარო;
• პლატფორმის ხელმისაწვდომობა ტელეკომის და მასობრივი კომუნიკაციების სამინისტროს რეესტრში;
• პლატფორმის არსებობა გარკვეულ რეიტინგში (მაგალითად, db-engines.com-ის რეიტინგის პირველ ასეულში);
• ბაზარზე ექსპერტების არსებობა (მაგალითად, ვებსაიტზე hh.ru რეზიუმეში პლატფორმის სახელის ძიების შედეგების საფუძველზე).

ყოველივე ამის შემდეგ, შეიძლება არსებობდეს საწარმოს სპეციფიკური კრიტერიუმები:

• სპეციალისტების ხელმისაწვდომობა პერსონალზე;
• თავსებადობა მონიტორინგის სისტემასთან X ან სარეზერვო სისტემასთან Y, რომელზეც დაფუძნებულია მთელი მხარდაჭერა...

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

Ხარჯთაღრიცხვა

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

თუ სისტემები დაახლოებით იგივე კლასია (მაგალითად, Microsoft SQL Server და PostgreSQL), მაშინ სიმარტივისთვის შეგვიძლია ვივარაუდოთ, რომ ორივე გადაწყვეტილების აღჭურვილობის რაოდენობა დაახლოებით იგივე იქნება. ეს საშუალებას მოგცემთ არ შეაფასოთ აღჭურვილობა, რითაც დაზოგავთ დიდ დროს და ძალისხმევას. თუ თქვენ უნდა შეადაროთ სრულიად განსხვავებული სისტემები (ვთქვათ, Oracle vs. Redis), მაშინ აშკარაა, რომ სწორი შეფასებისთვის საჭიროა sizing (აღჭურვილობის რაოდენობის გამოთვლა). არარსებული სისტემის ზომების დადგენა ძალიან უმადურ საქმეა, ამიტომ ისინი მაინც ცდილობენ თავი აარიდონ ასეთ შედარებებს. ამის გაკეთება მარტივია: შეწყვეტის პირობებში იწერება ნულოვანი მონაცემთა დაკარგვა და ურთიერთობის მოდელი, ან პირიქით - 50 ათასი ტრანზაქციის დატვირთვა წამში.

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

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

სწორი შედარებისთვის მნიშვნელოვანი პუნქტია მხარდაჭერის იგივე პირობები. მაგალითად, Oracle-ის მხარდაჭერა ღირს ლიცენზიის ფასის 22% წელიწადში, მაგრამ თქვენ არ გჭირდებათ გადახდა PostgreSQL მხარდაჭერისთვის. სწორია ასე შედარება? არა, რადგან შეცდომას, რომლის დამოუკიდებლად გამოსწორება შეუძლებელია, აქვს სრულიად განსხვავებული შედეგები: პირველ შემთხვევაში, დამხმარე სპეციალისტები სწრაფად დაგეხმარებიან მის გამოსწორებაში, მაგრამ მეორე შემთხვევაში, არსებობს პროექტის შეფერხების ან დასრულებული სამუშაოს შეფერხების რისკი. სისტემა განუსაზღვრელი ვადით.

თქვენ შეგიძლიათ გაათანაბროთ გაანგარიშების პირობები სამი გზით:

1. გამოიყენეთ Oracle მხარდაჭერის გარეშე (სინამდვილეში ეს არ ხდება).
2. შეიძინეთ მხარდაჭერა PostgreSQL-ისთვის - მაგალითად, Postgres Professional-ისგან.
3. გაითვალისწინეთ მხარდაჭერის ნაკლებობასთან დაკავშირებული რისკები.

მაგალითად, რისკის გაანგარიშება შეიძლება ასე გამოიყურებოდეს: მონაცემთა ბაზის ფატალური წარუმატებლობის შემთხვევაში, სისტემის გაუმართაობა იქნება 1 სამუშაო დღე. სისტემის გამოყენების პროგნოზირებული მოგება არის 40 მილიარდი MNT წელიწადში, ავარიის მაჩვენებელი შეფასებულია 1/400, შესაბამისად მხარდაჭერის არარსებობის რისკი შეფასებულია დაახლოებით 100 მილიონი MNT წელიწადში. ცხადია, „დაგეგმილი მოგება“ და „ავარიის სავარაუდო სიხშირე“ ვირტუალური მნიშვნელობებია, მაგრამ ასეთი მოდელის ქონა ბევრად უკეთესია, ვიდრე არ ქონდეთ.

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

დავუშვათ, რომ ყველა გამოთვლების შემდეგ, ოპერაციული პლატფორმის A 5 წლის ღირებულება გამოდის 800 მილიონი MNT, ოპერაციული პლატფორმის B არის 650 მილიონი MNT, ხოლო ოპერაციული პლატფორმის C არის 600 მილიონი MNT. პლატფორმა C, როგორც გამარჯვებული, იღებს სრულ ქულას ფასზე, ხოლო პლატფორმები A და B იღებენ ოდნავ ნაკლებს, რამდენჯერ უფრო ძვირია. ამ შემთხვევაში – 0.75 და 0.92 ქულა, შესაბამისად.

შესაძლებლობის შეფასება

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

განვითარების ფუნქციები მოიცავს:

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

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

ადმინისტრაციის ფუნქციები მოიცავს:

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

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

Tool
კომენტარები
შეფასება

imp/exp
მონაცემების ატვირთვა და ჩატვირთვა
0.1

სარეზერვო ასლის დაწყება/დასრულება
ფაილების კოპირება
0.3

RMAN
დამატებითი კოპირების შესაძლებლობა
0.7

ZDLRA
მხოლოდ დამატებითი კოპირება, ყველაზე სწრაფი აღდგენა წერტილამდე
1.0

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

და ბოლოს, ჩვენ უბრალოდ ჩამოვთვლით ინფორმაციის უსაფრთხოების ფუნქციებს:

• პაროლის მართვის პოლიტიკის ხელმისაწვდომობა;
• გარე ავტორიზაციის ხელსაწყოების დაკავშირების შესაძლებლობა (LDAP, Kerberos);
• წვდომის როლური მოდელი;
• აუდიტის შესაძლებლობები;
• დისკზე მონაცემების დაშიფვრა;
• დაშიფვრა ქსელში გადაცემისას (TLS);
• მონაცემთა დაცვა ადმინისტრატორისგან.

შესრულების ტესტირება

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

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

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

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

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

შედეგი

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

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

წყარო: www.habr.com