આ ડેટાબેઝ આગમાં છે...

ચાલો હું એક તકનીકી વાર્તા કહું.

ઘણા વર્ષો પહેલા, હું તેમાં બિલ્ટ સહયોગ સુવિધાઓ સાથે એપ્લિકેશન વિકસાવી રહ્યો હતો. તે એક વપરાશકર્તા-મૈત્રીપૂર્ણ પ્રાયોગિક સ્ટેક હતો જેણે પ્રારંભિક પ્રતિક્રિયા અને CouchDB ની સંપૂર્ણ સંભાવનાનો લાભ લીધો હતો. તે JSON દ્વારા રીઅલ ટાઇમમાં ડેટાને સિંક્રનાઇઝ કરે છે OT. તેનો ઉપયોગ કંપનીમાં આંતરિક રીતે કરવામાં આવ્યો હતો, પરંતુ અન્ય ક્ષેત્રોમાં તેની વ્યાપક ઉપયોગિતા અને સંભવિતતા સ્પષ્ટ હતી.

સંભવિત ગ્રાહકોને આ ટેક્નોલોજી વેચવાનો પ્રયાસ કરતી વખતે, અમને એક અણધારી અવરોધનો સામનો કરવો પડ્યો. ડેમો વિડિયોમાં, અમારી ટેક્નોલોજી સરસ દેખાતી હતી અને કામ કરતી હતી, ત્યાં કોઈ સમસ્યા નથી. વિડિઓએ બરાબર બતાવ્યું કે તે કેવી રીતે કાર્ય કરે છે અને કંઈપણનું અનુકરણ કર્યું નથી. અમે પ્રોગ્રામનો ઉપયોગ કરવા માટે એક વાસ્તવિક દૃશ્ય સાથે આવ્યા અને કોડેડ કર્યા.


હકીકતમાં, આ સમસ્યા બની હતી. અમારો ડેમો બરાબર એ રીતે કામ કરે છે જે રીતે બીજા બધાએ તેમની એપ્લિકેશનનું અનુકરણ કર્યું હતું. ખાસ કરીને, માહિતી તરત જ A થી B માં સ્થાનાંતરિત કરવામાં આવી હતી, પછી ભલે તે મોટી મીડિયા ફાઇલો હોય. લૉગ ઇન કર્યા પછી, દરેક વપરાશકર્તાએ નવી એન્ટ્રીઓ જોઈ. એપ્લિકેશનનો ઉપયોગ કરીને, જુદા જુદા વપરાશકર્તાઓ એક જ પ્રોજેક્ટ પર સ્પષ્ટ રીતે એકસાથે કામ કરી શકે છે, પછી ભલેને ગામમાં ક્યાંક ઇન્ટરનેટ કનેક્શન અવરોધાય. આફ્ટર ઇફેક્ટ્સમાં કોઈપણ ઉત્પાદન વિડિયો કટમાં આ સ્પષ્ટપણે સૂચિત છે.

રિફ્રેશ બટન શેના માટે છે તે દરેકને ખબર હોવા છતાં, કોઈ પણ ખરેખર સમજી શક્યું નથી કે તેઓએ અમને જે વેબ એપ્લીકેશન બનાવવાનું કહ્યું છે તે સામાન્ય રીતે તેમની પોતાની મર્યાદાઓને આધીન છે. અને તે કે જો તેમની હવે જરૂર નથી, તો વપરાશકર્તા અનુભવ સંપૂર્ણપણે અલગ હશે. તેઓએ મોટે ભાગે નોંધ્યું કે તેઓ જેની સાથે વાત કરી રહ્યા હતા તેમની નોંધો છોડીને તેઓ "ચેટ" કરી શકે છે, તેથી તેઓ આશ્ચર્ય પામ્યા કે આ કેવી રીતે અલગ છે, ઉદાહરણ તરીકે, Slack. ફફ!

રોજિંદા સમન્વયનની ડિઝાઇન

