મને તાજેતરમાં તે જાણવા મળ્યું Red Hat સેટેલાઈટમાંથી MongoDB આધારને દૂર કરે છે (તેઓ લાઇસન્સ ફેરફારોને કારણે કહે છે). આનાથી હું વિચારવા લાગ્યો કારણ કે છેલ્લા કેટલાક વર્ષોમાં મેં મોંગોડીબી કેટલું ભયંકર છે અને કોઈએ તેનો ઉપયોગ કેવી રીતે કરવો જોઈએ તે વિશે ઘણા બધા લેખો જોયા છે. પરંતુ આ સમય દરમિયાન, મોંગોડીબી વધુ પરિપક્વ ઉત્પાદન બની ગયું છે. શું થયું? શું તમામ તિરસ્કાર ખરેખર નવા DBMS ના પ્રારંભિક માર્કેટિંગમાં ભૂલોને કારણે છે? અથવા લોકો માત્ર ખોટા સ્થળોએ MongoDB નો ઉપયોગ કરી રહ્યા છે?

જો તમને લાગે કે હું મોંગોડીબીનો બચાવ કરી રહ્યો છું, તો કૃપા કરીને વાંચો અસ્વીકરણ લેખના અંતે.

નવો ટ્રેન્ડ

હું કહી શકું તેના કરતાં વધુ વર્ષોથી હું સોફ્ટવેર ઉદ્યોગમાં કામ કરી રહ્યો છું, પરંતુ હું હજી પણ અમારા ઉદ્યોગને અસર કરતા વલણોના એક નાના ભાગ સાથે સંપર્કમાં આવ્યો છું. મેં 4GL, AOP, Agile, SOA, Web 2.0, AJAX, Blockchain નો ઉદય જોયો છે... યાદી અનંત છે. દર વર્ષે નવા વલણો દેખાય છે. કેટલાક ઝડપથી અદૃશ્ય થઈ જાય છે, જ્યારે અન્ય મૂળભૂત રીતે સોફ્ટવેર વિકસાવવાની રીતમાં ફેરફાર કરે છે.

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

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

નોંધ: તમે વિચારી શકો છો કે હું દસ્તાવેજ ડેટાબેસેસને કૉલમર ડેટાબેસેસ, કી/વેલ્યુ સ્ટોર્સ, અથવા અન્ય અસંખ્ય પ્રકારના ડેટા સ્ટોર્સમાંના કોઈપણ કે જે સામાન્ય NoSQL વ્યાખ્યા હેઠળ આવે છે સાથે ગૂંચવણમાં મૂકું છું. અને તમે સાચા છો. પરંતુ તે સમયે અરાજકતાનું શાસન હતું. દરેક જણ NoSQL સાથે ભ્રમિત છે, તે દરેક વ્યક્તિ બની ગયું છે એકદમ જરૂરી છે, જોકે ઘણાને વિવિધ તકનીકોમાં તફાવત જોવા મળ્યો નથી. ઘણા લોકો માટે, MongoDB બની ગયું છે સાથે સમાનાર્થી NoSQL.

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

તે યાદ રાખવું અગત્યનું છે કે MongoDB, અને સામાન્ય રીતે દસ્તાવેજ ડેટાબેસેસ, પરંપરાગત રીલેશ્નલ ડેટાબેસેસ સાથે ઘણી સમસ્યાઓનું નિરાકરણ કરે છે:

