हा डेटाबेस पेटला आहे...

मी एक तांत्रिक गोष्ट सांगतो.

बर्‍याच वर्षांपूर्वी, मी त्यात तयार केलेल्या सहयोग वैशिष्ट्यांसह एक अनुप्रयोग विकसित करत होतो. हा एक वापरकर्ता-अनुकूल प्रायोगिक स्टॅक होता ज्याने लवकर प्रतिक्रिया आणि CouchDB च्या पूर्ण क्षमतेचा फायदा घेतला. हे JSON द्वारे रिअल टाइममध्ये डेटा समक्रमित करते OT. हे कंपनीमध्ये अंतर्गत वापरले गेले होते, परंतु इतर क्षेत्रांमध्ये त्याची व्यापक लागूता आणि संभाव्यता स्पष्ट होती.

हे तंत्रज्ञान संभाव्य ग्राहकांना विकण्याचा प्रयत्न करत असताना, आम्हाला एक अनपेक्षित अडथळा आला. डेमो व्हिडिओमध्ये, आमची तंत्रज्ञान दिसली आणि उत्तम काम करते, तेथे कोणतीही समस्या नाही. व्हिडिओने ते कसे कार्य करते ते दर्शविले आणि कशाचेही अनुकरण केले नाही. आम्ही प्रोग्राम वापरण्यासाठी एक वास्तववादी परिस्थिती घेऊन आलो आणि कोड केले.


खरं तर, ही समस्या बनली. आमच्या डेमोने इतर सर्वांनी त्यांच्या ऍप्लिकेशन्सचे नक्कल केल्याप्रमाणे कार्य केले. विशेषत:, माहिती तात्काळ A मधून B मध्ये हस्तांतरित केली गेली, जरी ती मोठ्या मीडिया फाइल्स असली तरीही. लॉग इन केल्यानंतर, प्रत्येक वापरकर्त्याने नवीन नोंदी पाहिल्या. ॲप्लिकेशनचा वापर करून, गावात कुठेतरी इंटरनेट कनेक्शन व्यत्यय आला असला तरीही, भिन्न वापरकर्ते समान प्रकल्पांवर स्पष्टपणे एकत्र काम करू शकतात. After Effects मध्ये कट केलेल्या कोणत्याही उत्पादनाच्या व्हिडिओमध्ये हे स्पष्टपणे निहित आहे.

रीफ्रेश बटण कशासाठी आहे हे प्रत्येकाला माहित असले तरीही, त्यांनी आम्हाला तयार करण्यास सांगितलेले वेब अनुप्रयोग सहसा त्यांच्या स्वतःच्या मर्यादांच्या अधीन होते हे कोणालाही खरोखर समजले नाही. आणि ते यापुढे आवश्यक नसल्यास, वापरकर्ता अनुभव पूर्णपणे भिन्न असेल. त्यांच्या लक्षात आले की ते ज्या लोकांशी बोलत होते त्यांच्यासाठी नोट्स टाकून ते “चॅट” करू शकतात, म्हणून त्यांना आश्चर्य वाटले की हे कसे वेगळे आहे, उदाहरणार्थ, स्लॅक. ओफ्फ!

दैनंदिन समक्रमणांची रचना

जर तुम्हाला सॉफ्टवेअर डेव्हलपमेंटचा अनुभव असेल, तर हे लक्षात ठेवणे खूप त्रासदायक असेल की बहुतेक लोक फक्त इंटरफेसचे चित्र पाहू शकत नाहीत आणि त्याच्याशी संवाद साधताना ते काय करेल हे समजू शकत नाही. कार्यक्रमातच काय होते ते सांगायला नको. ते जाण हे करू शकता घडणे हे मुख्यतः काय होऊ शकत नाही आणि काय होऊ नये हे जाणून घेण्याचा परिणाम आहे. यासाठी आवश्यक आहे मानसिक मॉडेल सॉफ्टवेअर काय करते हेच नाही तर त्याचे वैयक्तिक भाग एकमेकांशी कसे समन्वयित आणि संवाद साधतात.