જો તમને સોફ્ટવેર ડેવલપમેન્ટનો અનુભવ હોય, તો તે યાદ રાખવું નર્વ-રેકિંગ હોવું જોઈએ કે મોટાભાગના લોકો ઈન્ટરફેસના ચિત્રને જોઈ શકતા નથી અને તેની સાથે ક્રિયાપ્રતિક્રિયા કરતી વખતે તે શું કરશે તે સમજી શકતા નથી. પ્રોગ્રામની અંદર શું થાય છે તેનો ઉલ્લેખ ન કરવો. તે જાણવું કરી શકો છો શું ન થઈ શકે અને શું ન થવું જોઈએ તે જાણવાનું પરિણામ મોટે ભાગે થાય છે. આ જરૂરી છે માનસિક મોડલ સોફ્ટવેર શું કરે છે એટલું જ નહીં, પરંતુ તેના વ્યક્તિગત ભાગો કેવી રીતે સંકલિત થાય છે અને એકબીજા સાથે વાતચીત કરે છે.

આનું ઉત્તમ ઉદાહરણ એ છે કે વપરાશકર્તા a તરફ જોતો હોય છે સ્પિનર.gif, આખરે કામ ક્યારે પૂર્ણ થશે તે અંગે આશ્ચર્ય છે. વિકાસકર્તાને સમજાયું હશે કે પ્રક્રિયા સંભવતઃ અટકી ગઈ છે અને GIF સ્ક્રીન પરથી ક્યારેય અદૃશ્ય થશે નહીં. આ એનિમેશન નોકરીના અમલનું અનુકરણ કરે છે, પરંતુ તેની સ્થિતિ સાથે સંબંધિત નથી. આવા કિસ્સાઓમાં, કેટલાક તકનીકીઓ તેમની આંખો ફેરવવાનું પસંદ કરે છે, વપરાશકર્તાઓની મૂંઝવણની હદથી આશ્ચર્યચકિત થાય છે. જો કે, નોંધ લો કે તેમાંથી કેટલા ફરતી ઘડિયાળ તરફ નિર્દેશ કરે છે અને કહે છે કે તે ખરેખર સ્થિર છે?

આ વાસ્તવિક સમયના મૂલ્યનો સાર છે. આ દિવસોમાં, રીઅલ-ટાઇમ ડેટાબેઝ હજુ પણ ખૂબ ઓછા ઉપયોગમાં લેવાય છે અને ઘણા લોકો તેમને શંકાની નજરે જુએ છે. આમાંના મોટાભાગના ડેટાબેઝ NoSQL શૈલી તરફ ખૂબ જ ઝુકાવતા હોય છે, તેથી જ તેઓ સામાન્ય રીતે મોંગો-આધારિત ઉકેલોનો ઉપયોગ કરે છે, જે શ્રેષ્ઠ રીતે ભૂલી જાય છે. જો કે, મારા માટે આનો અર્થ છે CouchDB સાથે કામ કરવા માટે આરામદાયક બનવું, સાથે સાથે કેટલાક અમલદારો ડેટા સાથે ભરી શકે તેવા માળખાને ડિઝાઇન કરવાનું શીખવું. મને લાગે છે કે હું મારા સમયનો વધુ સારી રીતે ઉપયોગ કરી રહ્યો છું.

પરંતુ આ પોસ્ટનો વાસ્તવિક વિષય તે છે જેનો હું આજે ઉપયોગ કરી રહ્યો છું. પસંદગી દ્વારા નહીં, પરંતુ ઉદાસીન અને આંધળી રીતે લાગુ કોર્પોરેટ નીતિઓને કારણે. તેથી હું બે નજીકથી સંબંધિત Google રીઅલ-ટાઇમ ડેટાબેઝ ઉત્પાદનોની સંપૂર્ણ રીતે ન્યાયી અને નિષ્પક્ષ સરખામણી પ્રદાન કરીશ.

બંનેના નામમાં ફાયર શબ્દ છે. એક વાત મને પ્રેમથી યાદ છે. મારા માટે બીજી વસ્તુ આગનો અલગ પ્રકાર છે. હું તેમના નામો કહેવાની ઉતાવળમાં નથી, કારણ કે એકવાર હું કરીશ, અમે પ્રથમ મોટી સમસ્યાનો સામનો કરીશું: નામ.

પ્રથમ કહેવામાં આવે છે ફાયરબેઝ રીઅલ-ટાઇમ ડેટાબેઝ, અને બીજું - ફાયરબેઝ ક્લાઉડ ફાયરસ્ટોર. તે બંનેમાંથી ઉત્પાદનો છે ફાયરબેઝ સ્યુટ Google તેમના API ને અનુક્રમે કહેવામાં આવે છે firebase.database(…) и firebase.firestore(…).