• કડક યોજના: રિલેશનલ ડેટાબેઝ સાથે, જો તમારી પાસે ડાયનેમિકલી જનરેટ થયેલો ડેટા હોય, તો તમારે કાં તો ડેટાના રેન્ડમ "પરચુરણ" કૉલમનો સમૂહ બનાવવા, ત્યાં ડેટાના બ્લોબ્સ ખસેડવા અથવા રૂપરેખાંકનનો ઉપયોગ કરવાની ફરજ પાડવામાં આવે છે. EAV...આ તમામમાં નોંધપાત્ર ખામીઓ છે.
• સ્કેલિંગમાં મુશ્કેલી: જો ત્યાં એટલો બધો ડેટા છે કે તે એક સર્વર પર ફિટ થતો નથી, તો મોંગોડીબીએ તેને બહુવિધ મશીનો પર સ્કેલ કરવાની મંજૂરી આપવા માટે મિકેનિઝમ્સ ઓફર કર્યા છે.
• જટિલ સર્કિટ ફેરફારો: કોઈ સ્થળાંતર નથી! રિલેશનલ ડેટાબેઝમાં, ડેટાબેઝ માળખું બદલવું એ એક મોટી સમસ્યા હોઈ શકે છે (ખાસ કરીને જ્યારે ઘણો ડેટા હોય). મોંગોડીબી પ્રક્રિયાને મોટા પ્રમાણમાં સરળ બનાવવામાં સક્ષમ હતું. અને તે એટલું સરળ બનાવ્યું કે તમે જેમ જેમ જાઓ તેમ તેમ તમે સર્કિટને અપડેટ કરી શકો છો અને ખૂબ જ ઝડપથી આગળ વધી શકો છો.
• રેકોર્ડિંગ કામગીરી: MongoDB પ્રદર્શન સારું હતું, ખાસ કરીને જ્યારે યોગ્ય રીતે ગોઠવેલું હોય. મોંગોડીબીનું આઉટ-ઓફ-ધ-બોક્સ રૂપરેખાંકન, જેના માટે તેની ઘણીવાર ટીકા કરવામાં આવી હતી, કેટલાક પ્રભાવશાળી પ્રદર્શન નંબરો દર્શાવે છે.

બધા જોખમો તમારા પર છે

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

સાચું કહું તો, 10gen/MongoDB Inc પર કોઈ નથી. એમ નહીં કહે કે નીચે આપેલું સાચું નથી, આ માત્ર સમાધાન છે.

