இந்த தரவுத்தளம் தீயில் உள்ளது...

ஒரு தொழில்நுட்பக் கதையைச் சொல்கிறேன்.

பல ஆண்டுகளுக்கு முன்பு, நான் அதில் உள்ளமைக்கப்பட்ட ஒத்துழைப்பு அம்சங்களுடன் ஒரு பயன்பாட்டை உருவாக்கிக்கொண்டிருந்தேன். இது ஆரம்பகால ரியாக்ட் மற்றும் CouchDB இன் முழு திறனைப் பயன்படுத்திக் கொண்ட ஒரு பயனர் நட்பு சோதனை ஸ்டாக் ஆகும். இது JSON வழியாக நிகழ்நேரத்தில் தரவை ஒத்திசைக்கிறது OT. இது நிறுவனத்திற்குள் உள்நாட்டில் பயன்படுத்தப்பட்டது, ஆனால் மற்ற பகுதிகளில் அதன் பரந்த பொருந்தக்கூடிய தன்மை மற்றும் சாத்தியம் தெளிவாக இருந்தது.

சாத்தியமான வாடிக்கையாளர்களுக்கு இந்த தொழில்நுட்பத்தை விற்க முயற்சிக்கும் போது, ​​எதிர்பாராத தடையை நாங்கள் சந்தித்தோம். டெமோ வீடியோவில், எங்கள் தொழில்நுட்பம் நன்றாக வேலை செய்தது, எந்த பிரச்சனையும் இல்லை. வீடியோ எவ்வாறு செயல்படுகிறது என்பதை சரியாகக் காட்டியது மற்றும் எதையும் பின்பற்றவில்லை. நிரலைப் பயன்படுத்துவதற்கான யதார்த்தமான காட்சியைக் கொண்டு வந்து குறியிட்டோம்.


உண்மையில் இதுவே பிரச்சனையாக மாறியது. அனைவரும் தங்கள் பயன்பாடுகளை உருவகப்படுத்திய விதத்தில் எங்கள் டெமோ சரியாக வேலை செய்தது. குறிப்பாக, பெரிய மீடியா கோப்புகளாக இருந்தாலும், தகவல் உடனடியாக A இலிருந்து Bக்கு மாற்றப்படும். உள்நுழைந்த பிறகு, ஒவ்வொரு பயனரும் புதிய உள்ளீடுகளைப் பார்த்தனர். பயன்பாட்டைப் பயன்படுத்தி, கிராமத்தில் எங்காவது இணைய இணைப்பு துண்டிக்கப்பட்டாலும், வெவ்வேறு பயனர்கள் ஒரே திட்டங்களில் தெளிவாக இணைந்து செயல்பட முடியும். விளைவுகளுக்குப் பின் உள்ள எந்தவொரு தயாரிப்பு வீடியோ வெட்டிலும் இது மறைமுகமாக குறிக்கப்படுகிறது.

புதுப்பிப்பு பொத்தான் எதற்காக என்று அனைவருக்கும் தெரிந்திருந்தாலும், அவர்கள் எங்களிடம் உருவாக்கக் கேட்ட வலை பயன்பாடுகள் பொதுவாக அவற்றின் சொந்த வரம்புகளுக்கு உட்பட்டவை என்பதை யாரும் புரிந்து கொள்ளவில்லை. அவை இனி தேவைப்படாவிட்டால், பயனர் அனுபவம் முற்றிலும் வேறுபட்டதாக இருக்கும். அவர்கள் பேசும் நபர்களுக்கு குறிப்புகளை விட்டுவிட்டு "அரட்டை" செய்ய முடியும் என்பதை அவர்கள் பெரும்பாலும் கவனித்தனர், எனவே இது எடுத்துக்காட்டாக, ஸ்லாக்கிலிருந்து எவ்வாறு வேறுபட்டது என்று அவர்கள் ஆச்சரியப்பட்டனர். அச்சச்சோ!

தினசரி ஒத்திசைவுகளின் வடிவமைப்பு

