यो डाटाबेस आगोमा छ ...

एउटा प्राविधिक कथा सुनाऊँ ।

धेरै वर्ष पहिले, मैले यसमा निर्मित सहयोग सुविधाहरूको साथ एउटा अनुप्रयोग विकास गरिरहेको थिएँ। यो एक प्रयोगकर्ता-अनुकूल प्रयोगात्मक स्ट्याक थियो जसले प्रारम्भिक प्रतिक्रिया र CouchDB को पूर्ण क्षमताको फाइदा उठायो। यसले JSON मार्फत वास्तविक समयमा डाटा सिङ्क्रोनाइज गर्छ OT। यो कम्पनी भित्र आन्तरिक रूपमा प्रयोग गरिएको थियो, तर यसको व्यापक लागूता र अन्य क्षेत्रहरूमा सम्भावना स्पष्ट थियो।

सम्भावित ग्राहकहरूलाई यो प्रविधि बेच्ने प्रयास गर्दा, हामीले एक अप्रत्याशित अवरोधको सामना गर्‍यौं। डेमो भिडियोमा, हाम्रो टेक्नोलोजी राम्रो देखियो र काम गर्यो, त्यहाँ कुनै समस्या छैन। भिडियोले ठ्याक्कै देखाएको छ कि यसले कसरी काम गर्दछ र केहि नक्कल गर्दैन। हामी कार्यक्रम प्रयोग गर्नको लागि एक यथार्थपरक परिदृश्यको साथ आएका छौं।


वास्तवमा, यो समस्या भयो। हाम्रो डेमोले ठ्याक्कै त्यसरी काम गर्‍यो जसरी अरू सबैले तिनीहरूका अनुप्रयोगहरू सिमुलेट गरे। विशेष रूपमा, जानकारी तुरुन्तै A बाट B मा स्थानान्तरण गरिएको थियो, भले पनि यो ठूला मिडिया फाइलहरू थिए। लग इन गरेपछि, प्रत्येक प्रयोगकर्ताले नयाँ प्रविष्टिहरू देखे। एप्लिकेसन प्रयोग गरेर, गाउँमा कतै इन्टरनेट जडान अवरुद्ध भए पनि विभिन्न प्रयोगकर्ताहरूले एउटै परियोजनाहरूमा स्पष्ट रूपमा काम गर्न सक्छन्। यो प्रभाव पछि कुनै पनि उत्पादन भिडियो कट मा निहित छ।

रिफ्रेस बटन के हो भन्ने सबैलाई थाहा भएता पनि, उनीहरूले हामीलाई निर्माण गर्न भनेका वेब अनुप्रयोगहरू सामान्यतया तिनीहरूको आफ्नै सीमितताहरूको अधीनमा थिए भनेर कसैले पनि बुझेनन्। र यदि तिनीहरू अब आवश्यक छैन भने, प्रयोगकर्ता अनुभव पूर्ण रूपमा फरक हुनेछ। तिनीहरूले प्रायः याद गरे कि उनीहरूले कुरा गरिरहेका मानिसहरूका लागि नोटहरू छोडेर "च्याट" गर्न सक्छन्, त्यसैले उनीहरूले यो कसरी फरक छ भनेर सोचेका थिए, उदाहरणका लागि, स्ल्याक। ओफ!

दैनिक सिंकको डिजाइन

यदि तपाइँसँग सफ्टवेयर विकासमा अनुभव छ भने, धेरै मानिसहरूले इन्टरफेसको तस्विर मात्र हेर्न सक्दैनन् र योसँग अन्तर्क्रिया गर्दा यसले के गर्छ भनेर बुझ्न सक्दैन भन्ने कुरा याद गर्न यो नर्भ-रेकिङ हुनुपर्छ। कार्यक्रम भित्रै के हुन्छ भनेर उल्लेख नगर्नुहोस्। त्यो जान्नुहोस् गर्न सक्छन् के हुन सक्दैन र के हुनु हुँदैन भन्ने थाहा पाउनुको परिणाम हो। यो आवश्यक छ मानसिक मोडेल सफ्टवेयरले के गर्छ मात्र होइन, तर यसको व्यक्तिगत भागहरू कसरी एकअर्कासँग समन्वय र सञ्चार हुन्छन्।