• ખોવાયેલા વ્યવહારો: ટ્રાન્ઝેક્શન એ ઘણા રિલેશનલ ડેટાબેસેસનું મુખ્ય લક્ષણ છે (બધા નહીં, પરંતુ મોટાભાગના). વ્યવહારનો અર્થ એ છે કે તમે પરમાણુ રીતે બહુવિધ કામગીરી કરી શકો છો અને ખાતરી કરી શકો છો કે ડેટા સુસંગત રહે છે. અલબત્ત, NoSQL ડેટાબેઝ સાથે, વ્યવહારિકતા એક દસ્તાવેજમાં હોઈ શકે છે, અથવા તમે ટ્રાન્ઝેક્શનલ સિમેન્ટિક્સ મેળવવા માટે બે-તબક્કાના કમિટનો ઉપયોગ કરી શકો છો. પરંતુ તમારે આ કાર્યક્ષમતા જાતે અમલમાં મૂકવી પડશે... જે મુશ્કેલ અને સમય માંગી લેતું કાર્ય હોઈ શકે છે. ઘણી વખત તમને ખ્યાલ નથી આવતો કે ત્યાં સુધી કોઈ સમસ્યા છે જ્યાં સુધી તમે ડેટાબેઝમાંનો ડેટા અમાન્ય સ્થિતિમાં ન જોશો કારણ કે ઓપરેશન્સની અણુશકિતની ખાતરી આપી શકાતી નથી. નોંધ: ઘણા લોકોએ મને કહ્યું કે MongoDB 4.0 એ ગયા વર્ષે વ્યવહારો રજૂ કર્યા હતા, પરંતુ કેટલીક મર્યાદાઓ સાથે. લેખમાંથી ટેકઓવે એ જ રહે છે: ટેક્નોલોજી તમારી જરૂરિયાતોને કેટલી સારી રીતે પૂરી કરે છે તેનું મૂલ્યાંકન કરો.
• સંબંધની અખંડિતતાની ખોટ (વિદેશી ચાવીઓ): જો તમારા ડેટામાં સંબંધો છે, તો તમારે તેને એપ્લિકેશનમાં લાગુ કરવું પડશે. આ સંબંધોને માન આપતો ડેટાબેઝ રાખવાથી એપ્લિકેશનમાંથી ઘણું કામ લેવામાં આવશે અને તેથી તમારા પ્રોગ્રામરો.
• ડેટા સ્ટ્રક્ચર લાગુ કરવાની ક્ષમતાનો અભાવ: કડક સ્કીમા કેટલીકવાર મોટી સમસ્યા બની શકે છે, પરંતુ જો સમજદારીપૂર્વક ઉપયોગ કરવામાં આવે તો તે સારા ડેટા સ્ટ્રક્ચરિંગ માટે એક શક્તિશાળી મિકેનિઝમ પણ છે. MongoDB જેવા દસ્તાવેજ ડેટાબેઝ અકલ્પનીય સ્કીમા લવચીકતા પ્રદાન કરે છે, પરંતુ આ સુગમતા ડેટાને સ્વચ્છ રાખવાની જવાબદારીને દૂર કરે છે. જો તમે તેમની કાળજી લેતા નથી, તો તમે તમારી અપેક્ષા મુજબના ફોર્મમાં સંગ્રહિત ન હોય તેવા ડેટાના એકાઉન્ટ માટે તમારી એપ્લિકેશનમાં ઘણા બધા કોડ લખવાનું સમાપ્ત કરશો. જેમ કે અમે અમારી કંપની સિમ્પલ થ્રેડમાં વારંવાર કહીએ છીએ... એપ્લિકેશન કોઈ દિવસ ફરીથી લખવામાં આવશે, પરંતુ ડેટા કાયમ માટે જીવંત રહેશે. નોંધ: મોંગોડીબી સ્કીમા ચેકિંગને સપોર્ટ કરે છે: તે ઉપયોગી છે, પરંતુ રિલેશનલ ડેટાબેઝની સમાન ગેરંટી આપતું નથી. સૌ પ્રથમ, સ્કીમા ચેક ઉમેરવા અથવા બદલવાથી સંગ્રહમાં હાલના ડેટાને અસર થતી નથી. તમે નવી સ્કીમા અનુસાર ડેટા અપડેટ કરો છો તેની ખાતરી કરવી તમારા પર છે. તમારી જરૂરિયાતો માટે આ પૂરતું છે કે કેમ તે તમારા માટે નક્કી કરો.
• મૂળ ક્વેરી ભાષા / સાધન ઇકોસિસ્ટમનું નુકશાન: SQL નું આગમન એક સંપૂર્ણ ક્રાંતિ હતી અને ત્યારથી કંઈ બદલાયું નથી. તે અતિશય શક્તિશાળી ભાષા છે, પણ તદ્દન જટિલ પણ છે. જેએસએન ટુકડાઓનો સમાવેશ કરતી નવી ભાષામાં ડેટાબેઝ ક્વેરી બનાવવાની જરૂરિયાતને SQL સાથે કામ કરવાનો અનુભવ ધરાવતા લોકો દ્વારા પાછળનું એક મોટું પગલું માનવામાં આવે છે. ટૂલ્સનું એક આખું બ્રહ્માંડ છે જે IDEs થી લઈને રિપોર્ટિંગ ટૂલ્સ સુધી SQL ડેટાબેસેસ સાથે ક્રિયાપ્રતિક્રિયા કરે છે. SQL ને સપોર્ટ ન કરતા ડેટાબેઝ પર જવાનો અર્થ એ છે કે તમે આમાંના મોટાભાગના ટૂલ્સનો ઉપયોગ કરી શકતા નથી અથવા તમારે ડેટાનો ઉપયોગ કરવા માટે SQL માં અનુવાદ કરવો પડશે, જે તમને લાગે તે કરતાં વધુ મુશ્કેલ હોઈ શકે છે.

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

અલગ રીતે શું કરી શકાયું હોત?

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