மென்பொருள் மேம்பாட்டில் உங்களுக்கு அனுபவம் இருந்தால், பெரும்பாலான மக்கள் ஒரு இடைமுகத்தின் படத்தைப் பார்த்து, அதனுடன் தொடர்பு கொள்ளும்போது அது என்ன செய்யும் என்பதைப் புரிந்து கொள்ள முடியாது என்பதை நினைவில் கொள்வது மிகவும் வேதனையாக இருக்க வேண்டும். நிரலுக்குள் என்ன நடக்கிறது என்று குறிப்பிடவில்லை. என்று அறிவு முடியும் எது நடக்கக் கூடாது, எது நடக்கக் கூடாது என்பதைத் தெரிந்துகொள்வதன் விளைவுதான் பெரும்பாலும் நிகழ்வது. இது தேவைப்படுகிறது மன மாதிரி மென்பொருள் என்ன செய்கிறது என்பது மட்டுமல்லாமல், அதன் தனிப்பட்ட பாகங்கள் எவ்வாறு ஒருங்கிணைக்கப்படுகின்றன மற்றும் ஒருவருக்கொருவர் தொடர்பு கொள்கின்றன.

இதற்கு ஒரு உன்னதமான உதாரணம், ஒரு பயனர் உற்று நோக்குவது spinner.gif, வேலை எப்போது முடிவடையும் என்று யோசித்தேன். டெவலப்பர் இந்த செயல்முறை சிக்கியிருக்கலாம் மற்றும் gif திரையில் இருந்து மறைந்துவிடாது என்பதை உணர்ந்திருப்பார். இந்த அனிமேஷன் ஒரு வேலையைச் செயல்படுத்துவதை உருவகப்படுத்துகிறது, ஆனால் அதன் நிலையுடன் தொடர்புடையது அல்ல. இதுபோன்ற சந்தர்ப்பங்களில், சில தொழில்நுட்ப வல்லுநர்கள் தங்கள் கண்களை உருட்ட விரும்புகிறார்கள், பயனர் குழப்பத்தின் அளவைக் கண்டு ஆச்சரியப்படுகிறார்கள். இருப்பினும், அவர்களில் எத்தனை பேர் சுழலும் கடிகாரத்தை சுட்டிக்காட்டி அது உண்மையில் நிலையானது என்று கூறுகிறார்கள் என்பதைக் கவனியுங்கள்?

இதுவே உண்மையான நேர மதிப்பின் சாராம்சம். இந்த நாட்களில், நிகழ்நேர தரவுத்தளங்கள் இன்னும் குறைவாகவே பயன்படுத்தப்படுகின்றன, மேலும் பலர் அவற்றை சந்தேகத்துடன் பார்க்கிறார்கள். இந்த தரவுத்தளங்களில் பெரும்பாலானவை NoSQL பாணியை நோக்கி பெரிதும் சாய்ந்துள்ளன, அதனால்தான் அவை பொதுவாக மோங்கோ அடிப்படையிலான தீர்வுகளைப் பயன்படுத்துகின்றன, அவை சிறப்பாக மறந்துவிடுகின்றன. இருப்பினும், என்னைப் பொறுத்தவரை இது CouchDB உடன் பணிபுரிவது வசதியானது, மேலும் சில அதிகாரத்துவத்தை விட அதிகமான தரவுகளை நிரப்பக்கூடிய கட்டமைப்புகளை வடிவமைக்க கற்றுக்கொள்வது. நான் எனது நேரத்தை சிறப்பாக பயன்படுத்துகிறேன் என்று நினைக்கிறேன்.

ஆனால் இந்த இடுகையின் உண்மையான தலைப்பு நான் இன்று பயன்படுத்துகிறேன். விருப்பத்தால் அல்ல, மாறாக அலட்சியமாகவும் கண்மூடித்தனமாகவும் கார்ப்பரேட் கொள்கைகளைப் பயன்படுத்துவதால். எனவே இரண்டு நெருங்கிய தொடர்புடைய Google நிகழ்நேர தரவுத்தள தயாரிப்புகளின் முற்றிலும் நியாயமான மற்றும் பக்கச்சார்பற்ற ஒப்பீட்டை வழங்குகிறேன்.