याचे उत्कृष्ट उदाहरण म्हणजे a कडे पाहणारा वापरकर्ता स्पिनर.gif, शेवटी काम कधी पूर्ण होणार असा प्रश्न पडतो. विकासकाला हे समजले असेल की प्रक्रिया कदाचित अडकली आहे आणि जीआयएफ स्क्रीनवरून कधीही अदृश्य होणार नाही. हे अॅनिमेशन नोकरीच्या अंमलबजावणीचे अनुकरण करते, परंतु त्याच्या स्थितीशी संबंधित नाही. अशा परिस्थितीत, काही तंत्रज्ञांना डोळे फिरवायला आवडतात, वापरकर्त्याच्या गोंधळाच्या प्रमाणात आश्चर्यचकित होतात. तथापि, लक्षात घ्या की त्यापैकी किती फिरत्या घड्याळाकडे निर्देश करतात आणि म्हणतात की ते प्रत्यक्षात स्थिर आहे?

हे रिअल-टाइम मूल्याचे सार आहे. आजकाल, रिअल-टाइम डेटाबेस अजूनही फारच कमी वापरले जातात आणि बरेच लोक त्यांना संशयाने पाहतात. यापैकी बहुतेक डेटाबेस NoSQL शैलीकडे मोठ्या प्रमाणावर झुकतात, म्हणूनच ते सहसा मोंगो-आधारित सोल्यूशन्स वापरतात, जे सर्वोत्तम विसरले जातात. तथापि, माझ्यासाठी याचा अर्थ CouchDB सह आरामात काम करणे, तसेच काही नोकरशहा डेटासह भरू शकतील अशा संरचना डिझाइन करणे शिकणे. मला वाटते की मी माझा वेळ अधिक चांगला वापरत आहे.

पण या पोस्टचा खरा विषय हा आहे जो मी आज वापरत आहे. निवडीनुसार नाही, परंतु उदासीनपणे आणि आंधळेपणाने लागू केलेल्या कॉर्पोरेट धोरणांमुळे. म्हणून मी दोन जवळून संबंधित Google रीअल-टाइम डेटाबेस उत्पादनांची पूर्णपणे निष्पक्ष आणि निःपक्षपाती तुलना प्रदान करेन.

दोघांच्या नावात फायर हा शब्द आहे. एक गोष्ट मला प्रकर्षाने आठवते. माझ्यासाठी दुसरी गोष्ट म्हणजे आगीचा वेगळा प्रकार. मला त्यांची नावे सांगण्याची घाई नाही, कारण एकदा मी असे केले की, आम्ही पहिल्या मोठ्या समस्येला सामोरे जाऊ: नावे.

पहिल्याला म्हणतात फायरबेस रिअल-टाइम डेटाबेस, आणि दुसरा - फायरबेस क्लाउड फायरस्टोअर. ते दोन्ही उत्पादने आहेत फायरबेस सूट Google त्यांचे API अनुक्रमे म्हणतात firebase.database(…) и firebase.firestore(…).

हे घडले कारण रिअल-टाइम डेटाबेस - ते फक्त मूळ आहे फायरबेज 2014 मध्ये Google ने खरेदी करण्यापूर्वी. मग गुगलने समांतर उत्पादन बनवण्याचा निर्णय घेतला प्रत फायरबेस बिग डेटा कंपनीवर आधारित आहे आणि त्याला क्लाउडसह फायरस्टोर म्हणतात. मला आशा आहे की तुम्ही अजून गोंधळलेला नाही. तुम्ही अजूनही गोंधळात असाल तर काळजी करू नका, मी स्वतः लेखाचा हा भाग दहा वेळा पुन्हा लिहिला आहे.

कारण आपल्याला सूचित करणे आवश्यक आहे फायरबेज फायरबेस प्रश्नामध्ये आणि फायरस्टोअर Firebase बद्दलच्या प्रश्नात, किमान काही वर्षांपूर्वी तुम्हाला स्टॅक ओव्हरफ्लोवर समजून घेण्यासाठी.

सर्वात वाईट सॉफ्टवेअर नामकरण अनुभवासाठी पुरस्कार असल्यास, हे निश्चितपणे स्पर्धकांपैकी एक असेल. या नावांमधील हॅमिंग अंतर इतके कमी आहे की ते अनुभवी अभियंत्यांना देखील गोंधळात टाकते ज्यांची बोटे एक नाव टाइप करतात आणि त्यांचे डोके दुसर्याबद्दल विचार करत असतात. या चांगल्या हेतूने केलेल्या योजना आहेत ज्या अयशस्वी होतात; डेटाबेसला आग लागेल ही भविष्यवाणी त्यांनी पूर्ण केली. आणि मी अजिबात मस्करी करत नाहीये. ही नामकरण योजना आणलेल्या व्यक्तीला रक्त, घाम आणि अश्रू आले.