यसको एक उत्कृष्ट उदाहरण एक प्रयोगकर्ताले हेरिरहेको छ spinner.gifअन्ततः काम कहिले पूरा हुन्छ भन्ने चिन्ता छ। विकासकर्ताले यो प्रक्रिया सम्भवतः अड्किएको थियो र gif स्क्रिनबाट कहिल्यै गायब हुने छैन भनेर महसुस गरेको थियो। यो एनिमेसनले कार्यको कार्यान्वयनलाई अनुकरण गर्दछ, तर यसको राज्यसँग सम्बन्धित छैन। यस्तो अवस्थामा, केही प्राविधिकहरू आफ्ना आँखा घुमाउन मन पराउँछन्, प्रयोगकर्ताको भ्रमको हदमा छक्क पर्छन्। यद्यपि, ध्यान दिनुहोस् कि तिनीहरूमध्ये कतिले घुम्ने घडीलाई औंल्याउँछन् र भन्छन् कि यो वास्तवमा स्थिर छ?

यो वास्तविक समय मूल्य को सार हो। यी दिनहरू, वास्तविक-समय डाटाबेसहरू अझै धेरै कम प्रयोग गरिएका छन् र धेरै मानिसहरूले तिनीहरूलाई शंकाको साथ हेर्छन्। यी धेरै जसो डाटाबेसहरू NoSQL शैली तिर धेरै झुक्छन्, त्यसैले तिनीहरू प्राय: मङ्गो-आधारित समाधानहरू प्रयोग गर्छन्, जुन राम्रो बिर्सिन्छन्। जे होस्, मेरो लागि यसको मतलब CouchDB सँग काम गर्न सहज हुनु हो, साथै संरचनाहरू डिजाइन गर्न सिक्नु हो जुन केवल केहि नोकरशाहले डाटा भर्न सक्छ। मलाई लाग्छ कि म मेरो समय राम्रोसँग सदुपयोग गर्दैछु।

तर यस पोष्टको वास्तविक विषय भनेको मैले आज प्रयोग गरिरहेको छु। छनोटबाट होइन, तर उदासीनता र अन्धाधुन्ध रूपमा लागू कर्पोरेट नीतिहरूको कारण। त्यसोभए म दुई नजिकको सम्बन्धित Google वास्तविक-समय डाटाबेस उत्पादनहरूको पूर्ण रूपमा निष्पक्ष र निष्पक्ष तुलना प्रदान गर्नेछु।

दुबैको नाममा फायर शब्द छ। एउटा कुरा मनले सम्झन्छु । मेरो लागि दोस्रो कुरा फरक प्रकारको आगो हो। म तिनीहरूको नाम भन्न हतारमा छैन, किनकि एक पटक मैले गरेपछि, हामी पहिलो ठूलो समस्यामा जानेछौं: नामहरू।

पहिलो भनिन्छ Firebase वास्तविक समय डाटाबेस, र दोस्रो - फायरबेस क्लाउड फायरस्टोर। ती दुवै उत्पादनहरू हुन् फायरबेस सुइट गूगल। तिनीहरूको API लाई क्रमशः भनिन्छ firebase.database(…) и firebase.firestore(…).

यो कारणले भएको हो वास्तविक समय डाटाबेस - यो केवल मूल हो Firebase 2014 मा Google द्वारा खरिद गर्नु अघि। त्यसपछि गुगलले समानान्तर उत्पादनको रूपमा सिर्जना गर्ने निर्णय गर्यो एक प्रतिलिपि ठूलो डाटा कम्पनीमा आधारित फायरबेस, र यसलाई क्लाउडको साथ फायरस्टोर भनिन्छ। म आशा गर्छु कि तपाई अझै भ्रमित हुनुहुन्न। यदि तपाईं अझै अन्योलमा हुनुहुन्छ भने, चिन्ता नगर्नुहोस्, म आफैले लेखको यो भाग दस पटक पुन: लेखेको छु।

किनकी तपाईले संकेत गर्न आवश्यक छ Firebase फायरबेस प्रश्नमा, र फायरस्टोर Firebase को बारे मा एक प्रश्न मा, कम्तिमा तपाइँ केहि वर्ष पहिले स्ट्याक ओभरफ्लो मा बुझ्न को लागी।