இருவரின் பெயரிலும் நெருப்பு என்ற சொல் உள்ளது. ஒன்றை நான் அன்புடன் நினைவில் கொள்கிறேன். எனக்கு இரண்டாவது விஷயம் வேறு வகையான நெருப்பு. அவர்களின் பெயர்களைச் சொல்ல எனக்கு எந்த அவசரமும் இல்லை, ஏனென்றால் நான் அதைச் சொன்னால், நாங்கள் முதல் பெரிய பிரச்சனையில் சிக்குவோம்: பெயர்கள்.

முதலாவது அழைக்கப்படுகிறது ஃபயர்பேஸ் நிகழ்நேர தரவுத்தளம், மற்றும் இரண்டாவது - Firebase Cloud Firestore. இவை இரண்டும் தயாரிப்புகள் ஃபயர்பேஸ் தொகுப்பு கூகிள். அவற்றின் APIகள் முறையே அழைக்கப்படுகின்றன firebase.database(…) и firebase.firestore(…).

ஏனெனில் இது நடந்தது நிகழ்நேர தரவுத்தளம் - இது அசல் தான் Firebase 2014 இல் கூகுள் வாங்குவதற்கு முன். பின்னர் கூகுள் இணை தயாரிப்பாக உருவாக்க முடிவு செய்தது நகல் பிக் டேட்டா நிறுவனத்தை அடிப்படையாகக் கொண்ட ஃபயர்பேஸ், அதை மேகத்துடன் கூடிய ஃபயர்ஸ்டோர் என்று அழைத்தது. நீங்கள் இன்னும் குழப்பமடையவில்லை என்று நம்புகிறேன். நீங்கள் இன்னும் குழப்பமாக இருந்தால், கவலைப்பட வேண்டாம், கட்டுரையின் இந்த பகுதியை நானே பத்து முறை மீண்டும் எழுதினேன்.

ஏனெனில் நீங்கள் குறிப்பிட வேண்டும் Firebase ஃபயர்பேஸ் கேள்வியில், மற்றும் நெருப்புக் கடை ஃபயர்பேஸ் பற்றிய ஒரு கேள்வியில், குறைந்தபட்சம் சில ஆண்டுகளுக்கு முன்பு ஸ்டாக் ஓவர்ஃப்ளோவைப் பற்றி உங்களுக்குப் புரிய வைக்க வேண்டும்.

மோசமான மென்பொருள் பெயரிடும் அனுபவத்திற்கான விருது இருந்தால், இது நிச்சயமாக போட்டியாளர்களில் ஒருவராக இருக்கும். இந்தப் பெயர்களுக்கு இடையே உள்ள ஹேமிங் தூரம் மிகவும் சிறியது, இது அனுபவம் வாய்ந்த பொறியாளர்களைக் கூட குழப்புகிறது, அவர்களின் தலைகள் மற்றொரு பெயரைப் பற்றி சிந்திக்கும்போது விரல்களால் ஒரு பெயரைத் தட்டச்சு செய்யும். இவை நல்ல எண்ணம் கொண்ட திட்டங்கள், அவை மோசமாக தோல்வியடைகின்றன; தரவுத்தளம் தீயில் எரியும் என்ற தீர்க்கதரிசனத்தை அவர்கள் நிறைவேற்றினர். மேலும் நான் கேலி செய்யவில்லை. இந்தப் பெயரிடும் திட்டத்தைக் கொண்டு வந்தவர் ரத்தம், வியர்வை, கண்ணீர்.

பைரிக் வெற்றி

ஃபயர்ஸ்டோர் என்று ஒருவர் நினைக்கலாம் மாற்று ஃபயர்பேஸ், அதன் அடுத்த தலைமுறை வழித்தோன்றல், ஆனால் அது தவறாக வழிநடத்தும். Firebase க்கு பொருத்தமான மாற்றாக Firestore உத்தரவாதம் அளிக்கப்படவில்லை. யாரோ அதிலிருந்து சுவாரஸ்யமான அனைத்தையும் வெட்டி, மீதமுள்ளவற்றை பல்வேறு வழிகளில் குழப்பியது போல் தெரிகிறது.