पायरीक विजय

एखाद्याला असे वाटेल की फायरस्टोअर आहे बदली फायरबेस, त्याच्या पुढच्या पिढीचे वंशज, परंतु ते दिशाभूल करणारे असेल. फायरबेससाठी फायरस्टोअर योग्य बदलण्याची हमी नाही. असे दिसते की कोणीतरी त्यातून मनोरंजक सर्वकाही कापून टाकले आणि बाकीचे बहुतेक विविध मार्गांनी गोंधळले.

तथापि, दोन उत्पादनांवर एक झटपट नजर टाकल्यास आपण गोंधळात टाकू शकता: ते समान कार्य करतात असे दिसते, मुळात समान API द्वारे आणि अगदी त्याच डेटाबेस सत्रात. फरक सूक्ष्म आहेत आणि विस्तृत दस्तऐवजीकरणाच्या काळजीपूर्वक तुलनात्मक अभ्यासानेच प्रकट होतात. किंवा जेव्हा तुम्ही फायरबेसवर उत्तम प्रकारे काम करणारा कोड पोर्ट करण्याचा प्रयत्न करत असाल जेणेकरून ते Firestore सह कार्य करेल. तरीही तुम्हाला कळते की तुम्ही रीअल टाइममध्ये माउसने ड्रॅग आणि ड्रॉप करण्याचा प्रयत्न करताच डेटाबेस इंटरफेस उजळतो. मी पुन्हा सांगतो, मी विनोद करत नाही.

फायरबेस क्लायंट या अर्थाने विनम्र आहे की तो बदल बफर करतो आणि शेवटच्या लेखन ऑपरेशनला प्राधान्य देणार्‍या अपडेटचा आपोआप पुन्हा प्रयत्न करतो. तथापि, Firestore ची मर्यादा प्रति दस्तऐवज प्रति वापरकर्ता प्रति सेकंद 1 लेखन ऑपरेशनची आहे आणि ही मर्यादा सर्व्हरद्वारे लागू केली जाते. त्याच्यासोबत काम करत असताना, तुम्ही तुमचा अर्ज तयार करण्याचा प्रयत्न करत असताना देखील, त्याभोवती मार्ग शोधणे आणि अपडेट रेट लिमिटर लागू करणे तुमच्यावर अवलंबून आहे. म्हणजेच, फायरस्टोर हा रिअल-टाइम क्लायंटशिवाय रिअल-टाइम डेटाबेस आहे, जो API वापरून एक म्हणून मास्करेड करतो.

येथे आपल्याला फायरस्टोअरच्या रायझन डी'एट्रेची पहिली चिन्हे दिसू लागतात. मी चुकीचे असू शकते, परंतु मला शंका आहे की Google च्या व्यवस्थापनातील उच्च व्यक्तीने खरेदी केल्यानंतर फायरबेसकडे पाहिले आणि फक्त म्हणाले, “नाही, अरे देवा, नाही. हे अस्वीकार्य आहे. फक्त माझ्या नेतृत्वाखाली नाही."

तो त्याच्या चेंबरमधून प्रकट झाला आणि घोषित केले:

“एक मोठा JSON दस्तऐवज? नाही. तुम्ही स्वतंत्र दस्तऐवजांमध्ये डेटा विभाजित कराल, त्यातील प्रत्येकाचा आकार 1 मेगाबाइटपेक्षा जास्त नसेल."

असे दिसते की अशी मर्यादा कोणत्याही पुरेशी प्रेरित वापरकर्ता बेससह पहिल्या चकमकीमध्ये टिकून राहणार नाही. तुम्हाला माहीत आहे की ते आहे. कामावर, उदाहरणार्थ, आमच्याकडे दीड हजाराहून अधिक सादरीकरणे आहेत आणि हे पूर्णपणे सामान्य आहे.

या मर्यादेसह, तुम्हाला हे सत्य स्वीकारण्यास भाग पाडले जाईल की डेटाबेसमधील एक "दस्तऐवज" वापरकर्ता दस्तऐवज म्हणू शकेल अशा कोणत्याही वस्तूसारखे दिसणार नाही.