આ કારણે થયું રીઅલ-ટાઇમ ડેટાબેઝ - તે માત્ર મૂળ છે ફાયરબેઝ 2014 માં Google દ્વારા તેની ખરીદી પહેલા. પછી ગૂગલે સમાંતર પ્રોડક્ટ તરીકે બનાવવાનું નક્કી કર્યું એક નકલ મોટી ડેટા કંપની પર આધારિત ફાયરબેઝ, અને તેને ક્લાઉડ સાથે ફાયરસ્ટોર કહે છે. હું આશા રાખું છું કે તમે હજી મૂંઝવણમાં નથી. જો તમે હજી પણ મૂંઝવણમાં છો, તો ચિંતા કરશો નહીં, મેં જાતે લેખનો આ ભાગ દસ વખત ફરીથી લખ્યો છે.

કારણ કે તમારે સૂચવવાની જરૂર છે ફાયરબેઝ ફાયરબેઝ પ્રશ્નમાં અને ફાયરસ્ટોર ફાયરબેઝ વિશેના પ્રશ્નમાં, ઓછામાં ઓછું તમને થોડા વર્ષો પહેલા સ્ટેક ઓવરફ્લો પર સમજવા માટે.

જો સૌથી ખરાબ સૉફ્ટવેર નામકરણ અનુભવ માટે કોઈ પુરસ્કાર હતો, તો આ ચોક્કસપણે દાવેદારોમાંનો એક હશે. આ નામો વચ્ચે હેમિંગનું અંતર એટલું નાનું છે કે તે અનુભવી ઇજનેરોને પણ મૂંઝવણમાં મૂકે છે જેમની આંગળીઓ એક નામ લખે છે જ્યારે તેમના માથા બીજા વિશે વિચારે છે. આ સારી હેતુવાળી યોજનાઓ છે જે ખરાબ રીતે નિષ્ફળ જાય છે; તેઓએ ભવિષ્યવાણી પૂરી કરી કે ડેટાબેઝમાં આગ લાગશે. અને હું બિલકુલ મજાક નથી કરી રહ્યો. જે વ્યક્તિ આ નામકરણ યોજના સાથે આવી હતી તેના કારણે લોહી, પરસેવો અને આંસુ થયા હતા.

પિરરિક વિજય

એક એવું વિચારશે કે ફાયરસ્ટોર છે બદલી ફાયરબેઝ, તેની આગામી પેઢીના વંશજ, પરંતુ તે ભ્રામક હશે. Firebase માટે ફાયરસ્ટોર યોગ્ય રિપ્લેસમેન્ટ હોવાની ખાતરી નથી. એવું લાગે છે કે કોઈએ તેમાંથી રસપ્રદ બધું કાપી નાખ્યું, અને બાકીના મોટાભાગનાને વિવિધ રીતે મૂંઝવણમાં મૂક્યા.

જો કે, બે ઉત્પાદનો પર એક ઝડપી નજર તમને મૂંઝવણમાં મૂકી શકે છે: તેઓ મૂળભૂત રીતે સમાન API દ્વારા અને સમાન ડેટાબેઝ સત્રમાં પણ સમાન કાર્ય કરતા હોય તેવું લાગે છે. તફાવતો સૂક્ષ્મ છે અને વ્યાપક દસ્તાવેજીકરણના કાળજીપૂર્વક તુલનાત્મક અભ્યાસ દ્વારા જ પ્રગટ થાય છે. અથવા જ્યારે તમે પોર્ટ કોડનો પ્રયાસ કરી રહ્યાં હોવ જે ફાયરબેઝ પર સંપૂર્ણ રીતે કામ કરે છે જેથી તે ફાયરસ્ટોર સાથે કામ કરે. પછી પણ તમે જાણો છો કે ડેટાબેઝ ઈન્ટરફેસ જલદીથી પ્રકાશિત થાય છે જ્યારે તમે વાસ્તવિક સમયમાં માઉસ સાથે ડ્રેગ અને ડ્રોપ કરવાનો પ્રયાસ કરો છો. હું પુનરાવર્તન કરું છું, હું મજાક નથી કરતો.

