Theory
જ્યારે rows અને columns તમારા data સામે લડે
BCA205 અને BCA303 માં તમે data ને tables માં સંઘરતા હતા: નિશ્ચિત columns, દરેક row એક જ આકારની, અને સંબંધિત tables એકબીજા સાથે join થયેલાં. એ શક્તિશાળી અને ચોક્કસ છે.
પણ FestConnect ના events table માં બેડોળ લાગે છે: સાંસ્કૃતિક event માં dress code હોય, coding contest માં programming ભાષાઓની list હોય, workshop માં સામગ્રીની list હોય. જુદા events, જુદાં fields. એમને એક જ કડક table માં ઠાંસવાનો અર્થ એ કે ડઝનેક columns મોટે ભાગે ખાલી રહે.
અહીં જ NoSQL databases ચમકે છે: એ કડક rows ને બદલે લવચીક, પોતાનું વર્ણન કરતાં documents સંઘરે છે. આ unit FestConnect નો data MongoDB પર ફરી બાંધે છે, અને શરૂઆત NoSQL શા માટે અસ્તિત્વમાં છે એનાથી થાય છે.
Theory
NoSQL, ઔપચારિક રીતે
NoSQL (જેને ઘણી વાર 'Not Only SQL' કે 'non-relational' તરીકે વાંચવામાં આવે છે) databases data ને relational databases વાળા નિશ્ચિત table-row-column ના schema વગર સંઘરે છે.
એના 4 મુખ્ય પ્રકાર છે:
- Document (MongoDB): JSON જેવાં documents તરીકે data: આ unit નું ધ્યાન એના પર છે
- Key-value (Redis): ચાવી અને કિંમતની સાદી જોડી
- Column-family (Cassandra): લવચીક columns વાળી rows
- Graph (Neo4j): nodes અને એમના સંબંધો
બધાને જોડતો વિચાર: કડક schema છોડી દો. Relational database દરેક event ને એક જ table ના આકારમાં બેસાડવાનું માગે છે, જ્યારે document database દરેક event ને એને જોઈતાં fields સાથે પોતાનું લવચીક document બનવા દે છે.
At a glance
Relational (SQL) સામે NoSQL
| બાબત | Relational (SQL) | NoSQL |
|---|---|---|
| માળખું | નિશ્ચિત tables, rows, columns | લવચીક: documents, key-values વગેરે |
| Schema | કડક, પહેલેથી નક્કી કરેલું | લવચીક કે schema વગરનું |
| સંબંધો | Tables વચ્ચે JOIN | ઘણી વાર અંદર જ ગોઠવેલા, joins વગર |
| વિસ્તરણ | સામાન્ય રીતે ઊભું (મોટો server) | આડું (ઘણા servers પર ફેલાવીને) |
| કયા માટે શ્રેષ્ઠ | ગૂંચવણભર્યા transactions, કડક સુસંગતતા | મોટા પાયાનો, બદલાતો, બંધારણ વગરનો data |
Theory
ફાયદા અને લક્ષણો
ટીમો NoSQL તરફ કેમ વળે છે:
- લવચીક schema: દરેક record માં fields જુદાં હોઈ શકે, એટલે data નું model પીડાદાયક migrations વગર વિકસે છે
- આડું વિસ્તરણ: servers ઉમેરીને બહાર તરફ ફેલાવો, જેથી ખૂબ મોટો data અને ભારે અવરજવર સંભાળી શકાય
- ઘણા વાચન અને લેખન વાળા કામ માટે ઊંચી કામગીરી
- બંધારણ વગરનો કે અર્ધબંધારણવાળો data કુદરતી રીતે સંભાળે છે
- વિકાસકાર માટે અનુકૂળ: documents program નાં objects સાથે સ્વચ્છ રીતે બંધબેસે છે (MongoDB નું document JavaScript ના object જેવું જ દેખાય છે)
એક પ્રામાણિક ભોગ પણ કહેવો જોઈએ: ઘણી NoSQL વ્યવસ્થાઓ ઉપલબ્ધતા અને વિસ્તરણ ખાતર કડક સુસંગતતા (relational databases જેને મૂલ્યવાન ગણે છે તે ACID ની ખાતરીઓ) ઢીલી કરે છે. એટલે NoSQL દરેક રીતે 'વધુ સારું' નથી: એ ભોગનો જુદો સમૂહ છે, અને ગૂંચવણભર્યા transactions તથા કડક સુસંગતતા માટે relational databases જ સાચી પસંદગી રહે છે.
Quiz
Relational databases ની સરખામણીમાં NoSQL databases નું ઓળખાણ આપતું લક્ષણ કયું છે?
- એ હંમેશા data ને કડક schemas વાળાં નિશ્ચિત tables માં સંઘરે છે
- એ લવચીક, table વગરનાં માળખાં (જેમ કે documents) વાપરે છે, ઘણી વાર કડક schema કે joins વગર
- એ કોઈ પણ બંધારણવાળો data સંઘરી શકતાં જ નથી
- એ દરેક પરિસ્થિતિમાં relational databases કરતાં હંમેશા વધુ ઝડપી હોય છે
Show the answer
એ લવચીક, table વગરનાં માળખાં (જેમ કે documents) વાપરે છે, ઘણી વાર કડક schema કે joins વગર
NoSQL નું ઓળખાણ આપતું લક્ષણ એ છે કે એ લવચીક, table વગરનો સંગ્રહ (documents, key-values, columns, graphs) વાપરે છે, સામાન્ય રીતે પહેલેથી નક્કી કરેલા કડક schema વગર અને ઘણી વાર joins વગર: એટલે કે વિકલ્પ A વર્ણવે છે તે નિશ્ચિત tables થી ઊલટું (એ તો relational છે). વિકલ્પ C અતિશયોક્તિ છે: NoSQL બંધારણવાળો અને અર્ધબંધારણવાળો data સારી રીતે સંભાળે છે; એ ફક્ત એક જ કડક આકાર લાદતું નથી. વિકલ્પ D એ 'NoSQL હંમેશા વધુ સારું' એવો ભ્રમ છે જેને આ પાઠ નકારે છે: NoSQL વિસ્તરણ અને લવચીકતામાં જીતે છે પણ સુસંગતતાની કેટલીક ખાતરીઓ જતી કરે છે, અને ગૂંચવણભર્યા transactions માટે relational databases હજી પણ વધુ સારાં છે. પ્રામાણિક વાત: ભોગ જુદા છે, કોઈ સર્વોપરી નથી.
Think first
FestConnect ના events ને documents કેમ બંધબેસે છે
FestConnect પાસે સાંસ્કૃતિક events, coding contests અને workshops છે, અને દરેકમાં જુદાં વધારાનાં fields છે. એક કડક table કરતાં document database આને વધુ સારી રીતે કેમ સંભાળે છે તે સમજાવો. પછી tap કરો.
Show the answer
Relational table માં દરેક event એ એક જ columns નો સમૂહ વહેંચવો પડે, એટલે તમારે કાં તો દરેક શક્ય field માટે (dress code, ભાષાઓની list, સામગ્રી...) column વાળું વિરાટ table બનાવવું પડે, જેમાંનાં મોટા ભાગનાં કોઈ પણ એક event માટે ખાલી હોય, અથવા એને ઘણાં join થયેલાં tables માં વહેંચવું પડે: બંને બેડોળ છે. Document database માં દરેક event પોતાનું document હોય છે અને એમાં બરાબર એને જોઈતાં fields જ હોય છે: Garba ના document માં dressCode નું field, coding-contest ના document માં languages નું array, workshop ના document માં સામગ્રીની list, અને એકેય બીજાનાં ખાલી fields ઊંચકતું નથી. કુદરતી રીતે બદલાતા data ને લવચીક schema બંધબેસે છે. તેમ છતાં, જો data ખૂબ એકસરખો હોય અને એમાં transactions ભારે હોય (જેમ કે bank ના ખાતાં), તો relational table જ વધુ સારું ઓજાર બને. Database ને data ના આકાર પ્રમાણે પસંદ કરો.
Watch out
NoSQL વિશેની ગેરસમજો
'NoSQL એટલે SQL જેવી queries જ નહીં': ઘણી NoSQL વ્યવસ્થાઓ પાસે સમૃદ્ધ query ભાષાઓ છે; નામનો અર્થ non-relational છે, query વગરનું નહીં.
'NoSQL હંમેશા વધુ સારું કે ઝડપી': એ વિસ્તરણ અને લવચીકતા બદલ સુસંગતતા જતી કરે છે; ગૂંચવણભર્યા transactions માટે relational વધુ સારું છે.
'Schema વગરનું એટલે બંધારણ વગરનું': documents ને પણ બંધારણ હોય જ છે; એ ફક્ત લવચીક છે, પહેલેથી લદાયેલું નથી.
ભોગ ભૂલી જવો: ઢીલી સુસંગતતા (eventual consistency) ઘણી NoSQL વ્યવસ્થાઓમાં ખરી કિંમત છે; તમારે કેટલી સુસંગતતા જોઈએ છે તે જાણો.
Theory
ખયાલથી MongoDB સુધી
NoSQL શા માટે અસ્તિત્વમાં છે એ હવે તમે સમજો છો: કડક tables માં ન બેસતા data માટે લવચીક, વિસ્તરી શકે એવો સંગ્રહ. Unit 1 નો બાકીનો ભાગ સૌથી લોકપ્રિય document database, એટલે કે MongoDB સાથે નક્કર બને છે: એના data types, databases તથા collections બનાવવાં અને કાઢવાં, પછી પૂરેપૂરું CRUD (create, read, update, delete) અને query, projection તથા aggregation ના operators. FestConnect ના events હવે MongoDB નાં documents બનવાના છે. પછી React અને Angular એની ઉપર આધુનિક UI બાંધે છે.
Summary
Key takeaways
- NoSQL databases data ને relational databases વાળાં કડક tables ને બદલે લવચીક, table વગરનાં માળખાંમાં સંઘરે છે.
- ચાર મુખ્ય પ્રકાર: document (MongoDB), key-value, column-family, graph.
- Relational સામે: લવચીક કે schema વગરનું સામે કડક schema; અંદર ગોઠવેલો data સામે joins; આડું વિસ્તરણ સામે ઊભું વિસ્તરણ.
- ફાયદા: લવચીક schema, આડું વિસ્તરણ, ઊંચી કામગીરી, બંધારણ વગરનો data સંભાળે, અને objects સાથે બંધબેસે.
- ભોગ: ઘણી NoSQL વ્યવસ્થાઓ ઉપલબ્ધતા અને વિસ્તરણ ખાતર કડક સુસંગતતા (ACID) ઢીલી કરે છે.
- NoSQL બધી રીતે વધુ સારું નથી: ગૂંચવણભર્યા transactions અને કડક સુસંગતતા માટે relational હજી પણ શ્રેષ્ઠ છે.
- યાદ રાખવાની કડી: NoSQL કડક table છોડીને લવચીક documents લે છે, અને વિસ્તરણ ખાતર કડક સુસંગતતા જતી કરે છે.