यदि त्यहाँ सबैभन्दा खराब सफ्टवेयर नामकरण अनुभवको लागि पुरस्कार थियो भने, यो निश्चित रूपमा दावेदारहरू मध्ये एक हुनेछ। यी नामहरू बीच ह्यामिङ दूरी यति सानो छ कि यसले अनुभवी इन्जिनियरहरूलाई पनि भ्रमित पार्छ जसको औंलाहरूले एउटा नाम टाइप गर्छन् जबकि तिनीहरूको टाउको अर्कोको बारेमा सोचिरहेको हुन्छ। यी राम्रा नियतका योजनाहरू हुन् जुन नराम्ररी असफल हुन्छन्; तिनीहरूले भविष्यवाणी पूरा गरे कि डाटाबेस आगोमा हुनेछ। र म पटक्कै मजाक गरिरहेको छैन। यो नामकरण योजना ल्याएको व्यक्तिले रगत, पसिना र आँसु बगाएको थियो।

Pyrric विजय

कसैले सोच्दछ कि फायरस्टोर हो प्रतिस्थापन फायरबेस, यसको अर्को पुस्ताको वंशज, तर त्यो भ्रामक हुनेछ। Firestore Firebase को लागि उपयुक्त प्रतिस्थापन हुन ग्यारेन्टी छैन। यस्तो देखिन्छ कि कसैले यसबाट चाखलाग्दो सबै कुरा काट्यो, र धेरै जसो बाँकीलाई विभिन्न तरिकामा अलमलमा पार्यो।

जे होस्, दुई उत्पादनहरूमा द्रुत नजरले तपाईंलाई भ्रमित पार्न सक्छ: तिनीहरू समान रूपमा एउटै एपीआईहरू मार्फत र एउटै डाटाबेस सत्रमा पनि एउटै कुरा गर्छन्। भिन्नताहरू सूक्ष्म छन् र विस्तृत कागजातहरूको सावधानीपूर्वक तुलनात्मक अध्ययनद्वारा मात्र प्रकट हुन्छन्। वा जब तपाइँ फायरबेसमा पूर्ण रूपमा काम गर्ने कोड पोर्ट गर्ने प्रयास गर्दै हुनुहुन्छ ताकि यसले फायरस्टोरसँग काम गर्दछ। तब पनि तपाईले पत्ता लगाउनुहुन्छ कि तपाईले वास्तविक समयमा माउसको साथ ड्र्याग र ड्रप गर्ने प्रयास गर्दा डाटाबेस इन्टरफेस उज्यालो हुन्छ। म दोहोर्याउँछु, म मजाक गरिरहेको छैन।

फायरबेस क्लाइन्ट यस अर्थमा विनम्र छ कि यसले परिवर्तनहरू बफर गर्दछ र स्वचालित रूपमा अद्यावधिकहरू पुन: प्रयास गर्दछ जसले अन्तिम लेखन कार्यलाई प्राथमिकता दिन्छ। यद्यपि, फायरस्टोरमा प्रति प्रयोगकर्ता प्रति सेकेन्ड प्रति कागजात १ लेखन सञ्चालनको सीमा छ, र यो सीमा सर्भरद्वारा लागू गरिएको छ। यसको साथ काम गर्दा, यसको वरिपरि बाटो खोज्न र अद्यावधिक दर सीमितता लागू गर्न तपाईंमा निर्भर छ, जब तपाईं भर्खरै आफ्नो अनुप्रयोग निर्माण गर्ने प्रयास गर्दै हुनुहुन्छ। त्यो हो, फायरस्टोर वास्तविक-समय क्लाइन्ट बिनाको वास्तविक-समय डाटाबेस हो, जुन एपीआई प्रयोग गरेर एकको रूपमा मास्करेड हुन्छ।

यहाँ हामी Firestore को raison d'être को पहिलो संकेतहरू देख्न सुरु गर्छौं। म गलत हुन सक्छु, तर मलाई शंका छ कि गुगलको व्यवस्थापनमा उच्च व्यक्तिले किनेको पछि फायरबेसलाई हेरे र केवल यसो भने, "होइन, हे भगवान, होइन। यो अस्वीकार्य छ। मेरो नेतृत्वमा मात्र होइन।"