"अरेचे अ‍ॅरे ज्यात पुनरावृत्तीने इतर घटक असू शकतात? नाही. अ‍ॅरेमध्ये केवळ निश्चित लांबीच्या वस्तू किंवा संख्या असतील, जसे देवाच्या इच्छेनुसार."

त्यामुळे तुम्ही तुमच्या फायरस्टोअरमध्ये GeoJSON टाकण्याची आशा करत असाल, तर तुम्हाला आढळेल की हे शक्य नाही. एक-आयामी नसलेले काहीही स्वीकार्य नाही. मला आशा आहे की तुम्हाला JSON मध्ये Base64 आणि/किंवा JSON आवडेल.

"JSON HTTP, कमांड लाइन टूल्स किंवा अॅडमिन पॅनेलद्वारे आयात आणि निर्यात करायचे? नाही. तुम्ही फक्त Google Cloud Storage वर डेटा निर्यात आणि आयात करण्यात सक्षम असाल. यालाच आता म्हणतात, मला वाटतं. आणि जेव्हा मी "तुम्ही" म्हणतो तेव्हा मी फक्त त्यांनाच संबोधित करतो ज्यांच्याकडे प्रोजेक्ट ओनर क्रेडेंशियल्स असतात. बाकीचे सगळे जाऊन तिकीट काढू शकतात."

तुम्ही बघू शकता, फायरबेस डेटा मॉडेलचे वर्णन करणे सोपे आहे. यात एक मोठा JSON दस्तऐवज आहे जो JSON की ला URL पथांशी जोडतो. सोबत लिहिल्यास HTTP PUT в / फायरबेस खालीलप्रमाणे आहे:

{
  "hello": "world"
}

द GET /hello परत येईल "world". मुळात ते तुमच्या अपेक्षेप्रमाणे कार्य करते. फायरबेस वस्तूंचा संग्रह /my-collection/:id JSON शब्दकोशाच्या समतुल्य {"my-collection": {...}} रूट मध्ये, त्यातील सामग्री उपलब्ध आहे /my-collection:

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

प्रत्येक इन्सर्टमध्ये टक्कर-मुक्त आयडी असल्यास हे चांगले कार्य करते, ज्यासाठी सिस्टमकडे मानक उपाय आहे.

दुसऱ्या शब्दांत, डेटाबेस 100% JSON(*) सुसंगत आहे आणि HTTP सह उत्तम कार्य करते, जसे की CouchDB. परंतु मुळात तुम्ही ते एका रिअल-टाइम API द्वारे वापरता जे वेबसॉकेट्स, अधिकृतता आणि सबस्क्रिप्शन अ‍ॅबस्ट्रॅक्ट करते. प्रशासक पॅनेलमध्ये दोन्ही क्षमता आहेत, रिअल-टाइम संपादन आणि JSON आयात/निर्यात या दोन्हींना अनुमती देतात. तुम्ही तुमच्या कोडमध्ये असेच केल्यास, तुम्हाला हे लक्षात येईल की पॅच आणि डिफ JSON 90% पर्सिस्टंट स्थिती हाताळण्यासाठी नियमित कार्ये सोडवते तेव्हा किती विशिष्ट कोड वाया जाईल याबद्दल तुम्हाला आश्चर्य वाटेल.

फायरस्टोअर डेटा मॉडेल JSON सारखेच आहे, परंतु काही गंभीर मार्गांनी वेगळे आहे. मी आधीच अ‍ॅरेमध्ये अ‍ॅरे नसल्याचा उल्लेख केला आहे. उप-संग्रहांचे मॉडेल त्यांच्यासाठी प्रथम श्रेणीच्या संकल्पना आहेत, ज्यामध्ये ते समाविष्ट असलेल्या JSON दस्तऐवजापासून वेगळे आहेत. यासाठी कोणतेही रेडीमेड सीरियलायझेशन नसल्यामुळे, डेटा पुनर्प्राप्त करण्यासाठी आणि लिहिण्यासाठी एक विशेष कोड पथ आवश्यक आहे. तुमच्या स्वतःच्या संग्रहांवर प्रक्रिया करण्यासाठी, तुम्हाला तुमच्या स्वतःच्या स्क्रिप्ट्स आणि टूल्स लिहिण्याची आवश्यकता आहे. अ‍ॅडमिन पॅनल तुम्हाला एका वेळी एक फील्ड छोटे बदल करण्याची परवानगी देतो आणि त्यात आयात/निर्यात क्षमता नाही.