இருப்பினும், இரண்டு தயாரிப்புகளையும் விரைவாகப் பார்ப்பது உங்களைக் குழப்பலாம்: அடிப்படையில் ஒரே APIகள் மற்றும் ஒரே தரவுத்தள அமர்வில் கூட அவை ஒரே செயலைச் செய்வதாகத் தெரிகிறது. வேறுபாடுகள் நுட்பமானவை மற்றும் விரிவான ஆவணங்களை கவனமாக ஒப்பிட்டு ஆய்வு செய்வதன் மூலம் மட்டுமே வெளிப்படுத்தப்படுகின்றன. அல்லது ஃபயர்பேஸில் சரியாக வேலை செய்யும் குறியீட்டை போர்ட் செய்ய முயற்சிக்கும்போது, ​​அது ஃபயர்ஸ்டோருடன் வேலை செய்யும். நீங்கள் உண்மையான நேரத்தில் மவுஸைக் கொண்டு இழுத்து விட முயற்சித்தவுடன் தரவுத்தள இடைமுகம் ஒளிரும் என்பதை நீங்கள் கண்டுபிடிப்பீர்கள். நான் மீண்டும் சொல்கிறேன், நான் கேலி செய்யவில்லை.

Firebase கிளையண்ட், மாற்றங்களைத் தாங்கி, கடைசியாக எழுதும் செயல்பாட்டிற்கு முன்னுரிமை அளிக்கும் புதுப்பிப்புகளை தானாகவே மீண்டும் முயற்சிக்கும் வகையில் கண்ணியமாக இருக்கிறது. இருப்பினும், Firestore ஒரு வினாடிக்கு ஒரு பயனருக்கு ஒரு ஆவணத்திற்கு 1 எழுதும் செயல்பாடு என்ற வரம்பைக் கொண்டுள்ளது, மேலும் இந்த வரம்பு சேவையகத்தால் செயல்படுத்தப்படுகிறது. அதனுடன் பணிபுரியும் போது, ​​உங்கள் பயன்பாட்டை உருவாக்க முயற்சிக்கும்போது கூட, அதைச் சுற்றி ஒரு வழியைக் கண்டுபிடித்து, புதுப்பிப்பு விகித வரம்பைச் செயல்படுத்துவது உங்களுடையது. அதாவது, ஃபயர்ஸ்டோர் என்பது நிகழ்நேர கிளையன்ட் இல்லாத ஒரு நிகழ்நேர தரவுத்தளமாகும், இது API ஐப் பயன்படுத்தும் ஒன்றாக மாறுகிறது.

இங்கே நாம் Firestore இன் raison d'être இன் முதல் அறிகுறிகளைக் காணத் தொடங்குகிறோம். நான் தவறாக இருக்கலாம், ஆனால் கூகுளின் நிர்வாகத்தில் உள்ள ஒருவர் வாங்கிய பிறகு Firebase ஐப் பார்த்து, “இல்லை, கடவுளே, இல்லை. இது ஏற்றுக்கொள்ள முடியாதது. என் தலைமையின் கீழ் இல்லை."

அவர் தனது அறையிலிருந்து தோன்றி அறிவித்தார்:

“ஒரு பெரிய JSON ஆவணமா? இல்லை. நீங்கள் தரவை தனித்தனி ஆவணங்களாகப் பிரிப்பீர்கள், அவை ஒவ்வொன்றும் 1 மெகாபைட் அளவுக்கு அதிகமாக இருக்காது.

போதுமான உந்துதல் பெற்ற பயனர் தளத்துடனான முதல் சந்திப்பில் அத்தகைய வரம்பு நிலைக்காது என்று தெரிகிறது. அது உங்களுக்குத் தெரியும். வேலையில், எடுத்துக்காட்டாக, எங்களிடம் ஒன்றரை ஆயிரத்துக்கும் மேற்பட்ட விளக்கக்காட்சிகள் உள்ளன, இது முற்றிலும் இயல்பானது.