ફાયરબેઝ ક્લાયંટ એ અર્થમાં નમ્ર છે કે તે ફેરફારોને બફર કરે છે અને અપડેટ્સનો આપમેળે પુનઃપ્રયાસ કરે છે જે છેલ્લા લખવાના ઓપરેશનને પ્રાથમિકતા આપે છે. જો કે, Firestore પાસે પ્રતિ સેકન્ડ દીઠ વપરાશકર્તા દીઠ દસ્તાવેજ દીઠ 1 લેખન કામગીરીની મર્યાદા છે, અને આ મર્યાદા સર્વર દ્વારા લાગુ કરવામાં આવે છે. તેની સાથે કામ કરતી વખતે, તેની આસપાસ કોઈ રસ્તો શોધવાનું અને અપડેટ રેટ લિમિટરનો અમલ કરવો તે તમારા પર છે, પછી ભલે તમે તમારી એપ્લિકેશન બનાવવાનો પ્રયાસ કરી રહ્યાં હોવ. એટલે કે, ફાયરસ્ટોર એ રીઅલ-ટાઇમ ક્લાયંટ વિનાનો રીઅલ-ટાઇમ ડેટાબેઝ છે, જે API નો ઉપયોગ કરીને એક તરીકે માસ્કરેડ કરે છે.

અહીં આપણે ફાયરસ્ટોરના રેઇઝન ડી'ત્રના પ્રથમ સંકેતો જોવાનું શરૂ કરીએ છીએ. હું ખોટો હોઈ શકું છું, પરંતુ મને શંકા છે કે Google ના મેનેજમેન્ટમાં કોઈ ઉચ્ચ વ્યક્તિએ ખરીદી પછી ફાયરબેઝ તરફ જોયું અને ફક્ત એટલું જ કહ્યું, “ના, ઓહ માય ગોડ, ના. આ અસ્વીકાર્ય છે. ફક્ત મારા નેતૃત્વ હેઠળ નથી."

તે તેની ચેમ્બરમાંથી દેખાયો અને જાહેર કર્યું:

"એક મોટો JSON દસ્તાવેજ? ના. તમે ડેટાને અલગ-અલગ દસ્તાવેજોમાં વિભાજિત કરશો, જેમાંથી દરેકનું કદ 1 મેગાબાઈટથી વધુ નહીં હોય.”

એવું લાગે છે કે આવી મર્યાદા કોઈપણ પર્યાપ્ત પ્રેરિત વપરાશકર્તા આધાર સાથે પ્રથમ એન્કાઉન્ટરમાં ટકી શકશે નહીં. તમે જાણો છો કે તે છે. કામ પર, ઉદાહરણ તરીકે, અમારી પાસે દોઢ હજારથી વધુ પ્રસ્તુતિઓ છે, અને આ સંપૂર્ણપણે સામાન્ય છે.

આ મર્યાદા સાથે, તમને એ હકીકત સ્વીકારવાની ફરજ પાડવામાં આવશે કે ડેટાબેઝમાંનો એક "દસ્તાવેજ" કોઈપણ ઑબ્જેક્ટ જેવો નહીં હોય જેને વપરાશકર્તા દસ્તાવેજ કહી શકે.

"એરેના એરે જે પુનરાવર્તિત રીતે અન્ય ઘટકો સમાવી શકે છે? ના. એરેમાં માત્ર નિશ્ચિત-લંબાઈની વસ્તુઓ અથવા સંખ્યાઓ હશે, જેમ કે ભગવાન ઇચ્છે છે."

તેથી જો તમે તમારા ફાયરસ્ટોરમાં જીઓજેસન મૂકવાની આશા રાખતા હો, તો તમે જોશો કે આ શક્ય નથી. બિન-એક-પરિમાણીય કંઈપણ સ્વીકાર્ય નથી. મને આશા છે કે તમને JSON ની અંદર Base64 અને/અથવા JSON ગમશે.

"HTTP, કમાન્ડ લાઇન ટૂલ્સ અથવા એડમિન પેનલ દ્વારા JSON આયાત અને નિકાસ? ના. તમે માત્ર 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},
  // ...
}

