ይህ ዳታቤዝ በእሳት ላይ ነው...

አንድ ቴክኒካል ታሪክ ልንገራችሁ።

ከብዙ አመታት በፊት፣ በውስጡ አብሮ የተሰሩ የትብብር ባህሪያት መተግበሪያን እያዘጋጀሁ ነበር። ቀደምት React እና CouchDB ሙሉውን አቅም የተጠቀመ ለተጠቃሚ ምቹ የሆነ የሙከራ ቁልል ነበር። በJSON በኩል ውሂብን በቅጽበት አመሳስሏል። OT. በኩባንያው ውስጥ በውስጥ ጥቅም ላይ ውሏል, ነገር ግን ሰፊው ተፈጻሚነት እና በሌሎች አካባቢዎች ያለው እምቅ ችሎታ ግልጽ ነበር.

ይህንን ቴክኖሎጂ ለደንበኞቻችን ለመሸጥ እየሞከርን ሳለ፣ ያልጠበቅነው እንቅፋት አጋጥሞናል። በማሳያ ቪዲዮው ላይ የእኛ ቴክኖሎጂ ጥሩ ይመስላል እና ሰርቷል፣ ምንም ችግር የለም። ቪዲዮው በትክክል እንዴት እንደሚሰራ አሳይቷል እና ምንም ነገር አልኮረሰም. ፕሮግራሙን ለመጠቀም ተጨባጭ ሁኔታን አዘጋጅተናል እና ኮድ ሰጥተናል።


እንዲያውም ይህ ችግር ሆነ። የእኛ ማሳያ ልክ ሁሉም ሰው መተግበሪያዎቻቸውን በሚመስሉበት መንገድ ሰርቷል። በተለይ፣ ምንም እንኳን ትላልቅ የሚዲያ ፋይሎች ቢሆኑም መረጃ ወዲያውኑ ከሀ ወደ ቢ ተላልፏል። ከገቡ በኋላ እያንዳንዱ ተጠቃሚ አዲስ ግቤቶችን አይቷል። አፕሊኬሽኑን በመጠቀም፣ በመንደሩ ውስጥ የሆነ ቦታ የበይነመረብ ግንኙነት ቢቋረጥም የተለያዩ ተጠቃሚዎች በተመሳሳይ ፕሮጀክቶች ላይ በግልፅ አብረው ሊሰሩ ይችላሉ። ይህ በ After Effects ውስጥ በማንኛውም የምርት ቪዲዮ መቁረጥ ላይ በተዘዋዋሪ ይገለጻል።

ምንም እንኳን ሁሉም ሰው የማደስ አዝራሩ ምን እንደሆነ ቢያውቅም፣ እንድንገነባ የጠየቁን የድር መተግበሪያዎች አብዛኛውን ጊዜ ለራሳቸው ውስንነቶች ተገዥ መሆናቸውን ማንም አልተረዳም። እና ከአሁን በኋላ አያስፈልጉም ከሆነ, የተጠቃሚው ልምድ ሙሉ በሙሉ የተለየ ይሆናል. አብዛኛውን ጊዜ ለሚነጋገሩዋቸው ሰዎች ማስታወሻ በመተው "ቻት" ማድረግ እንደሚችሉ አስተውለዋል፣ ስለዚህ ይህ ከSlack እንዴት እንደሚለይ አሰቡ። ፊው!

የዕለት ተዕለት ማመሳሰል ንድፍ

በሶፍትዌር ልማት ላይ ልምድ ካላችሁ፣ ብዙ ሰዎች የበይነገጽን ምስል ብቻ ማየት እንደማይችሉ እና ከእሱ ጋር ሲገናኙ ምን እንደሚሰራ መረዳት እንደማይችሉ ማስታወስ ነርቭ መሆን አለበት። በፕሮግራሙ ውስጥ ምን እንደሚፈጠር ሳይጠቅሱ. ያንን እወቅ ይችላል ሊከሰት የማይችለውንና የማይሆነውን የማወቅ ውጤት ነው። ይህ ይጠይቃል የአዕምሮ ሞዴል ሶፍትዌሩ የሚያደርገውን ብቻ ሳይሆን የነጠላ ክፍሎቹ እንዴት እንደሚቀናጁ እና እርስ በርስ እንደሚግባቡም ጭምር።