இந்த வரம்புடன், தரவுத்தளத்தில் உள்ள ஒரு "ஆவணம்" ஒரு பயனர் ஒரு ஆவணத்தை அழைக்கும் எந்தவொரு பொருளையும் ஒத்திருக்காது என்ற உண்மையை நீங்கள் ஏற்க வேண்டிய கட்டாயத்தில் உள்ளீர்கள்.

"தொடர்ச்சியாக மற்ற உறுப்புகளைக் கொண்டிருக்கக்கூடிய வரிசைகளின் வரிசைகள்? இல்லை. கடவுள் எண்ணியபடி, வரிசைகளில் நிலையான நீளமான பொருள்கள் அல்லது எண்கள் மட்டுமே இருக்கும்."

எனவே நீங்கள் உங்கள் Firestore இல் GeoJSON ஐப் பயன்படுத்த நினைத்தால், இது சாத்தியமில்லை என்பதை நீங்கள் காண்பீர்கள். ஒரு பரிமாணமில்லாத எதையும் ஏற்றுக்கொள்ள முடியாது. JSON இல் Base64 மற்றும்/அல்லது JSON உங்களுக்கு பிடிக்கும் என நம்புகிறேன்.

"HTTP, கட்டளை வரி கருவிகள் அல்லது நிர்வாக குழு வழியாக JSON இறக்குமதி மற்றும் ஏற்றுமதி? இல்லை. நீங்கள் Google Cloud Storage க்கு மட்டுமே தரவை ஏற்றுமதி மற்றும் இறக்குமதி செய்ய முடியும். அதுதான் இப்போது அழைக்கப்படுகிறது, நான் நினைக்கிறேன். "நீங்கள்" என்று நான் கூறும்போது, ​​திட்ட உரிமையாளர் நற்சான்றிதழ்கள் உள்ளவர்களை மட்டுமே நான் உரையாற்றுகிறேன். மற்ற அனைவரும் சென்று டிக்கெட்டுகளை உருவாக்கலாம்."

நீங்கள் பார்க்க முடியும் என, FireBase தரவு மாதிரி விவரிக்க எளிதானது. இது JSON விசைகளை URL பாதைகளுடன் இணைக்கும் ஒரு பெரிய JSON ஆவணத்தைக் கொண்டுள்ளது. உடன் எழுதினால் HTTP PUT в / ஃபயர்பேஸ் பின்வருமாறு:

{
  "hello": "world"
}

தி GET /hello திரும்பும் "world". அடிப்படையில் நீங்கள் எதிர்பார்ப்பது போலவே இது வேலை செய்கிறது. ஃபயர்பேஸ் பொருள்களின் சேகரிப்பு /my-collection/:id JSON அகராதிக்கு சமமானது {"my-collection": {...}} மூலத்தில், அதன் உள்ளடக்கங்கள் கிடைக்கின்றன /my-collection:

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

ஒவ்வொரு செருகும் மோதலில்லா ஐடியைக் கொண்டிருந்தால், கணினியில் நிலையான தீர்வு இருந்தால், இது நன்றாக வேலை செய்யும்.

வேறு வார்த்தைகளில் கூறுவதானால், தரவுத்தளம் 100% JSON(*) இணக்கமானது மற்றும் CouchDB போன்ற HTTP உடன் சிறப்பாக செயல்படுகிறது. ஆனால் அடிப்படையில் நீங்கள் அதை வெப்சாக்கெட்டுகள், அங்கீகாரம் மற்றும் சந்தாக்களை சுருக்கமான நிகழ்நேர API மூலம் பயன்படுத்துகிறீர்கள். நிர்வாக குழு இரண்டு திறன்களையும் கொண்டுள்ளது, நிகழ்நேர எடிட்டிங் மற்றும் JSON இறக்குமதி/ஏற்றுமதி ஆகிய இரண்டையும் அனுமதிக்கிறது. உங்கள் குறியீட்டிலும் நீங்கள் அதையே செய்தால், பேட்ச் மற்றும் டிஃப் JSON நிலையான நிலையைக் கையாளும் வழக்கமான பணிகளில் 90% தீர்க்கிறது என்பதை நீங்கள் உணரும்போது, ​​எவ்வளவு சிறப்புக் குறியீடு வீணடிக்கப்படும் என்று நீங்கள் ஆச்சரியப்படுவீர்கள்.