उहाँ आफ्नो कोठाबाट देखा पर्नुभयो र घोषणा गर्नुभयो:

"एउटा ठूलो JSON कागजात? छैन। तपाईंले डाटालाई अलग-अलग कागजातहरूमा विभाजन गर्नुहुनेछ, जसमध्ये प्रत्येकको आकार 1 मेगाबाइट भन्दा बढी हुनेछैन।"

यस्तो देखिन्छ कि यस्तो सीमा कुनै पनि पर्याप्त उत्प्रेरित प्रयोगकर्ता आधारको साथ पहिलो मुठभेडमा बाँच्नेछैन। तपाईलाई थाहा छ यो छ। काममा, उदाहरणका लागि, हामीसँग डेढ हजार भन्दा बढी प्रस्तुतीकरणहरू छन्, र यो पूर्ण रूपमा सामान्य छ।

यस सीमितताको साथ, तपाइँ तथ्यलाई स्वीकार गर्न बाध्य हुनुहुनेछ कि डाटाबेसमा एउटा "कागजात" कुनै पनि वस्तुसँग मिल्दोजुल्दो छैन जुन प्रयोगकर्ताले कागजात कल गर्न सक्छ।

"पुनरावर्ती अन्य तत्वहरू समावेश गर्न सक्ने arrays को arrays? छैन। एरेहरूले केवल निश्चित-लम्बाइ वस्तुहरू वा संख्याहरू समावेश गर्दछ, जसरी परमेश्वरले चाहनुभएको थियो।"

त्यसोभए यदि तपाइँ GeoJSON लाई तपाइँको Firestore मा राख्ने आशा गर्दै हुनुहुन्छ भने, तपाइँ पाउनुहुनेछ कि यो सम्भव छैन। गैर-एक-आयामी केहि स्वीकार्य छैन। मलाई आशा छ कि तपाईलाई JSON भित्र Base64 र/वा JSON मन पर्छ।

"JSON आयात र निर्यात HTTP, कमाण्ड लाइन उपकरण वा प्रशासक प्यानल मार्फत? छैन। तपाईं केवल Google क्लाउड भण्डारणमा डाटा निर्यात र आयात गर्न सक्षम हुनुहुनेछ। यसलाई अहिले भनिन्छ, मलाई लाग्छ। र जब म "तपाईं" भन्छु, म परियोजना मालिक प्रमाणहरू भएकाहरूलाई मात्र सम्बोधन गर्दैछु। सबैजना गएर टिकट बनाउन सक्छन्।"

तपाईले देख्न सक्नुहुन्छ, फायरबेस डेटा मोडेल वर्णन गर्न सजिलो छ। यसले JSON कुञ्जीहरूलाई URL पथहरूसँग सम्बद्ध गर्ने एउटा ठूलो JSON कागजात समावेश गर्दछ। यदि तपाईं संग लेख्नुहोस् HTTP PUT в / फायरबेस निम्न हो:

{
  "hello": "world"
}

The GET /hello फर्कने छौ, फर्कने छन् "world"। मूलतया यो तपाईले अपेक्षा गरे जस्तै काम गर्दछ। फायरबेस वस्तुहरूको सङ्कलन /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 जस्तै छ, तर केही महत्वपूर्ण तरिकामा फरक छ। मैले पहिले नै arrays भित्र arrays को अभाव उल्लेख गरेको छु। उप-संकलनहरूको लागि मोडेल तिनीहरूको लागि JSON कागजातबाट अलग, प्रथम श्रेणी अवधारणाहरू हुन्। यसका लागि कुनै रेडिमेड सिरियलाइजेसन नभएकोले, डाटा पुन: प्राप्त गर्न र लेख्नको लागि एक विशेष कोड पथ आवश्यक छ। तपाईंको आफ्नै संग्रहहरू प्रशोधन गर्न, तपाईंले आफ्नै लिपि र उपकरणहरू लेख्न आवश्यक छ। प्रशासक प्यानलले तपाईंलाई एक पटकमा एउटा फिल्डमा सानो परिवर्तनहरू गर्न अनुमति दिन्छ, र आयात/निर्यात क्षमताहरू हुँदैन।

तिनीहरूले वास्तविक-समय NoSQL डाटाबेस लिए र यसलाई ढिलो गैर-SQL मा अटो-जोइन र छुट्टै गैर-JSON स्तम्भमा परिणत गरे। GraftQL जस्तै केहि.