ለዚህ ዓይነተኛ ምሳሌ ተጠቃሚው ሀ ላይ እያፈጠጠ ነው። spinner.gif, በመጨረሻ ስራው መቼ እንደሚጠናቀቅ በማሰብ. ገንቢው ሂደቱ ምናልባት ተጣብቆ እንደነበረ እና gif ከስክሪኑ ላይ ፈጽሞ እንደማይጠፋ ይገነዘባል. ይህ አኒሜሽን የስራ አፈጻጸምን ያስመስላል፣ ነገር ግን ከግዛቱ ጋር የተያያዘ አይደለም። በእንደዚህ ዓይነት ሁኔታዎች አንዳንድ ቴክኒኮች በተጠቃሚው ግራ መጋባት መጠን በመገረም ዓይኖቻቸውን ማንከባለል ይወዳሉ። ይሁን እንጂ ስንቶቹ ወደ መዞሪያው ሰዓቱ ጠቁመው በትክክል የቆመ ነው ይላሉ?

ይህ የእውነተኛ ጊዜ እሴት ይዘት ነው። በአሁኑ ጊዜ፣ የእውነተኛ ጊዜ የውሂብ ጎታዎች አሁንም በጣም ጥቂት ጥቅም ላይ ይውላሉ እና ብዙ ሰዎች በጥርጣሬ ይመለከቷቸዋል። አብዛኛዎቹ እነዚህ የውሂብ ጎታዎች ወደ ኖኤስኪኤል ቅጥ ያጋደላሉ፣ ለዚህም ነው አብዛኛውን ጊዜ ሞንጎን መሰረት ያደረጉ መፍትሄዎችን የሚጠቀሙት፣ ይህም በጣም የተረሱ ናቸው። ነገር ግን፣ ለእኔ ይህ ማለት ከCouchDB ጋር መስራት ምቾት ማግኘት እና እንዲሁም አንዳንድ ቢሮክራቶች በመረጃ ሊሞሉ ከሚችሉት በላይ መዋቅሮችን መንደፍ መማር ማለት ነው። ጊዜዬን በተሻለ ሁኔታ እየተጠቀምኩ ነው ብዬ አስባለሁ።

ነገር ግን የዚህ ጽሑፍ ትክክለኛ ርዕስ ዛሬ እየተጠቀምኩበት ያለሁት ነው። በምርጫ ሳይሆን በግዴለሽነት እና በጭፍን ተግባራዊ የድርጅት ፖሊሲዎች ምክንያት። ስለዚህ የሁለት በቅርብ ተዛማጅነት ያላቸውን የGoogle ቅጽበታዊ የውሂብ ጎታ ምርቶችን ሙሉ ለሙሉ ፍትሃዊ እና አድሎአዊ ያልሆነ ንፅፅር አቀርባለሁ።

ሁለቱም በስማቸው እሳት የሚል ቃል አላቸው። አንድ ነገር በፍቅር አስታውሳለሁ። ለእኔ ሁለተኛው ነገር የተለየ የእሳት ዓይነት ነው. ስማቸውን ለመናገር አልቸኩልም ምክንያቱም አንዴ ካደረግኩ በኋላ ወደ መጀመሪያው ትልቅ ችግር እንሮጣለን-ስሞች።

የመጀመሪያው ይባላል Firebase ሪል-ታይም ዳታቤዝእና ሁለተኛ - Firebase Cloud Firestore. ሁለቱም ምርቶች ከ Firebase Suite በጉግል መፈለግ. የእነሱ ኤፒአይዎች በቅደም ተከተል ተጠርተዋል firebase.database(…) и firebase.firestore(…).