Firestore தரவு மாதிரி JSON போன்றது, ஆனால் சில முக்கியமான வழிகளில் வேறுபடுகிறது. வரிசைகளுக்குள் வரிசைகள் இல்லாததை நான் ஏற்கனவே குறிப்பிட்டுள்ளேன். துணை சேகரிப்புகளுக்கான மாதிரியானது, அவற்றைக் கொண்டிருக்கும் JSON ஆவணத்திலிருந்து தனித்தனியாக, முதல் வகுப்பு கருத்துகளாக இருக்க வேண்டும். இதற்கான ஆயத்த வரிசைப்படுத்தல் இல்லாததால், தரவை மீட்டெடுக்கவும் எழுதவும் ஒரு சிறப்பு குறியீடு பாதை தேவைப்படுகிறது. உங்கள் சொந்த சேகரிப்புகளைச் செயல்படுத்த, உங்கள் சொந்த ஸ்கிரிப்ட்களையும் கருவிகளையும் எழுத வேண்டும். நிர்வாகி குழு ஒரு நேரத்தில் ஒரு துறையில் சிறிய மாற்றங்களைச் செய்ய உங்களை அனுமதிக்கிறது, மேலும் இறக்குமதி/ஏற்றுமதி திறன்கள் இல்லை.

அவர்கள் ஒரு நிகழ்நேர NoSQL தரவுத்தளத்தை எடுத்து, தானாக இணைதல் மற்றும் தனி JSON அல்லாத நெடுவரிசையுடன் மெதுவாக SQL அல்லாததாக மாற்றினர். GraftQL போன்ற ஒன்று.

சூடான ஜாவா

ஃபயர்ஸ்டோர் மிகவும் நம்பகமானதாகவும், அளவிடக்கூடியதாகவும் இருக்க வேண்டும் என்றால், நகைச்சுவை என்னவென்றால், சராசரி டெவலப்பர், ஃபயர்பேஸைப் பெட்டியிலிருந்து தேர்வு செய்வதைக் காட்டிலும் குறைவான நம்பகமான தீர்வைப் பெறுவார். Grumpy Database Administratorக்கு தேவைப்படும் மென்பொருளுக்கு ஒரு அளவிலான முயற்சி மற்றும் திறமையின் திறன் தேவைப்படுகிறது, இது தயாரிப்பு சிறப்பாக இருக்க வேண்டிய முக்கியத்துவத்திற்கு உண்மையற்றது. டெவலப்மென்ட் டூல்ஸ் மற்றும் பிளேயர் இல்லாவிட்டால் HTML5 கேன்வாஸ் எப்படி ஃப்ளாஷுக்கு மாற்றாக இருக்காது என்பதைப் போன்றது இது. மேலும், ஃபயர்ஸ்டோர் தரவுத் தூய்மை மற்றும் மலட்டுச் சரிபார்ப்புக்கான விருப்பத்தில் மூழ்கியுள்ளது, இது சராசரி வணிகப் பயனருடன் ஒத்துப்போகாது. வேலை செய்ய விரும்புகிறார்: அவருக்கு எல்லாம் விருப்பமானது, ஏனென்றால் கடைசி வரை எல்லாமே வரைவுதான்.