तातो जाभा

यदि फायरस्टोर अधिक भरपर्दो र स्केलेबल भएको मानिएको थियो भने, विडम्बना यो हो कि औसत विकासकर्ताले बाकस बाहिर फायरबेस छनौट गर्नु भन्दा कम भरपर्दो समाधानको साथ समाप्त हुनेछ। ग्रम्पी डाटाबेस प्रशासकलाई आवश्यक पर्ने सफ्टवेयरको लागि प्रयासको स्तर र प्रतिभाको क्यालिबर चाहिन्छ जुन उत्पादन राम्रो मानिने ठाउँको लागि मात्र अवास्तविक छ। यो HTML5 क्यानभास कुनै पनि विकास उपकरण र खेलाडी नभएको खण्डमा फ्ल्याशको लागि प्रतिस्थापन होइन भन्ने समान छ। यसबाहेक, फायरस्टोर डेटा शुद्धता र बाँझ प्रमाणीकरणको चाहनामा फसेको छ जुन औसत व्यापार प्रयोगकर्ता कसरी पङ्क्तिबद्ध गर्दैन। काम गर्न मन पर्छ: उसको लागि सबै कुरा ऐच्छिक छ, किनकि अन्त्यसम्म सबै कुरा मस्यौदा हो।

फायरबेसको मुख्य बेफाइदा यो हो कि क्लाइन्ट आफ्नो समय भन्दा धेरै वर्ष अगाडि सिर्जना गरिएको थियो, धेरै वेब विकासकर्ताहरूलाई अपरिवर्तनीयता बारे थाहा हुनु अघि। यस कारणले गर्दा, FireBase ले तपाईंले डाटा परिवर्तन गर्नुहुनेछ र त्यसैले प्रयोगकर्ताले प्रदान गरेको अपरिवर्तनीयताको फाइदा उठाउँदैन। थप रूपमा, यसले प्रयोगकर्तालाई पास गर्ने स्न्यापशटहरूमा डेटा पुन: प्रयोग गर्दैन, जसले भिन्नतालाई अझ गाह्रो बनाउँछ। ठूला कागजातहरूको लागि, यसको परिवर्तनीय भिन्न-आधारित लेनदेन संयन्त्र मात्र अपर्याप्त छ। साथीहरू, हामीसँग पहिले नै छ WeakMap JavaScript मा। यो सहज छ।

यदि तपाइँ डेटालाई इच्छित आकार दिनुहुन्छ र रूखहरूलाई धेरै ठूलो बनाउनुहुन्न भने, यो समस्यालाई रोक्न सकिन्छ। तर म उत्सुक छु यदि फायरबेस धेरै रोचक हुनेछ यदि विकासकर्ताहरूले डाटाबेस डिजाइनमा केही गम्भीर व्यावहारिक सल्लाहको साथ अपरिवर्तनीयता प्रयोग गर्ने साँच्चै राम्रो ग्राहक एपीआई जारी गरे। बरु, तिनीहरूले के टुटेको थिएन ठीक गर्न प्रयास गरे जस्तो देखिन्थ्यो, र यसले यसलाई अझ खराब बनायो।

मलाई Firestore को सिर्जना पछि सबै तर्क थाहा छैन। ब्ल्याक बक्स भित्र उत्पन्न हुने मनसाय बारे अनुमान लगाउनु पनि रमाइलोको एक हिस्सा हो। दुई अत्यन्त समान तर अतुलनीय डाटाबेसहरूको यो संयोजन एकदम दुर्लभ छ। यो कसैले सोचेको जस्तै छ: "फायरबेस एउटा प्रकार्य हो जुन हामीले गुगल क्लाउडमा अनुकरण गर्न सक्छौं", तर अहिलेसम्म वास्तविक-विश्व आवश्यकताहरू पहिचान गर्ने वा ती सबै आवश्यकताहरू पूरा गर्ने उपयोगी समाधानहरू सिर्जना गर्ने अवधारणा पत्ता लगाएको छैन। "विकासकर्ताहरूलाई यसको बारेमा सोच्न दिनुहोस्। केवल UI सुन्दर बनाउनुहोस्... के तपाईं थप आगो थप्न सक्नुहुन्छ?"