જો દરેક ઇન્સર્ટમાં અથડામણ-મુક્ત ID હોય તો આ સારું કામ કરે છે, જેના માટે સિસ્ટમ પાસે પ્રમાણભૂત ઉકેલ છે.

બીજા શબ્દોમાં કહીએ તો, ડેટાબેઝ 100% JSON(*) સુસંગત છે અને HTTP સાથે ઉત્તમ કામ કરે છે, જેમ કે CouchDB. પરંતુ મૂળભૂત રીતે તમે તેનો ઉપયોગ રીઅલ-ટાઇમ API દ્વારા કરો છો જે વેબસોકેટ્સ, અધિકૃતતા અને સબ્સ્ક્રિપ્શન્સને અમૂર્ત કરે છે. એડમિન પેનલમાં બંને ક્ષમતાઓ છે, જે રીઅલ-ટાઇમ એડિટિંગ અને JSON આયાત/નિકાસ બંનેને મંજૂરી આપે છે. જો તમે તમારા કોડમાં તે જ કરો છો, તો તમને આશ્ચર્ય થશે કે જ્યારે તમને ખ્યાલ આવશે કે પેચ અને ડિફ JSON સતત સ્થિતિને હેન્ડલ કરવાના 90% નિયમિત કાર્યોને હલ કરે છે ત્યારે કેટલો વિશિષ્ટ કોડ બગાડવામાં આવશે.

ફાયરસ્ટોર ડેટા મોડલ JSON જેવું જ છે, પરંતુ કેટલીક જટિલ રીતે અલગ પડે છે. મેં પહેલેથી જ એરેની અંદર એરેના અભાવનો ઉલ્લેખ કર્યો છે. પેટા-સંગ્રહો માટેનું મૉડલ તેમના માટે પ્રથમ વર્ગની વિભાવનાઓ છે, જે JSON દસ્તાવેજથી અલગ છે જેમાં તે છે. આ માટે કોઈ તૈયાર સીરીયલાઇઝેશન ન હોવાથી, ડેટા પુનઃપ્રાપ્ત કરવા અને લખવા માટે વિશિષ્ટ કોડ પાથની જરૂર છે. તમારા પોતાના સંગ્રહ પર પ્રક્રિયા કરવા માટે, તમારે તમારી પોતાની સ્ક્રિપ્ટો અને સાધનો લખવાની જરૂર છે. એડમિન પેનલ તમને એક સમયે એક ફીલ્ડમાં નાના ફેરફારો કરવાની મંજૂરી આપે છે, અને તેમાં આયાત/નિકાસ ક્ષમતાઓ હોતી નથી.

તેઓએ રીઅલ-ટાઇમ NoSQL ડેટાબેઝ લીધો અને તેને સ્વતઃ-જોડાણ અને એક અલગ બિન-JSON કૉલમ સાથે ધીમા બિન-SQLમાં ફેરવ્યું. GraftQL જેવું કંઈક.

ગરમ જાવા

જો ફાયરસ્ટોર વધુ ભરોસાપાત્ર અને માપી શકાય તેવું માનવામાં આવતું હતું, તો વક્રોક્તિ એ છે કે સરેરાશ ડેવલપર ફાયરબેઝને બોક્સની બહાર પસંદ કરવા કરતાં ઓછા વિશ્વસનીય ઉકેલ સાથે સમાપ્ત થશે. ગ્રમ્પી ડેટાબેઝ એડમિનિસ્ટ્રેટરને જે પ્રકારના સોફ્ટવેરની જરૂર હોય છે તે માટે પ્રયત્નોના સ્તર અને પ્રતિભાની ક્ષમતાની જરૂર હોય છે જે ઉત્પાદનને સારું માનવામાં આવે છે તે વિશિષ્ટ માટે અવાસ્તવિક છે. જો ડેવલપમેન્ટ ટૂલ્સ અને પ્લેયર ન હોય તો કેવી રીતે HTML5 કેનવાસ ફ્લેશનું રિપ્લેસમેન્ટ નથી તે સમાન છે. તદુપરાંત, ફાયરસ્ટોર ડેટા શુદ્ધતા અને જંતુરહિત માન્યતાની ઇચ્છામાં ડૂબી ગયું છે જે સરેરાશ વ્યવસાયિક વપરાશકર્તાની સાથે કેવી રીતે સંરેખિત થતું નથી કામ કરવાનું પસંદ છે: તેના માટે બધું વૈકલ્પિક છે, કારણ કે અંત સુધી બધું જ ડ્રાફ્ટ છે.