त्यांनी रिअल-टाइम NoSQL डेटाबेस घेतला आणि तो स्वयं-सामील आणि वेगळ्या नॉन-JSON स्तंभासह स्लो नॉन-SQL मध्ये बदलला. GraftQL सारखे काहीतरी.

गरम जावा

जर फायरस्टोअर अधिक विश्वासार्ह आणि स्केलेबल असायला हवे होते, तर विडंबना अशी आहे की सरासरी विकसकाने बॉक्सच्या बाहेर फायरबेस निवडण्यापेक्षा कमी विश्वासार्ह उपाय मिळेल. ग्रंपी डेटाबेस अॅडमिनिस्ट्रेटरला ज्या प्रकारच्या सॉफ्टवेअरची आवश्यकता असते त्यासाठी प्रयत्नांची पातळी आणि कौशल्याची क्षमता आवश्यक असते जे उत्पादन ज्या ठिकाणी चांगले असायला हवे होते त्यासाठी अवास्तव असते. विकास साधने आणि प्लेअर नसल्यास HTML5 कॅनव्हास फ्लॅशसाठी अजिबात बदलू शकत नाही यासारखेच आहे. शिवाय, फायरस्टोअर डेटा शुद्धता आणि निर्जंतुकीकरण प्रमाणीकरणाच्या इच्छेमध्ये अडकले आहे जे फक्त सरासरी व्यावसायिक वापरकर्त्यांशी कसे जुळत नाही काम करायला आवडते: त्याच्यासाठी सर्व काही ऐच्छिक आहे, कारण अगदी शेवटपर्यंत सर्व काही मसुदा आहे.

फायरबेसचा मुख्य तोटा असा आहे की क्लायंट त्याच्या वेळेच्या कित्येक वर्षे अगोदर तयार केला गेला होता, बहुतेक वेब विकासकांना अपरिवर्तनीयतेबद्दल माहिती होण्यापूर्वी. यामुळे, फायरबेस असे गृहीत धरते की तुम्ही डेटा बदलाल आणि म्हणून वापरकर्त्याने प्रदान केलेल्या अपरिवर्तनीयतेचा फायदा घेत नाही. याव्यतिरिक्त, ते वापरकर्त्याला पाठवलेल्या स्नॅपशॉटमधील डेटाचा पुनर्वापर करत नाही, ज्यामुळे फरक अधिक कठीण होतो. मोठ्या दस्तऐवजांसाठी, त्याची बदलता येण्याजोगी भिन्न-आधारित व्यवहार यंत्रणा केवळ अपुरी आहे. मित्रांनो, आमच्याकडे आधीच आहे WeakMap JavaScript मध्ये. ते आरामदायक आहे.

जर आपण डेटाला इच्छित आकार दिला आणि झाडे खूप मोठी न केल्यास, ही समस्या दूर केली जाऊ शकते. पण मला उत्सुकता आहे की जर डेव्हलपर्सने डेटाबेस डिझाइनवर काही गंभीर व्यावहारिक सल्ल्यासह अपरिवर्तनीयतेचा वापर केलेला खरोखर चांगला क्लायंट API जारी केला तर फायरबेस अधिक मनोरंजक असेल. त्याऐवजी, जे तुटलेले नाही ते दुरुस्त करण्याचा त्यांनी प्रयत्न केल्याचे दिसले आणि त्यामुळे ते आणखी वाईट झाले.

फायरस्टोअरच्या निर्मितीमागील सर्व तर्क मला माहित नाहीत. ब्लॅक बॉक्सच्या आत निर्माण होणाऱ्या हेतूंबद्दल अंदाज लावणे हा देखील गमतीचा भाग आहे. दोन अत्यंत समान परंतु अतुलनीय डेटाबेसची ही जुळणी अत्यंत दुर्मिळ आहे. हे एखाद्याने विचार केल्यासारखे आहे: "फायरबेस हे फक्त एक फंक्शन आहे जे आम्ही Google क्लाउडमध्ये अनुकरण करू शकतो", परंतु वास्तविक-जगातील गरजा ओळखण्याची किंवा त्या सर्व आवश्यकता पूर्ण करणारे उपयुक्त उपाय तयार करण्याची संकल्पना अद्याप शोधली नाही. “विकासकांना याचा विचार करू द्या. फक्त UI सुंदर बनवा... तुम्ही आणखी आग जोडू शकता का?"