म डाटा संरचना बारे केहि चीजहरू बुझ्छु। म निश्चित रूपमा "एउटा ठूलो JSON रूखमा सबै कुरा" अवधारणालाई डाटाबेसबाट ठूला-ठूला संरचनाको कुनै पनि भावनालाई सार्ने प्रयासको रूपमा देख्छु। कुनै पनि शंकास्पद डाटा संरचना फ्र्याक्टलसँग सामना गर्न सफ्टवेयरको अपेक्षा गर्नु केवल पागल हो। मैले कति नराम्रो चीजहरू हुन सक्छ भनेर कल्पना पनि गर्नुपर्दैन, मैले कठोर कोड अडिटहरू गरेको छु र मैले ती चीजहरू देखेको छु जुन तपाईं मानिसहरूले कहिल्यै सोचेका थिएनन्। तर मलाई यो पनि थाहा छ कि राम्रो संरचनाहरू कस्तो देखिन्छन्, तिनीहरूलाई कसरी प्रयोग गर्ने и यो किन गर्नु पर्छ। म यस्तो संसारको कल्पना गर्न सक्छु जहाँ फायरस्टोर तार्किक देखिन्छ र यसलाई सिर्जना गर्ने मानिसहरूले उनीहरूले राम्रो काम गरे जस्तो लाग्छ। तर हामी यो संसारमा बस्दैनौं।

फायरबेसको क्वेरी समर्थन कुनै पनि मानकले कमजोर छ र व्यावहारिक रूपमा अवस्थित छैन। यसलाई निश्चित रूपमा सुधार वा कम्तिमा संशोधन आवश्यक छ। तर फायरस्टोर धेरै राम्रो छैन किनभने यो सादा SQL मा पाइने समान एक-आयामी अनुक्रमणिकाहरूमा सीमित छ। यदि तपाईलाई प्रश्नहरू चाहिन्छ कि मानिसहरू अराजक डेटामा चल्छन्, तपाईलाई पूर्ण-पाठ खोजी, बहु-दायरा फिल्टरहरू, र अनुकूलन प्रयोगकर्ता-परिभाषित अर्डरिंग चाहिन्छ। नजिकको निरीक्षणमा, सादा SQL को कार्यहरू आफ्नै मा धेरै सीमित छन्। थप रूपमा, केवल SQL क्वेरीहरू उत्पादनमा चलाउन सक्ने व्यक्तिहरू द्रुत प्रश्नहरू हुन्। तपाईंलाई स्मार्ट डेटा संरचनाहरूको साथ अनुकूलन अनुक्रमणिका समाधान चाहिन्छ। अरू सबैको लागि, त्यहाँ कम्तिमा वृद्धिशील नक्सा-घटना वा यस्तै केहि हुनुपर्छ।

यदि तपाइँ यस बारे जानकारीको लागि Google कागजात खोज्नुहुन्छ भने, आशा छ कि तपाइँ BigTable र BigQuery जस्तै केहि दिशामा औंल्याउनुहुनेछ। यद्यपि, यी सबै समाधानहरू यति धेरै घना कर्पोरेट बिक्री शब्दजालको साथमा छन् कि तपाईं छिट्टै पछाडि फर्कनुहुनेछ र अरू केहि खोज्न सुरु गर्नुहुनेछ।

तपाईले वास्तविक-समय डाटाबेसको साथ चाहानु भएको अन्तिम चीज भनेको व्यवस्थापनको तलब स्केलमा भएका व्यक्तिहरूद्वारा र तिनीहरूका लागि बनाइएको हो।

(*) यो एक मजाक हो, यस्तो कुनै चीज छैन 100% JSON उपयुक्त.

विज्ञापनको अधिकारमा

खोज्दै VDS डिबगिङ परियोजनाहरूको लागि, विकास र होस्टिङको लागि सर्भर? तपाईं पक्कै पनि हाम्रो ग्राहक हुनुहुन्छ 🙂 विभिन्न कन्फिगरेसनका सर्भरहरूको दैनिक मूल्य निर्धारण, एन्टी-डीडीओएस र विन्डोज इजाजतपत्रहरू पहिले नै मूल्यमा समावेश गरिएका छन्।

स्रोत: www.habr.com