ይህ የሆነው ምክንያቱም የእውነተኛ ጊዜ የውሂብ ጎታ - ዋናው ብቻ ነው Firebase በ2014 በGoogle ከመግዛቱ በፊት። ከዚያ Google እንደ ትይዩ ምርት ለመፍጠር ወሰነ ቅጅ Firebase በትልቁ የውሂብ ኩባንያ ላይ የተመሰረተ እና ፋየርስቶርን ከዳመና ጋር ጠራው። እስካሁን ግራ እንዳልተጋባችሁ ተስፋ አደርጋለሁ። አሁንም ግራ ከተጋቡ, አይጨነቁ, እኔ ራሴ ይህን የአንቀጹን ክፍል አሥር ጊዜ እንደገና ጻፍኩት.

ምክንያቱም ማመልከት ያስፈልግዎታል Firebase በFirebase ጥያቄ ውስጥ እና የእሳት ቃጠሎ ማከማቻ ስለ ፋየር ቤዝ በቀረበ ጥያቄ፣ ቢያንስ ከጥቂት አመታት በፊት በ Stack Overflow ላይ እንዲረዱዎት።

ለከፋ የሶፍትዌር መሰየም ልምድ ሽልማት ካለ፣ ይህ በእርግጥ ከተወዳዳሪዎቹ አንዱ ነው። በእነዚህ ስሞች መካከል ያለው የሃሚንግ ርቀት በጣም ትንሽ ከመሆኑ የተነሳ ልምድ ያላቸውን መሐንዲሶች ግራ ያጋባል፣ ጣቶቻቸው አንዱን ስም ሲጽፉ ጭንቅላታቸው ስለሌላ እያሰቡ ነው። እነዚህ በጥሩ ሁኔታ የታቀዱ ዕቅዶች በከፍተኛ ሁኔታ የማይሳኩ ናቸው; የመረጃ ቋቱ ይቃጠላል የሚለውን ትንቢት ፈጽመዋል። እና በፍፁም እየቀለድኩ አይደለም። ይህን የስያሜ እቅድ ያወጣ ሰው ደም፣ ላብ እና እንባ አስከትሏል።

Pyrrhic ድል

አንድ ሰው Firestore እንደሆነ ያስባል መተካት ፋየር ቤዝ፣ የሚቀጥለው ትውልድ ትውልዱ፣ ግን ያ አሳሳች ነው። ፋየርስቶር ለFirebase ተስማሚ ምትክ እንደሚሆን ዋስትና አይሰጥም። አንድ ሰው ከእሱ የሚስብ ሁሉንም ነገር የቆረጠ ይመስላል እና አብዛኛዎቹን የቀሩትን በተለያዩ መንገዶች ግራ ያጋባ ይመስላል።

ነገር ግን፣ በሁለቱ ምርቶች ላይ ፈጣን እይታ ግራ ሊያጋባዎት ይችላል፡ እነሱ ተመሳሳይ ነገር የሚያደርጉ ይመስላሉ፣ በመሠረቱ በተመሳሳዩ ኤፒአይዎች እና በተመሳሳይ የውሂብ ጎታ ክፍለ ጊዜ ውስጥ። ልዩነቶቹ ስውር ናቸው እና የሚገለጹት ሰፊ ሰነዶችን በጥንቃቄ በማነጻጸር ብቻ ነው። ወይም በFirebase ላይ በትክክል የሚሰራ ወደብ ኮድ ከFirestore ጋር እንዲሰራ ለማድረግ ሲሞክሩ። ምንም እንኳን በእውነተኛ ጊዜ በመዳፊት ለመጎተት እና ለመጣል እንደሞከሩ የውሂብ ጎታ በይነገጽ መብራቱን ያውቃሉ። እደግመዋለሁ፣ እየቀለድኩ አይደለም።