ફાયરબેઝનો મુખ્ય ગેરલાભ એ છે કે મોટાભાગના વેબ ડેવલપર્સ અપરિવર્તનક્ષમતા વિશે જાણતા હોય તે પહેલાં ક્લાયંટ તેના સમયથી ઘણા વર્ષો પહેલા બનાવવામાં આવ્યું હતું. આને કારણે, ફાયરબેઝ ધારે છે કે તમે ડેટા બદલશો અને તેથી વપરાશકર્તા દ્વારા પ્રદાન કરવામાં આવતી અપરિવર્તનક્ષમતાનો લાભ લેતા નથી. વધુમાં, તે વપરાશકર્તાને પસાર કરે છે તે સ્નેપશોટમાં ડેટાનો પુનઃઉપયોગ કરતું નથી, જે તફાવતને વધુ મુશ્કેલ બનાવે છે. મોટા દસ્તાવેજો માટે, તેની પરિવર્તનશીલ ડિફ-આધારિત ટ્રાન્ઝેક્શન મિકેનિઝમ ફક્ત અપૂરતી છે. ગાય્સ, અમારી પાસે પહેલેથી જ છે WeakMap JavaScript માં. તે આરામદાયક છે.

જો તમે ડેટાને ઇચ્છિત આકાર આપો અને વૃક્ષોને ખૂબ જ વિશાળ ન બનાવો, તો આ સમસ્યાને દૂર કરી શકાય છે. પરંતુ હું ઉત્સુક છું કે જો ડેવલપર્સે ડેટાબેઝ ડિઝાઇન પર કેટલીક ગંભીર વ્યવહારુ સલાહ સાથે અવિચલિતતાનો ઉપયોગ કર્યો હોય તો ડેવલપર્સ ખરેખર સારા ક્લાયંટ APIને રિલીઝ કરે તો ફાયરબેઝ વધુ રસપ્રદ રહેશે. તેના બદલે, તેઓ જે તૂટ્યું ન હતું તેને ઠીક કરવાનો પ્રયાસ કરતા જણાય છે, અને તેનાથી તે વધુ ખરાબ થઈ ગયું.

હું ફાયરસ્ટોરની રચના પાછળનો તમામ તર્ક જાણતો નથી. બ્લેક બોક્સની અંદર ઉદ્ભવતા હેતુઓ વિશે અનુમાન લગાવવું એ પણ મજાનો એક ભાગ છે. બે અત્યંત સમાન પરંતુ અનુપમ ડેટાબેસેસનું આ જોડાણ તદ્દન દુર્લભ છે. તે એવું છે કે કોઈએ વિચાર્યું: "ફાયરબેઝ એ માત્ર એક કાર્ય છે જે અમે Google ક્લાઉડમાં અનુકરણ કરી શકીએ છીએ", પરંતુ હજી સુધી વાસ્તવિક-વિશ્વની જરૂરિયાતોને ઓળખવા અથવા તે બધી આવશ્યકતાઓને પૂર્ણ કરતા ઉપયોગી ઉકેલો બનાવવાનો ખ્યાલ શોધી શક્યો નથી. “વિકાસકર્તાઓને તેના વિશે વિચારવા દો. ફક્ત UI ને સુંદર બનાવો... શું તમે વધુ આગ ઉમેરી શકો છો?"