કેવી રીતે યોગ્ય ટેકનોલોજી પસંદ કરવા માટે? ટેક્નોલોજીના મૂલ્યાંકન માટે વ્યવસ્થિત માળખું બનાવવાના ઘણા પ્રયાસો થયા છે, જેમ કે "સોફ્ટવેર સંસ્થાઓમાં ટેક્નોલોજીની રજૂઆત માટેનું માળખું" и "સોફ્ટવેર તકનીકોનું મૂલ્યાંકન કરવા માટેનું માળખું", પરંતુ મને લાગે છે કે આ બિનજરૂરી જટિલતા છે.

માત્ર બે મૂળભૂત પ્રશ્નો પૂછીને ઘણી તકનીકોનું બુદ્ધિપૂર્વક મૂલ્યાંકન કરી શકાય છે. સમસ્યા એવા લોકોને શોધવાની છે કે જેઓ તેમને જવાબદારીપૂર્વક જવાબ આપી શકે, જવાબો શોધવા માટે સમય કાઢીને અને પક્ષપાત વિના.

જો તમે કોઈ સમસ્યાનો સામનો કરી રહ્યાં નથી, તો તમારે નવા ટૂલની જરૂર નથી. ડોટ.

પ્રશ્ન 1: હું કઈ સમસ્યાઓ હલ કરવાનો પ્રયાસ કરી રહ્યો છું?

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

પ્રશ્ન 2: હું શું ગુમાવી રહ્યો છું?

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

જો તમારી પાસે ન હોય, તો આ સાધનનું મૂલ્ય નક્કી કરવા માટે લઘુત્તમ સંભવિત રોકાણ વિશે વિચારવું અર્થપૂર્ણ છે. અને એકવાર તમે રોકાણ કરી લો, પછી નિર્ણય પાછો ખેંચવો કેટલો મુશ્કેલ હશે?

લોકો હંમેશા બધું બગાડે છે

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

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

ઉદ્દેશ્ય મૂલ્યાંકન સરળ નથી, પરંતુ અંતર્ગત જ્ઞાનાત્મક પૂર્વગ્રહોને સમજવાથી તમને વધુ તર્કસંગત નિર્ણયો લેવામાં મદદ મળશે.

સારાંશ

જ્યારે પણ કોઈ નવીનતા દેખાય છે, ત્યારે બે પ્રશ્નોના જવાબ ખૂબ કાળજી સાથે આપવા જોઈએ:

• શું આ સાધન વાસ્તવિક સમસ્યાને હલ કરે છે?
• શું આપણે ટ્રેડ-ઓફ સારી રીતે સમજીએ છીએ?

જો તમે આત્મવિશ્વાસપૂર્વક આ બે પ્રશ્નોના જવાબ આપી શકતા નથી, તો થોડા પગલાં પાછળ જાઓ અને વિચારો.

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

અસ્વીકરણ

હું સ્પષ્ટ કરવા માંગુ છું કે મારો MongoDB સાથે પ્રેમ કે નફરતનો સંબંધ નથી. અમારી પાસે એવી સમસ્યાઓ નથી કે જેને ઉકેલવા માટે MongoDB શ્રેષ્ઠ અનુરૂપ છે. હું જાણું છું કે 10gen/MongoDB Inc. શરૂઆતમાં ખૂબ જ બોલ્ડ હતું, અસુરક્ષિત ડિફૉલ્ટ સેટ કરવું અને કોઈપણ ડેટા સાથે કામ કરવા માટે સાર્વત્રિક ઉકેલ તરીકે દરેક જગ્યાએ (ખાસ કરીને હેકાથોન્સમાં) મોંગોડીબીને પ્રોત્સાહન આપવું. તે કદાચ ખરાબ નિર્ણય હતો. પરંતુ તે અહીં વર્ણવેલ અભિગમની પુષ્ટિ કરે છે: ટેક્નોલોજીના સુપરફિસિયલ મૂલ્યાંકન સાથે પણ આ સમસ્યાઓ ખૂબ જ ઝડપથી શોધી શકાય છે.

સોર્સ: www.habr.com