የFirebase ደንበኛ ጨዋ ነው ለውጦችን በማቆያ እና ለመጨረሻው የመፃፍ ስራ ቅድሚያ የሚሰጡትን ዝመናዎች በራስ ሰር ይሞክራል። ነገር ግን ፋየርስቶር በአንድ ሰነድ በአንድ ተጠቃሚ በሰከንድ 1 የመፃፍ ክዋኔ ገደብ አለው፣ እና ይህ ገደብ በአገልጋዩ ተፈጻሚ ነው። ከእሱ ጋር በሚሰሩበት ጊዜ, በዙሪያው መንገድ መፈለግ እና የዝማኔ ተመን መገደብ መተግበር የእርስዎ ነው, ምንም እንኳን መተግበሪያዎን ለመገንባት እየሞከሩ ቢሆኑም እንኳ. ማለትም ፋየርስቶር ኤፒአይን እንደ ሚጠቀም የሚመስለው የእውነተኛ ጊዜ ደንበኛ የሌለው የእውነተኛ ጊዜ የውሂብ ጎታ ነው።

እዚህ የFirestore raison d'être የመጀመሪያ ምልክቶችን ማየት እንጀምራለን. ተሳስቼ ሊሆን ይችላል፣ ነገር ግን በጉግል አስተዳደር ውስጥ ከፍተኛ ቦታ ያለው አንድ ሰው ከግዢው በኋላ ፋየርቤዝን ተመልክቶ በቀላሉ፣ “አይ፣ ኦ አምላኬ፣ አይሆንም። ይህ ተቀባይነት የለውም። በእኔ መሪነት አይደለም"

ከጓዳው ወጥቶ እንዲህ አለ።

“አንድ ትልቅ JSON ሰነድ? አይ. ውሂቡን ወደ ተለያዩ ሰነዶች ትከፍላለህ፣ እያንዳንዱም መጠናቸው ከ1 ሜጋባይት የማይበልጥ ይሆናል።

ይህ ዓይነቱ ገደብ ከማንኛውም በቂ ተነሳሽነት ካለው የተጠቃሚ መሰረት ጋር ለመጀመሪያ ጊዜ የሚተርፍ ይመስላል። እንደሆነ ታውቃለህ። በሥራ ላይ, ለምሳሌ, ከአንድ ሺህ ተኩል በላይ አቀራረቦች አሉን, እና ይህ ሙሉ በሙሉ መደበኛ ነው.

በዚህ ገደብ፣ በመረጃ ቋቱ ውስጥ ያለ አንድ "ሰነድ" ተጠቃሚው ሰነድ ብሎ ሊጠራው ከሚችለው ነገር ጋር የማይመሳሰል የመሆኑን እውነታ ለመቀበል ትገደዳለህ።

"ሌሎች ኤለመንቶችን በተከታታይ ሊይዙ የሚችሉ የድርድር ድርድር? አይ. ድርድሮች እግዚአብሔር እንዳሰበው ቋሚ ርዝመት ያላቸውን እቃዎች ወይም ቁጥሮች ብቻ ይይዛሉ።

ስለዚህ GeoJSON ን ወደ ፋየርስቶርዎ ለማስገባት ተስፋ ያደርጉ ከነበረ፣ ይህ የማይቻል መሆኑን ያገኙታል። አንድ ያልሆነ ነገር ተቀባይነት የለውም። በJSON ውስጥ Base64 እና/ወይም JSON እንደወደዱ ተስፋ አደርጋለሁ።

“JSON በኤችቲቲፒ፣ በትእዛዝ መስመር መሳሪያዎች ወይም በአስተዳዳሪ ፓነል አስመጣ እና ወደ ውጪ ላክ? አይ. ውሂብን ወደ ጉግል ክላውድ ማከማቻ መላክ እና ማስመጣት የሚችሉት። እኔ እንደማስበው አሁን ይባላል። እና “አንተ” እያልኩ የምናገረው የፕሮጀክት ባለቤት ማረጋገጫ ያላቸውን ብቻ ነው። ሁሉም ሰው ሄዶ ቲኬቶችን መፍጠር ይችላል።

እንደሚመለከቱት የFireBase ውሂብ ሞዴል ለመግለፅ ቀላል ነው። የJSON ቁልፎችን ከዩአርኤል መንገዶች ጋር የሚያቆራኝ አንድ ግዙፍ የJSON ሰነድ ይዟል። ጋር ብትጽፍ HTTP PUT в / FireBase የሚከተለው ነው:

{
  "hello": "world"
}

የ GET /hello ይመለሳል "world". በመሠረቱ ልክ እንደጠበቁት ይሰራል። የFireBase እቃዎች ስብስብ /my-collection/:id ከ JSON መዝገበ ቃላት ጋር እኩል ነው። {"my-collection": {...}} በሥሩ ውስጥ, ይዘቱ በ ውስጥ ይገኛሉ /my-collection:

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

ይህ እያንዳንዱ ማስገቢያ ከግጭት ነፃ መታወቂያ ካለው ይህ ጥሩ ይሰራል፣ ይህም ስርዓቱ መደበኛ መፍትሄ ካለው።

በሌላ አነጋገር፣ የመረጃ ቋቱ 100% JSON(*) ተኳሃኝ ነው እና ከኤችቲቲፒ ጋር ጥሩ ይሰራል፣ ለምሳሌ CouchDB። ነገር ግን በመሠረቱ የዌብሶኬቶችን፣ ፍቃድን እና የደንበኝነት ምዝገባዎችን በሚያጠቃልል በእውነተኛ ጊዜ ኤፒአይ በኩል ይጠቀሙበታል። የአስተዳዳሪው ፓኔል ሁለቱም ችሎታዎች አሉት፣ ሁለቱንም በቅጽበት ማረም እና JSON ማስመጣት/መላክ ያስችላል። በኮድዎ ላይ ተመሳሳይ ነገር ካደረጉ፣ ፕላስተር እና ልዩነት JSON 90% ዘላቂ ሁኔታን የማስተናገድ መደበኛ ተግባራትን እንደሚፈታ ሲረዱ ምን ያህል ልዩ ኮድ እንደሚባክን ስታውቅ ትገረማለህ።

የFirestore ውሂብ ሞዴል ከJSON ጋር ተመሳሳይ ነው፣ ግን በአንዳንድ ወሳኝ መንገዶች ይለያያል። በድርድር ውስጥ የድርድር እጥረት አለመኖሩን አስቀድሜ ጠቅሻለሁ። የንዑስ ስብስቦች ሞዴል ለእነሱ ከያዘው የJSON ሰነድ የተለየ አንደኛ ደረጃ ጽንሰ-ሀሳቦች እንዲሆኑ ነው። ለዚህ ዝግጁ የሆነ ተከታታይነት ስለሌለው መረጃን ለማምጣት እና ለመፃፍ ልዩ ኮድ ዱካ ያስፈልጋል። የእራስዎን ስብስቦች ለማስኬድ የእራስዎን ስክሪፕቶች እና መሳሪያዎች መፃፍ ያስፈልግዎታል. የአስተዳዳሪው ፓኔል በአንድ ጊዜ ትናንሽ ለውጦችን እንዲያደርጉ ይፈቅድልዎታል, እና የማስመጣት / የመላክ ችሎታዎች የሉትም.

ቅጽበታዊ የNoSQL ዳታቤዝ ወስደው ወደ ቀርፋፋ SQL ከራስ-መቀላቀል እና የተለየ JSON ያልሆነ አምድ አድርገውታል። እንደ GraftQL ያለ ነገር.

ትኩስ ጃቫ

ፋየርስቶር የበለጠ አስተማማኝ እና ሊሰፋ የሚችል መሆን ነበረበት ከተባለ፣ የሚያስቀው ነገር አማካዩ ገንቢ ፋየር ቤዝ ከሳጥን ውስጥ ከመምረጥ ያነሰ አስተማማኝ መፍትሄ ማግኘቱ ነው። Grumpy Database አስተዳዳሪው የሚያስፈልገው የሶፍትዌር አይነት ምርቱ ጥሩ ነው ተብሎ ለሚታሰበው ቦታ ከእውነታው የራቀ የጥረት እና የብቃት ደረጃን ይፈልጋል። ይህ HTML5 ሸራ ምንም የግንባታ መሳሪያዎች እና አጫዋች ከሌሉ በጭራሽ የፍላሽ ምትክ ካልሆነ ጋር ተመሳሳይ ነው። በተጨማሪም ፋየርስቶር የመረጃ ንፅህና እና የንፁህ ማረጋገጫ ፍላጎት ውስጥ ገብቷል ይህም በቀላሉ ከአማካይ የንግድ ተጠቃሚ ጋር የማይጣጣም ነው። መስራት ይወዳል: ለእሱ ሁሉም ነገር አማራጭ ነው, ምክንያቱም እስከ መጨረሻው ድረስ ሁሉም ነገር ረቂቅ ነው.

