ეს მონაცემთა ბაზა იწვის...

ტექნიკურ ისტორიას მოგიყვებით.

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

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


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

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

ყოველდღიური სინქრონიზაციის დიზაინი

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

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

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

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

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

პირველს ე.წ Firebase რეალურ დროში მონაცემთა ბაზადა მეორე - Firebase Cloud Firestore. ორივე მათგანი პროდუქტია Firebase კომპლექტი Google. მათ API-ებს ეძახიან შესაბამისად firebase.database(…) и firebase.firestore(…).

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

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

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

პიროსის გამარჯვება

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

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

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

აქ ვიწყებთ Firestore-ის არსებობის მიზეზის პირველი ნიშნების დანახვას. შეიძლება ვცდები, მაგრამ მეეჭვება, რომ Google-ის მენეჯმენტში ვიღაცამ შეხედა Firebase-ს შეძენის შემდეგ და უბრალოდ თქვა: „არა, ღმერთო ჩემო, არა. ეს მიუღებელია. უბრალოდ არა ჩემი ხელმძღვანელობით“.

ის გამოვიდა თავისი პალატიდან და თქვა:

„ერთი დიდი JSON დოკუმენტი? არა. თქვენ დაყოფთ მონაცემებს ცალკეულ დოკუმენტებად, რომელთაგან თითოეული იქნება არაუმეტეს 1 მეგაბაიტის ზომის“.

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

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

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

ასე რომ, თუ თქვენ იმედოვნებდით GeoJSON-ს თქვენს Firestore-ში ჩასმას, აღმოაჩენთ, რომ ეს შეუძლებელია. არაფერი არაერთგანზომილებიანი არ არის მისაღები. იმედი მაქვს მოგეწონებათ Base64 და/ან JSON JSON-ში.

„JSON იმპორტი და ექსპორტი HTTP, ბრძანების ხაზის ხელსაწყოების ან ადმინისტრაციული პანელის მეშვეობით? არა. თქვენ შეძლებთ მხოლოდ მონაცემების ექსპორტს და იმპორტს Google Cloud Storage-ში. ასე ქვია ახლა მგონი. და როდესაც მე ვამბობ "შენ", მე მივმართავ მხოლოდ მათ, ვისაც აქვს პროექტის მფლობელის რწმუნებათა სიგელები. ყველას შეუძლია წავიდეს და შექმნას ბილეთები“.

როგორც ხედავთ, FireBase მონაცემთა მოდელის აღწერა მარტივია. ის შეიცავს ერთ უზარმაზარ JSON დოკუმენტს, რომელიც აკავშირებს JSON გასაღებებს URL ბილიკებთან. თან თუ წერ HTTP PUT в / FireBase არის შემდეგი:

{
  "hello": "world"
}

რუბრიკები GET /hello დაბრუნდება "world". ძირითადად მუშაობს ზუსტად ისე, როგორც თქვენ მოელით. FireBase ობიექტების კოლექცია /my-collection/:id JSON ლექსიკონის ექვივალენტი {"my-collection": {...}} ძირში, რომლის შიგთავსი ხელმისაწვდომია /my-collection:

{
  "id1": {...object},
  "id2": {...object},
  "id3": {...object},
  // ...
}

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

სხვა სიტყვებით რომ ვთქვათ, მონაცემთა ბაზა არის 100% JSON(*) თავსებადი და მშვენივრად მუშაობს HTTP-თან, როგორიცაა CouchDB. მაგრამ ძირითადად თქვენ იყენებთ მას რეალურ დროში API-ს საშუალებით, რომელიც აბსტრაქტებს ვებსოკეტებს, ავტორიზაციას და გამოწერებს. ადმინისტრაციულ პანელს აქვს ორივე შესაძლებლობა, რაც საშუალებას იძლევა რეალურ დროში რედაქტირება და JSON იმპორტი/ექსპორტი. თუ თქვენ იგივეს გააკეთებთ თქვენს კოდში, გაგიკვირდებათ, რამდენი სპეციალიზებული კოდი დაიხარჯება, როდესაც მიხვდებით, რომ პაჩი და განსხვავებული JSON წყვეტს მუდმივი მდგომარეობის დამუშავების რუტინული ამოცანების 90%-ს.

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

მათ აიღეს რეალურ დროში NoSQL მონაცემთა ბაზა და გადააქციეს ის ნელ არა-SQL-ად ავტომატური შეერთებით და ცალკე არა-JSON სვეტად. რაღაც GraftQL.

ცხელი ჯავა

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

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

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

მე არ ვიცი მთელი ლოგიკა Firestore-ის შექმნის უკან. შავ ყუთში გაჩენილი მოტივების შესახებ სპეკულირება ასევე გართობის ნაწილია. ორი ძალიან მსგავსი, მაგრამ შეუდარებელი მონაცემთა ბაზის ეს შედარება საკმაოდ იშვიათია. თითქოს ვიღაცას ეგონა: "Firebase არის მხოლოდ ფუნქცია, რომელსაც ჩვენ შეგვიძლია მივბაძოთ Google Cloud-ში", მაგრამ ჯერ არ აღმოუჩენია რეალურ სამყაროში არსებული მოთხოვნების იდენტიფიცირების ან სასარგებლო გადაწყვეტილებების შექმნის კონცეფცია, რომელიც აკმაყოფილებს ყველა ამ მოთხოვნას. „დაე დეველოპერებმა დაფიქრდნენ ამაზე. უბრალოდ გახადეთ UI ლამაზი... შეგიძლიათ მეტი ცეცხლი დაამატოთ?”

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

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

თუ Google Docs-ში მოძებნით ინფორმაციას ამის შესახებ, იმედია მიგიყვანთ რაღაც BigTable-ისა და BigQuery-ის მსგავსი. თუმცა, ყველა ამ გადაწყვეტას თან ახლავს იმდენი მკვრივი კორპორატიული გაყიდვების ჟარგონი, რომ სწრაფად დაბრუნდებით უკან და დაიწყებთ სხვა რამის ძიებას.

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

(*) ეს ხუმრობაა, ასეთი რამ არ არსებობს 100% JSON თავსებადი.

რეკლამის უფლებების შესახებ

Ძებნა VDS პროექტების გამართვისთვის, სერვერი განვითარებისა და ჰოსტინგისთვის? თქვენ ნამდვილად ხართ ჩვენი კლიენტი 🙂 ფასში უკვე შედის სხვადასხვა კონფიგურაციის სერვერების ყოველდღიური ფასები, ანტი-DDoS და Windows ლიცენზიები.

წყარო: www.habr.com