ஃபயர்பேஸின் முக்கிய தீமை என்னவென்றால், கிளையன்ட் அதன் நேரத்திற்கு பல ஆண்டுகளுக்கு முன்பே உருவாக்கப்பட்டது, பெரும்பாலான வலை உருவாக்குநர்கள் மாறாத தன்மையைப் பற்றி அறிவதற்கு முன்பே. இதன் காரணமாக, நீங்கள் தரவை மாற்றுவீர்கள் என்று FireBase கருதுகிறது, எனவே பயனர் வழங்கிய மாறாத தன்மையைப் பயன்படுத்திக் கொள்ளாது. கூடுதலாக, இது பயனருக்கு அனுப்பும் ஸ்னாப்ஷாட்களில் உள்ள தரவை மீண்டும் பயன்படுத்தாது, இது வேறுபாட்டை மிகவும் கடினமாக்குகிறது. பெரிய ஆவணங்களுக்கு, அதன் மாறக்கூடிய வேறுபாடு அடிப்படையிலான பரிவர்த்தனை வழிமுறை போதுமானதாக இல்லை. நண்பர்களே, எங்களிடம் ஏற்கனவே உள்ளது WeakMap ஜாவாஸ்கிரிப்டில். வசதியாக இருக்கிறது.

நீங்கள் தரவுக்கு தேவையான வடிவத்தை அளித்து, மரங்களை மிகவும் பெரியதாக மாற்றவில்லை என்றால், இந்த சிக்கலைத் தவிர்க்கலாம். ஆனால் டெவலப்பர்கள் ஒரு நல்ல கிளையன்ட் API ஐ வெளியிட்டால், ஃபயர்பேஸ் மிகவும் சுவாரஸ்யமாக இருக்குமா என்று நான் ஆர்வமாக உள்ளேன், இது தரவுத்தள வடிவமைப்பில் சில தீவிர நடைமுறை ஆலோசனைகளுடன் இணைந்து மாறாத தன்மையைப் பயன்படுத்துகிறது. அதற்கு பதிலாக, அவர்கள் உடைக்கப்படாததை சரிசெய்ய முயற்சிப்பது போல் தோன்றியது, மேலும் அது மோசமாகிவிட்டது.

ஃபயர்ஸ்டோர் உருவாக்கத்தின் பின்னணியில் உள்ள அனைத்து தர்க்கங்களும் எனக்குத் தெரியாது. கருப்புப் பெட்டிக்குள் எழும் நோக்கங்களைப் பற்றி ஊகிப்பதும் வேடிக்கையின் ஒரு பகுதியாகும். இரண்டு மிகவும் ஒத்த ஆனால் ஒப்பிடமுடியாத தரவுத்தளங்களின் இந்த இணைப்பு மிகவும் அரிதானது. யாரோ நினைத்தது போல் உள்ளது: "ஃபயர்பேஸ் என்பது Google கிளவுட்டில் நாம் பின்பற்றக்கூடிய ஒரு செயல்பாடு மட்டுமே", ஆனால் நிஜ-உலகத் தேவைகளை அடையாளம் காண்பது அல்லது அந்தத் தேவைகள் அனைத்தையும் பூர்த்தி செய்யும் பயனுள்ள தீர்வுகளை உருவாக்குவது போன்ற கருத்தை இன்னும் கண்டுபிடிக்கவில்லை. "டெவலப்பர்கள் அதைப் பற்றி சிந்திக்கட்டும். UI ஐ அழகாக்குங்கள்... மேலும் நெருப்பை சேர்க்க முடியுமா?”

தரவு கட்டமைப்புகளைப் பற்றிய சில விஷயங்களை நான் புரிந்துகொள்கிறேன். "ஒரு பெரிய JSON மரத்தில் உள்ள அனைத்தும்" என்ற கருத்தை நான் நிச்சயமாக தரவுத்தளத்திலிருந்து பெரிய அளவிலான கட்டமைப்பின் எந்த உணர்வையும் சுருக்கிக் கொள்ளும் முயற்சியாகவே பார்க்கிறேன். எந்தவொரு சந்தேகத்திற்குரிய தரவு கட்டமைப்பையும் சமாளிக்க மென்பொருள் எதிர்பார்ப்பது வெறுமனே பைத்தியக்காரத்தனமானது. விஷயங்கள் எவ்வளவு மோசமானவை என்று நான் கற்பனை செய்து பார்க்க வேண்டியதில்லை, நான் கடுமையான குறியீடு தணிக்கைகளை செய்துள்ளேன். நீங்கள் கனவிலும் நினைக்காத விஷயங்களை நான் பார்த்தேன். ஆனால் நல்ல கட்டமைப்புகள் எப்படி இருக்கும் என்பதையும் நான் அறிவேன். அவற்றை எவ்வாறு பயன்படுத்துவது и இதை ஏன் செய்ய வேண்டும். ஃபயர்ஸ்டோர் தர்க்கரீதியாகத் தோன்றும் மற்றும் அதை உருவாக்கியவர்கள் தாங்கள் ஒரு நல்ல வேலையைச் செய்ததாக நினைக்கும் ஒரு உலகத்தை என்னால் கற்பனை செய்து பார்க்க முடிகிறது. ஆனால் நாம் இவ்வுலகில் வாழவில்லை.