የFireBase ዋንኛ ጉዳቱ ደንበኛው የተፈጠረው ብዙ አመታት ቀደም ብሎ ነው፣ አብዛኞቹ የድር ገንቢዎች ስለ አለመቻል ከማወቁ በፊት ነው። በዚህ ምክንያት, FireBase ውሂቡን እንደሚቀይሩ ያስባል እና ስለዚህ በተጠቃሚው የቀረበውን ያለመለወጥ አይጠቀምም. በተጨማሪም፣ ለተጠቃሚው በሚያስተላልፍ ቅጽበተ-ፎቶዎች ውስጥ ያለውን ውሂብ እንደገና አይጠቀምም፣ ይህም ልዩነትን የበለጠ አስቸጋሪ ያደርገዋል። ለትልቅ ሰነዶች፣ ተለዋዋጭ ዲፍ ላይ የተመሰረተ የግብይት ዘዴው በቀላሉ በቂ አይደለም። ጓዶች፣ አስቀድመን አለን። WeakMap በጃቫስክሪፕት. ምቹ ነው።

መረጃውን የሚፈለገውን ቅርጽ ከሰጡ እና ዛፎቹን በጣም ብዙ መጠን ካላደረጉ, ይህ ችግር ሊታለፍ ይችላል. ነገር ግን ገንቢዎቹ የማይለወጥ አቅምን የሚጠቀም በጣም ጥሩ ደንበኛ ኤፒአይ ከለቀቀ በመረጃ ቋት ንድፍ ላይ ከተወሰኑ ከባድ ተግባራዊ ምክሮች ጋር ተጣምሮ ከሆነ ፋየር ቤዝ የበለጠ አስደሳች እንደሚሆን የማወቅ ጉጉት አለኝ። ይልቁንም ያልተሰበረውን ለማስተካከል የሞከሩ ይመስላሉ፣ ያ ደግሞ ተባብሷል።

ፋየርስቶር ከመፈጠሩ በስተጀርባ ያለውን አመክንዮ ሁሉ አላውቅም። በጥቁር ሣጥን ውስጥ ስለሚነሱ ምክንያቶች መገመትም የደስታው አካል ነው። ይህ የሁለት በጣም ተመሳሳይ ነገር ግን ወደር የለሽ የውሂብ ጎታዎች አቀማመጥ በጣም አልፎ አልፎ ነው። አንድ ሰው እንዳሰበው ነው፡- "Firebase በ Google ክላውድ ውስጥ ልንመስለው የምንችለው ተግባር ነው", ነገር ግን የእውነተኛ ዓለም መስፈርቶችን የመለየት ወይም እነዚህን ሁሉ መስፈርቶች የሚያሟሉ ጠቃሚ መፍትሄዎችን የመፍጠር ጽንሰ-ሐሳብ ገና አላገኘም. “አዘጋጆቹ ያስቡበት። ዩአይዩ እንዲያምር አድርግ...ተጨማሪ እሳት መጨመር ትችላለህ?”