मला डेटा स्ट्रक्चर्सबद्दल काही गोष्टी समजतात. डेटाबेसमधून मोठ्या आकाराच्या संरचनेची कोणतीही भावना अमूर्त करण्याचा प्रयत्न म्हणून मी "एका मोठ्या JSON झाडात सर्वकाही" संकल्पना निश्चितपणे पाहतो. कोणत्याही संशयास्पद डेटा स्ट्रक्चर फ्रॅक्टलचा सामना करण्यासाठी सॉफ्टवेअरची अपेक्षा करणे केवळ वेडेपणा आहे. गोष्टी किती वाईट असू शकतात याची मला कल्पनाही करायची नाही, मी कठोर कोड ऑडिट केले आहेत आणि मी अशा गोष्टी पाहिल्या ज्या तुम्ही लोकांनी कधी स्वप्नातही पाहिल्या नव्हत्या. पण मला हे देखील माहित आहे की चांगल्या रचना कशा दिसतात, ते कसे वापरावे и हे का केले पाहिजे. मी अशा जगाची कल्पना करू शकतो जिथे Firestore तार्किक वाटेल आणि ज्या लोकांनी ते तयार केले त्यांना वाटते की त्यांनी चांगले काम केले आहे. पण आपण या जगात राहत नाही.

फायरबेसचे क्वेरी समर्थन कोणत्याही मानकानुसार खराब आहे आणि व्यावहारिकदृष्ट्या अस्तित्वात नाही. त्यात निश्चितच सुधारणा किंवा किमान सुधारणा आवश्यक आहे. परंतु फायरस्टोर अधिक चांगले नाही कारण ते साध्या SQL मध्ये आढळणाऱ्या समान एक-आयामी निर्देशांकांपुरते मर्यादित आहे. लोक गोंधळलेल्या डेटावर चालत असलेल्या प्रश्नांची तुम्हाला आवश्यकता असल्यास, तुम्हाला पूर्ण-मजकूर शोध, बहु-श्रेणी फिल्टर आणि सानुकूल वापरकर्ता-परिभाषित ऑर्डरिंग आवश्यक आहे. जवळून तपासणी केल्यावर, साध्या SQL ची कार्ये स्वतःहून खूप मर्यादित आहेत. याव्यतिरिक्त, लोक उत्पादनात चालवू शकणार्‍या फक्त SQL क्वेरी जलद क्वेरी आहेत. तुम्हाला स्मार्ट डेटा स्ट्रक्चर्ससह सानुकूल अनुक्रमणिका समाधानाची आवश्यकता असेल. इतर सर्व गोष्टींसाठी, किमान वाढीव नकाशा-कमी किंवा तत्सम काहीतरी असावे.

तुम्ही याबद्दल माहितीसाठी Google डॉक्स शोधल्यास, तुम्हाला आशा आहे की BigTable आणि BigQuery सारख्या दिशेने निर्देशित केले जाईल. तथापि, या सर्व सोल्यूशन्समध्ये इतके दाट कॉर्पोरेट विक्री शब्द आहे की तुम्ही पटकन मागे वळून काहीतरी वेगळे शोधू शकाल.

रिअल-टाइम डेटाबेससह तुम्हाला हवी असलेली शेवटची गोष्ट म्हणजे व्यवस्थापन वेतन स्केलवरील लोकांद्वारे आणि त्यांच्यासाठी बनवलेले काहीतरी.

(*) हा एक विनोद आहे, असे काही नाही 100% JSON सुसंगत.

जाहिरातींच्या अधिकारांवर

शोधत आहे व्हीडीएस डीबगिंग प्रकल्पांसाठी, विकास आणि होस्टिंगसाठी सर्व्हर? तुम्ही निश्चितपणे आमचे क्लायंट आहात 🙂 विविध कॉन्फिगरेशनच्या सर्व्हरसाठी दैनंदिन किंमत, अँटी-डीडीओएस आणि विंडोज परवाने आधीच किंमतीमध्ये समाविष्ट केले आहेत.

स्त्रोत: www.habr.com