ஃபயர்பேஸின் வினவல் ஆதரவு எந்த தரநிலையிலும் மோசமாக உள்ளது மற்றும் நடைமுறையில் இல்லை. இதற்கு நிச்சயமாக முன்னேற்றம் அல்லது குறைந்தபட்சம் திருத்தம் தேவை. ஆனால் Firestore மிகவும் சிறப்பாக இல்லை, ஏனெனில் இது எளிய SQL இல் காணப்படும் அதே ஒரு பரிமாண குறியீடுகளுக்கு மட்டுமே. குழப்பமான தரவுகளில் மக்கள் இயங்கும் வினவல்கள் உங்களுக்குத் தேவைப்பட்டால், உங்களுக்கு முழு உரைத் தேடல், பல-வரம்பு வடிப்பான்கள் மற்றும் தனிப்பயன் பயனர் வரையறுக்கப்பட்ட வரிசைப்படுத்தல் தேவை. நெருக்கமான ஆய்வு மூலம், எளிய SQL இன் செயல்பாடுகள் அவற்றின் சொந்தமாக மிகவும் குறைவாகவே உள்ளன. கூடுதலாக, உற்பத்தியில் மக்கள் இயக்கக்கூடிய ஒரே SQL வினவல்கள் வேகமான வினவல்களாகும். ஸ்மார்ட் டேட்டா கட்டமைப்புகளுடன் கூடிய தனிப்பயன் அட்டவணைப்படுத்தல் தீர்வு உங்களுக்குத் தேவைப்படும். மற்ற அனைத்திற்கும், குறைந்தபட்சம் அதிகரிக்கும் வரைபடம்-குறைப்பு அல்லது அது போன்ற ஏதாவது இருக்க வேண்டும்.

இதைப் பற்றிய தகவலை Google டாக்ஸில் தேடினால், BigTable மற்றும் BigQuery போன்றவற்றின் திசையில் நீங்கள் சுட்டிக்காட்டப்படுவீர்கள். இருப்பினும், இந்த தீர்வுகள் அனைத்தும் மிகவும் அடர்த்தியான கார்ப்பரேட் விற்பனை வாசகங்களுடன் உள்ளன, நீங்கள் விரைவாக திரும்பி வேறு எதையாவது தேடத் தொடங்குவீர்கள்.

நிகழ்நேர தரவுத்தளத்துடன் நீங்கள் விரும்பும் கடைசி விஷயம், நிர்வாக ஊதிய விகிதங்களில் உள்ளவர்களால் உருவாக்கப்பட்டதாகும்.

(*) இது ஒரு நகைச்சுவை, அப்படி எதுவும் இல்லை 100% JSON இணக்கமானது.

விளம்பரம் உரிமைகள் மீது

தேடுகிறது விடிஎஸ் பிழைத்திருத்த திட்டங்களுக்கு, மேம்பாடு மற்றும் ஹோஸ்டிங்கிற்கான சர்வர்? நீங்கள் நிச்சயமாக எங்கள் வாடிக்கையாளர் 🙂 பல்வேறு உள்ளமைவுகளின் சேவையகங்களுக்கான தினசரி விலை, எதிர்ப்பு DDoS மற்றும் Windows உரிமங்கள் ஏற்கனவே விலையில் சேர்க்கப்பட்டுள்ளன.

ஆதாரம்: www.habr.com