ስለ ዳታ አወቃቀሮች ሁለት ነገሮችን ተረድቻለሁ። እኔ በእርግጠኝነት "ሁሉም ነገር በአንድ ትልቅ JSON ዛፍ" ጽንሰ-ሐሳብ ማንኛውንም ትልቅ መጠነ-ሰፊ መዋቅር ከመረጃ ቋት ውስጥ ለማውጣት ሙከራ አድርጌ ነው የማየው። ሶፍትዌሩ ማንኛውንም አጠራጣሪ የመረጃ አወቃቀር ፍርፋሪ በቀላሉ እንዲቋቋም መጠበቅ በቀላሉ እብደት ነው። ምን ያህል መጥፎ ነገሮች ሊሆኑ እንደሚችሉ ማሰብ እንኳን አያስፈልገኝም, ጥብቅ የኮድ ኦዲት አድርጌያለሁ እና እናንተ ሰዎች ያልማችሁትን ነገር አይቻለሁ. ግን ጥሩ መዋቅሮች ምን እንደሚመስሉ አውቃለሁ ፣ እንዴት እንደሚጠቀሙባቸው и ይህ ለምን መደረግ አለበት. ፋየርስቶር አመክንዮአዊ የሚመስልበት እና የፈጠሩት ሰዎች ጥሩ ስራ ሰርተናል ብለው የሚያስቡበት አለምን መገመት እችላለሁ። እኛ ግን በዚህ ዓለም ውስጥ አንኖርም።

የFireBase መጠይቅ ድጋፍ በማንኛውም መስፈርት ደካማ ነው እና በተግባር የለም። በእርግጠኝነት መሻሻል ወይም ቢያንስ መከለስ ያስፈልገዋል። ነገር ግን ፋየርስቶር በጣም የተሻለ አይደለም ምክንያቱም በ SQL ውስጥ በሚገኙ ተመሳሳይ ባለ አንድ-ልኬት ኢንዴክሶች የተገደበ ነው። ሰዎች በተዘበራረቀ ውሂብ የሚያሄዱ ጥያቄዎች ከፈለጉ፣ የሙሉ ጽሑፍ ፍለጋ፣ ባለብዙ ክልል ማጣሪያዎች እና ብጁ በተጠቃሚ የተገለጸ ማዘዝ ያስፈልግዎታል። በቅርበት ሲመረመሩ፣ የቀላል SQL ተግባራት በራሳቸው በጣም የተገደቡ ናቸው። በተጨማሪም፣ ሰዎች በምርት ውስጥ ሊሄዱ የሚችሉት ብቸኛው የSQL መጠይቆች ፈጣን መጠይቆች ናቸው። የታሰበ የውሂብ አወቃቀሮች ያለው ብጁ የመረጃ ጠቋሚ መፍትሄ ያስፈልግዎታል። ለሌላው ነገር ቢያንስ የመጨመሪያ ካርታ-መቀነስ ወይም ተመሳሳይ የሆነ ነገር መኖር አለበት።

ስለዚህ ጉዳይ መረጃ ለማግኘት ጎግል ሰነዶችን ከፈለግክ እንደ BigTable እና BigQuery ወደሆነ ነገር አቅጣጫ እንደምትጠቆም ተስፋ እናደርጋለን። ነገር ግን፣ እነዚህ ሁሉ መፍትሄዎች በጣም ጥቅጥቅ ባለ የድርጅት ሽያጭ ቃላቶች የታጀቡ ስለሆኑ በፍጥነት ወደ ኋላ ተመልሰው ሌላ ነገር መፈለግ ይጀምራሉ።

በእውነተኛ ጊዜ የውሂብ ጎታ የሚፈልጉት የመጨረሻው ነገር በአስተዳደር ክፍያ ሚዛን ላይ ላሉ ሰዎች የተሰራ ነው።

(*) ይህ ቀልድ ነው, የሚባል ነገር የለም 100% JSON ተኳሃኝ.

በቅጂ መብቶች ላይ

እጠብቃለሁ ቪዲዎች ፕሮጀክቶችን ለማረም፣ ለልማት እና ለማስተናገድ አገልጋይ? በእርግጠኝነት እርስዎ ደንበኛችን ነዎት 🙂 ዕለታዊ ዋጋ ለተለያዩ ውቅሮች አገልጋዮች ፣ ፀረ-DDoS እና የዊንዶውስ ፍቃዶች ቀድሞውኑ በዋጋው ውስጥ ተካትተዋል።

ምንጭ: hab.com