હું ડેટા સ્ટ્રક્ચર્સ વિશે કેટલીક બાબતો સમજું છું. હું ચોક્કસપણે "એક મોટા JSON વૃક્ષમાં બધું" ખ્યાલને ડેટાબેઝમાંથી મોટા પાયે માળખાના કોઈપણ અર્થને અમૂર્ત કરવાના પ્રયાસ તરીકે જોઉં છું. કોઈપણ શંકાસ્પદ ડેટા સ્ટ્રક્ચર ફ્રેક્ટલનો સામનો કરવા માટે સૉફ્ટવેરની અપેક્ષા રાખવી એ ફક્ત પાગલ છે. મારે કલ્પના કરવાની પણ જરૂર નથી કે વસ્તુઓ કેટલી ખરાબ હોઈ શકે, મેં સખત કોડ ઓડિટ કર્યા છે અને મેં એવી વસ્તુઓ જોઈ જેનું તમે લોકોએ ક્યારેય સપનું જોયું ન હતું. પરંતુ હું એ પણ જાણું છું કે સારી રચનાઓ કેવી દેખાય છે, તેમનો ઉપયોગ કેવી રીતે કરવો и આ કેમ કરવું જોઈએ. હું એવી દુનિયાની કલ્પના કરી શકું છું જ્યાં ફાયરસ્ટોર તાર્કિક લાગશે અને જે લોકોએ તેને બનાવ્યું છે તેઓ વિચારશે કે તેઓએ સારું કામ કર્યું છે. પણ આપણે આ દુનિયામાં રહેતા નથી.

ફાયરબેઝનો ક્વેરી સપોર્ટ કોઈપણ ધોરણ પ્રમાણે નબળો છે અને વ્યવહારીક રીતે અસ્તિત્વમાં નથી. તેને ચોક્કસપણે સુધારણા અથવા ઓછામાં ઓછા પુનરાવર્તનની જરૂર છે. પરંતુ ફાયરસ્ટોર વધુ સારું નથી કારણ કે તે સાદા SQL માં જોવા મળતા સમાન વન-પરિમાણીય અનુક્રમણિકાઓ સુધી મર્યાદિત છે. જો તમને ક્વેરીઝની જરૂર હોય કે જે લોકો અસ્તવ્યસ્ત ડેટા પર ચલાવે છે, તો તમારે પૂર્ણ-ટેક્સ્ટ શોધ, મલ્ટિ-રેન્જ ફિલ્ટર્સ અને કસ્ટમ વપરાશકર્તા-વ્યાખ્યાયિત ઓર્ડરિંગની જરૂર છે. નજીકના નિરીક્ષણ પર, સાદા SQL ના કાર્યો તેમના પોતાના પર ખૂબ મર્યાદિત છે. વધુમાં, માત્ર SQL ક્વેરીઝ લોકો પ્રોડક્શનમાં ચલાવી શકે છે તે ઝડપી ક્વેરીઝ છે. તમને સ્માર્ટ ડેટા સ્ટ્રક્ચર્સ સાથે કસ્ટમ ઇન્ડેક્સિંગ સોલ્યુશનની જરૂર પડશે. બાકીની દરેક વસ્તુ માટે, ત્યાં ઓછામાં ઓછું વધારો નકશો-ઘટાડો અથવા કંઈક સમાન હોવું જોઈએ.

જો તમે આ વિશેની માહિતી માટે Google ડૉક્સ પર સર્ચ કરશો, તો આશા છે કે તમને BigTable અને BigQuery જેવી કોઈ વસ્તુની દિશામાં નિર્દેશ કરવામાં આવશે. જો કે, આ તમામ ઉકેલો એટલા ગાઢ કોર્પોરેટ સેલ્સ જાર્ગન સાથે છે કે તમે ઝડપથી પાછા ફરશો અને કંઈક બીજું શોધવાનું શરૂ કરશો.

રીઅલ-ટાઇમ ડેટાબેઝ સાથે તમે ઇચ્છો છો તે છેલ્લી વસ્તુ મેનેજમેન્ટ પગાર ધોરણો પરના લોકો દ્વારા અને તેમના માટે બનાવેલ છે.

(*) આ એક મજાક છે, એવું કંઈ નથી 100% JSON સુસંગત.

જાહેરાતના અધિકારો પર

ની સોધ મા હોવુ વી.ડી.એસ. ડીબગીંગ પ્રોજેક્ટ માટે, વિકાસ અને હોસ્ટિંગ માટે સર્વર? તમે ચોક્કસપણે અમારા ક્લાયન્ટ છો 🙂 વિવિધ રૂપરેખાંકનો, એન્ટિ-ડીડીઓએસ અને વિન્ડોઝ લાયસન્સનાં સર્વર માટે દૈનિક કિંમતો પહેલેથી જ કિંમતમાં શામેલ છે.

સોર્સ: www.habr.com