NoSQL માટે ડેટા મોડલ ડિઝાઇન કરવાની સુવિધાઓ

પરિચય

"તમારે સ્થાન પર રહેવા માટે જેટલું ઝડપથી ચલાવવું પડશે,
અને ક્યાંક પહોંચવા માટે, તમારે ઓછામાં ઓછી બમણી ઝડપે દોડવું પડશે!"
(c) એલિસ ઇન વન્ડરલેન્ડ

થોડા સમય પહેલા મને એક લેક્ચર આપવાનું કહેવામાં આવ્યું વિશ્લેષકો અમારી કંપની ડેટા મૉડલ્સ ડિઝાઇન કરવાના વિષય પર છે, કારણ કે લાંબા સમય સુધી પ્રોજેક્ટ્સ પર બેસીને (કેટલીકવાર ઘણા વર્ષો સુધી) અમે આઈટી ટેક્નોલોજીની દુનિયામાં આપણી આસપાસ શું થઈ રહ્યું છે તેની દૃષ્ટિ ગુમાવીએ છીએ. અમારી કંપનીમાં (તે એવું જ થાય છે) ઘણા પ્રોજેક્ટ્સ NoSQL ડેટાબેસેસનો ઉપયોગ કરતા નથી (ઓછામાં ઓછા હમણાં માટે), તેથી મારા પ્રવચનમાં મેં HBase ના ઉદાહરણનો ઉપયોગ કરીને તેમના પર અલગથી ધ્યાન આપ્યું અને સામગ્રીની રજૂઆતને તે લોકો માટે દિશામાન કરવાનો પ્રયાસ કર્યો. જેમણે ક્યારેય તેનો ઉપયોગ કર્યો નથી તેઓએ કામ કર્યું છે. ખાસ કરીને, મેં ઘણા વર્ષો પહેલા વાંચેલા ઉદાહરણનો ઉપયોગ કરીને ડેટા મોડેલ ડિઝાઇનની કેટલીક વિશેષતાઓ દર્શાવી અમનદીપ ખુરાના દ્વારા “HB ase સ્કીમા ડિઝાઇનનો પરિચય” લેખમાં. ઉદાહરણોનું વિશ્લેષણ કરતી વખતે, મેં મુખ્ય વિચારોને પ્રેક્ષકો સુધી વધુ સારી રીતે પહોંચાડવા માટે સમાન સમસ્યાને ઉકેલવા માટેના ઘણા વિકલ્પોની તુલના કરી.

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

ઉદાહરણ વિશ્લેષણ

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

ચાલો નીચેની "કૃત્રિમ" સમસ્યાને ધ્યાનમાં લઈએ, જેની સાથે આપણે કામ કરવાનું ચાલુ રાખીશું:

કેટલાક અમૂર્ત સામાજિક નેટવર્કના વપરાશકર્તાઓના મિત્રોની સૂચિ માટે સ્ટોરેજ સ્ટ્રક્ચર ડિઝાઇન કરવું જરૂરી છે. સરળ બનાવવા માટે, અમે ધારીશું કે અમારા બધા જોડાણો નિર્દેશિત છે (જેમ કે Instagram પર, Linkedin પર નહીં). રચનાએ તમને અસરકારક રીતે પરવાનગી આપવી જોઈએ:

• પ્રશ્નનો જવાબ આપો કે શું વપરાશકર્તા A વપરાશકર્તા B વાંચે છે (રીડિંગ પેટર્ન)
• વપરાશકર્તા B (ડેટા ચેન્જ ટેમ્પલેટ) માંથી વપરાશકર્તા A ના સબ્સ્ક્રિપ્શન/અનસબ્સ્ક્રિપ્શનના કિસ્સામાં જોડાણો ઉમેરવા/દૂર કરવાની મંજૂરી આપો

અલબત્ત, સમસ્યા હલ કરવા માટે ઘણા વિકલ્પો છે. નિયમિત રિલેશનલ ડેટાબેઝમાં, અમે સંભવતઃ સરળ રીતે સંબંધોનું ટેબલ બનાવીશું (જો, ઉદાહરણ તરીકે, અમારે વપરાશકર્તા જૂથ સંગ્રહિત કરવાની જરૂર હોય તો: કુટુંબ, કાર્ય, વગેરે, જેમાં આ "મિત્ર" શામેલ છે), અને ઑપ્ટિમાઇઝ કરવા માટે એક્સેસ સ્પીડ ઇન્ડેક્સ/પાર્ટીશન ઉમેરશે. મોટે ભાગે અંતિમ કોષ્ટક આના જેવું કંઈક દેખાશે:

user_id
મિત્ર_આઈડી

વાસ્યા
પેટ્યા

વાસ્યા
Olya

હવે પછી, સ્પષ્ટતા અને સારી સમજણ માટે, હું ID ને બદલે નામો સૂચવીશ

HBase ના કિસ્સામાં, આપણે જાણીએ છીએ કે:

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

તેથી, અમને વપરાશકર્તા ID નો ઉપયોગ કી તરીકે કરવાની ફરજ પડી છે. અને "મિત્રોના IDs ક્યાં અને કેવી રીતે સંગ્રહિત કરવા?" વિષય પર મારો પ્રથમ વિચાર કદાચ તેમને કૉલમમાં સંગ્રહિત કરવાનો વિચાર. આ સૌથી સ્પષ્ટ અને "નિષ્કપટ" વિકલ્પ કંઈક આના જેવો દેખાશે (ચાલો તેને કૉલ કરીએ વિકલ્પ 1 (ડિફૉલ્ટ)વધુ સંદર્ભ માટે):

RowKey
કૉલમ

વાસ્યા
1: પેટ્યા
2: ઓલ્યા
3: દશા

પેટ્યા
1: માશા
2: વાસ્યા

અહીં, દરેક લાઇન એક નેટવર્ક વપરાશકર્તાને અનુલક્ષે છે. કૉલમના નામ છે: 1, 2, ... - મિત્રોની સંખ્યા અનુસાર, અને મિત્રોના ID કૉલમમાં સંગ્રહિત છે. એ નોંધવું અગત્યનું છે કે દરેક પંક્તિમાં કૉલમની સંખ્યા અલગ હશે. ઉપરની આકૃતિમાંના ઉદાહરણમાં, એક પંક્તિમાં ત્રણ કૉલમ છે (1, 2 અને 3), અને બીજીમાં માત્ર બે (1 અને 2) છે - અહીં આપણે પોતે બે HBase ગુણધર્મોનો ઉપયોગ કર્યો છે જે રીલેશનલ ડેટાબેઝ પાસે નથી:

• કૉલમની રચનાને ગતિશીલ રીતે બદલવાની ક્ષમતા (મિત્ર ઉમેરો -> કૉલમ ઉમેરો, મિત્રને દૂર કરો -> કૉલમ કાઢી નાખો)
• અલગ-અલગ પંક્તિઓમાં અલગ-અલગ કૉલમ કમ્પોઝિશન હોઈ શકે છે

ચાલો કાર્યની આવશ્યકતાઓનું પાલન કરવા માટે અમારી રચના તપાસીએ:

• ડેટા વાંચન: વાસ્ય ઓલ્યામાં સબ્સ્ક્રાઇબ થયેલ છે કે કેમ તે સમજવા માટે, આપણે બાદબાકી કરવાની જરૂર પડશે આખી લાઇન કી RowKey = "વાસ્ય" દ્વારા અને કૉલમ મૂલ્યો દ્વારા સૉર્ટ કરો જ્યાં સુધી આપણે તેમાં ઓલ્યાને "મળીએ" નહીં. અથવા તમામ કૉલમના મૂલ્યો દ્વારા પુનરાવર્તન કરો, ઓલ્યાને "મળતા નથી" અને જવાબ ખોટા આપો;
• ડેટા સંપાદન: મિત્ર ઉમેરવું: સમાન કાર્ય માટે આપણે બાદબાકી કરવાની પણ જરૂર છે આખી લાઇન તેના મિત્રોની કુલ સંખ્યા ગણવા માટે RowKey = “વાસ્ય” કીનો ઉપયોગ કરો. આપણે જે કૉલમમાં નવા મિત્રનું ID લખવાની જરૂર છે તેની સંખ્યા નક્કી કરવા માટે અમને મિત્રોની આ કુલ સંખ્યાની જરૂર છે.
• ડેટા બદલવો: મિત્રને કાઢી નાખવું:
  • બાદબાકી કરવાની જરૂર છે આખી લાઇન કી RowKey = “વાસ્ય” દ્વારા અને જે મિત્રને કાઢી નાખવાનો છે તે શોધવા માટે કૉલમ દ્વારા સૉર્ટ કરો;
  • આગળ, મિત્રને કાઢી નાખ્યા પછી, અમારે તમામ ડેટાને એક કૉલમમાં "શિફ્ટ" કરવાની જરૂર છે જેથી તેમના નંબરિંગમાં "ગેપ" ન આવે.

ચાલો હવે મૂલ્યાંકન કરીએ કે આ અલ્ગોરિધમ્સ, જેને આપણે "શરતી એપ્લિકેશન" બાજુએ અમલમાં મૂકવાની જરૂર પડશે, તેનો ઉપયોગ કરીને કેટલા ઉત્પાદક હશે. ઓ-પ્રતીકવાદ. ચાલો આપણા અનુમાનિત સામાજિક નેટવર્કના કદને n તરીકે દર્શાવીએ. પછી એક વપરાશકર્તા પાસે મહત્તમ મિત્રોની સંખ્યા છે (n-1). અમે અમારા હેતુઓ માટે આ (-1)ને વધુ અવગણી શકીએ છીએ, કારણ કે O-ચિહ્નોના ઉપયોગના માળખામાં તે બિનમહત્વપૂર્ણ છે.

• ડેટા વાંચન: સમગ્ર લીટી બાદબાકી કરવી અને તેના તમામ કોલમ દ્વારા મર્યાદામાં પુનરાવર્તન કરવું જરૂરી છે. આનો અર્થ એ છે કે ખર્ચનો ઉપલા અંદાજ અંદાજે O(n) હશે
• ડેટા સંપાદન: મિત્ર ઉમેરવું: મિત્રોની સંખ્યા નક્કી કરવા માટે, તમારે પંક્તિના તમામ કૉલમ દ્વારા પુનરાવર્તન કરવાની જરૂર છે, અને પછી નવી કૉલમ દાખલ કરો => O(n)
• ડેટા બદલવો: મિત્રને કાઢી નાખવું:
  • ઉમેરવા જેવું જ - તમારે મર્યાદા => O(n) માં તમામ કૉલમ્સમાંથી પસાર થવાની જરૂર છે
  • કૉલમ દૂર કર્યા પછી, આપણે તેમને "ખસેડવાની" જરૂર છે. જો તમે આ "હેડ-ઓન" નો અમલ કરો છો, તો પછી મર્યાદામાં તમારે (n-1) સુધીની કામગીરીની જરૂર પડશે. પરંતુ અહીં અને આગળ વ્યવહારુ ભાગમાં આપણે એક અલગ અભિગમનો ઉપયોગ કરીશું, જે ચોક્કસ સંખ્યામાં કામગીરી માટે "સ્યુડો-શિફ્ટ" લાગુ કરશે - એટલે કે, n ને ધ્યાનમાં લીધા વિના, તેના પર સતત સમય પસાર કરવામાં આવશે. આ સતત સમય (O(2) ચોક્કસ હોવા માટે) O(n) ની સરખામણીમાં અવગણવામાં આવી શકે છે. અભિગમ નીચેની આકૃતિમાં સચિત્ર છે: અમે ફક્ત "છેલ્લી" કૉલમમાંથી ડેટાને કૉપિ કરીએ છીએ જેમાંથી આપણે ડેટા કાઢી નાખવા માંગીએ છીએ, અને પછી છેલ્લી કૉલમ કાઢી નાખીએ છીએ:
    

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

RowKey
કૉલમ

વાસ્યા
1: પેટ્યા
2: ઓલ્યા
3: દશા
ગણતરી: 3

પેટ્યા
1: માશા
2: વાસ્યા

ગણતરી: 2

પ્રથમ વિકલ્પની તુલનામાં:

• ડેટા વાંચન: પ્રશ્નનો જવાબ મેળવવા માટે "શું વાસ્યા ઓલ્યા વાંચે છે?" કંઈ બદલાયું નથી => O(n)
• ડેટા સંપાદન: મિત્ર ઉમેરવું: અમે નવા મિત્રના નિવેશને સરળ બનાવ્યું છે, કારણ કે હવે આપણે આખી લીટી વાંચવાની અને તેના કૉલમ પર પુનરાવર્તન કરવાની જરૂર નથી, પરંતુ ફક્ત "ગણતરી" કૉલમ વગેરેની કિંમત મેળવી શકીએ છીએ. નવા મિત્રને દાખલ કરવા માટે તરત જ કૉલમ નંબર નક્કી કરો. આ O(1) ની કોમ્પ્યુટેશનલ જટિલતામાં ઘટાડો તરફ દોરી જાય છે
• ડેટા બદલવો: મિત્રને કાઢી નાખવું: મિત્રને કાઢી નાખતી વખતે, ડેટા એક કોષને ડાબી બાજુએ "શિફ્ટ" કરતી વખતે અમે I/O કામગીરીની સંખ્યા ઘટાડવા માટે પણ આ કૉલમનો ઉપયોગ કરી શકીએ છીએ. પરંતુ જેને કાઢી નાખવાની જરૂર છે તે શોધવા માટે કૉલમ દ્વારા પુનરાવર્તિત કરવાની જરૂર હજુ પણ રહે છે, તેથી => O(n)
• બીજી બાજુ, હવે ડેટા અપડેટ કરતી વખતે અમારે દર વખતે "કાઉન્ટ" કૉલમ અપડેટ કરવાની જરૂર છે, પરંતુ આમાં સતત સમય લાગે છે, જેને O-સિમ્બોલના માળખામાં અવગણી શકાય છે.

સામાન્ય રીતે, વિકલ્પ 2 થોડો વધુ શ્રેષ્ઠ લાગે છે, પરંતુ તે "ક્રાંતિને બદલે ઉત્ક્રાંતિ" જેવો છે. "ક્રાંતિ" કરવા માટે આપણને જરૂર પડશે વિકલ્પ 3 (કોલ).
ચાલો બધું "ઉલટું" ફેરવીએ: અમે નિમણૂક કરીશું કૉલમ નામ વપરાશકર્તા ID! કૉલમમાં શું લખવામાં આવશે તે હવે આપણા માટે મહત્વપૂર્ણ નથી, તેને નંબર 1 રહેવા દો (સામાન્ય રીતે, ઉપયોગી વસ્તુઓ ત્યાં સંગ્રહિત કરી શકાય છે, ઉદાહરણ તરીકે, જૂથ "કુટુંબ/મિત્રો/વગેરે."). આ અભિગમ તૈયારી વિનાના "સામાન્ય માણસ" ને આશ્ચર્યચકિત કરી શકે છે જેમને NoSQL ડેટાબેસેસ સાથે કામ કરવાનો અગાઉનો અનુભવ નથી, પરંતુ તે ચોક્કસપણે આ અભિગમ છે જે તમને આ કાર્યમાં HBase ની સંભવિતતાનો વધુ અસરકારક રીતે ઉપયોગ કરવાની મંજૂરી આપે છે:

RowKey
કૉલમ

વાસ્યા
પેટ્યા: 1
ઓલ્યા: 1
દશા: 1

પેટ્યા
માશા: 1
વાસ્ય: 1

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

• ડેટા વાંચન: વાસ્યાએ ઓલ્યાનું સબ્સ્ક્રાઇબ કર્યું છે કે કેમ તે પ્રશ્નનો જવાબ આપવા માટે, એક કૉલમ "ઓલ્યા" વાંચવા માટે પૂરતું છે: જો તે ત્યાં છે, તો જવાબ સાચો છે, જો નહીં - ખોટું => O(1)
• ડેટા સંપાદન: મિત્ર ઉમેરવું: મિત્ર ઉમેરવું: ફક્ત એક નવી કૉલમ ઉમેરો “મિત્ર ID” => O(1)
• ડેટા બદલવો: મિત્રને કાઢી નાખવું: ફક્ત મિત્ર ID કૉલમ => O(1) દૂર કરો

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

તમે મૂંઝવણમાં પડી શકો છો અને ડેટાબેઝને ઍક્સેસ કરતી વખતે પ્રદર્શનને ઑપ્ટિમાઇઝ કરવા અને I/O ઑપરેશન ઘટાડવાના માર્ગ સાથે થોડું આગળ જઈ શકો છો. જો આપણે સીધી જ પંક્તિ કીમાં સંપૂર્ણ સંબંધ માહિતી સંગ્રહિત કરીએ તો શું? એટલે કે યુઝરઆઈડી.ફ્રેન્ડઆઈડી જેવી કી કમ્પોઝીટ બનાવો? આ કિસ્સામાં, આપણે લાઇનની કૉલમ્સ પણ વાંચવાની જરૂર નથી (વિકલ્પ 4(પંક્તિ)):

RowKey
કૉલમ

વાસ્યા.પેટ્યા
પેટ્યા: 1

વાસ્યા.ઓલ્યા
ઓલ્યા: 1

વાસ્યા.દશા
દશા: 1

પેટ્યા.માશા
માશા: 1

પેટ્યા.વાસ્યા
વાસ્ય: 1

દેખીતી રીતે, અગાઉના સંસ્કરણની જેમ, આવા માળખામાં તમામ ડેટા મેનીપ્યુલેશન દૃશ્યોનું મૂલ્યાંકન O(1) હશે. વિકલ્પ 3 સાથેનો તફાવત ફક્ત ડેટાબેઝમાં I/O કામગીરીની કાર્યક્ષમતામાં હશે.

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

RowKey
કૉલમ

dc084ef00e94aef49be885f9b01f51c01918fa783851db0dc1f72f83d33a5994
પેટ્યા: 1

dc084ef00e94aef49be885f9b01f51c0f06b7714b5ba522c3cf51328b66fe28a
ઓલ્યા: 1

dc084ef00e94aef49be885f9b01f51c00d2c2e5d69df6b238754f650d56c896a
દશા: 1

1918fa783851db0dc1f72f83d33a59949ee3309645bd2c0775899fca14f311e1
માશા: 1

1918fa783851db0dc1f72f83d33a5994dc084ef00e94aef49be885f9b01f51c0
વાસ્ય: 1

દેખીતી રીતે, અમે વિચારી રહ્યા છીએ તેવા સંજોગોમાં આવા માળખા સાથે કામ કરવાની અલ્ગોરિધમિક જટિલતા વિકલ્પ 4 - એટલે કે O(1) જેવી જ હશે.
કુલ મળીને, ચાલો એક કોષ્ટકમાં કોમ્પ્યુટેશનલ જટિલતાના અમારા તમામ અંદાજોનો સારાંશ આપીએ:

મિત્ર ઉમેરી રહ્યા છીએ
મિત્રની તપાસ કરી રહ્યાં છીએ
મિત્રને દૂર કરી રહ્યા છીએ

વિકલ્પ 1 (ડિફૉલ્ટ)
ઓ (એન)
ઓ (એન)
ઓ (એન)

વિકલ્પ 2 (ગણતરી)
ઓ (1)
ઓ (એન)
ઓ (એન)

વિકલ્પ 3 (કૉલમ)
ઓ (1)
ઓ (1)
ઓ (1)

વિકલ્પ 4 (પંક્તિ)
ઓ (1)
ઓ (1)
ઓ (1)

વિકલ્પ 5 (હેશ)
ઓ (1)
ઓ (1)
ઓ (1)

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

પ્રયોગની તૈયારી

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

• એક નવો મિત્ર ઉમેરી રહ્યા છીએ
• વપરાશકર્તા A એ વપરાશકર્તા B નો મિત્ર છે કે કેમ તે તપાસી રહ્યું છે
• એક મિત્રને દૂર કરી રહ્યાં છીએ

આમ, પ્રારંભિક નિવેદનમાં દર્શાવેલ આવશ્યકતાઓને ધ્યાનમાં લેતા, ચકાસણીનું દૃશ્ય નીચે મુજબ ઉભરી આવે છે:

• ડેટા રેકોર્ડિંગ. રેન્ડમલી કદ n નું પ્રારંભિક નેટવર્ક જનરેટ કરો. "વાસ્તવિક વિશ્વ" ની નજીક જવા માટે, દરેક વપરાશકર્તા પાસે મિત્રોની સંખ્યા પણ રેન્ડમ ચલ છે. તે સમયને માપો કે જે દરમિયાન અમારી “શરતી એપ્લિકેશન” તમામ જનરેટ થયેલ ડેટા HBase પર લખે છે. પછી પરિણામી સમયને ઉમેરેલા મિત્રોની કુલ સંખ્યા દ્વારા વિભાજીત કરો - આ રીતે આપણે એક "વ્યવસાયિક કામગીરી" માટે સરેરાશ સમય મેળવીએ છીએ.
• ડેટા વાંચન. દરેક વપરાશકર્તા માટે, "વ્યક્તિત્વ" ની સૂચિ બનાવો જેના માટે તમારે જવાબ મેળવવાની જરૂર છે કે વપરાશકર્તાએ તેમને સબ્સ્ક્રાઇબ કર્યું છે કે નહીં. સૂચિની લંબાઈ = વપરાશકર્તાના મિત્રોની આશરે સંખ્યા, અને ચેક કરેલા મિત્રોમાંથી અડધા માટે જવાબ "હા" હોવો જોઈએ, અને બીજા અડધા માટે - "ના" હોવો જોઈએ. ચેક એવા ક્રમમાં કરવામાં આવે છે કે જવાબો "હા" અને "ના" વૈકલ્પિક આવે છે (એટલે ​​​​કે, દરેક બીજા કિસ્સામાં આપણે વિકલ્પો 1 અને 2 માટે લાઇનના તમામ કૉલમમાંથી પસાર થવું પડશે). કુલ સ્ક્રીનીંગ સમય પછી વિષય દીઠ સરેરાશ સ્ક્રીનીંગ સમય મેળવવા માટે પરીક્ષણ કરાયેલા મિત્રોની સંખ્યા દ્વારા વિભાજિત કરવામાં આવે છે.
• ડેટા કાઢી રહ્યું છે. વપરાશકર્તામાંથી બધા મિત્રોને દૂર કરો. વધુમાં, કાઢી નાખવાનો ક્રમ રેન્ડમ છે (એટલે ​​કે, અમે ડેટા રેકોર્ડ કરવા માટે વપરાતી મૂળ સૂચિને "શફલ" કરીએ છીએ). ચેક દીઠ સરેરાશ સમય મેળવવા માટે કુલ ચેક સમયને પછી દૂર કરાયેલા મિત્રોની સંખ્યા વડે ભાગવામાં આવે છે.

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

• પ્રથમ એક નિવેશ માટે છે
• બીજી તપાસ માટે છે
• ત્રીજું - કાઢી નાખવા માટે

{0: [1], 1: [4, 5, 3, 2, 1], 2: [1, 2], 3: [2, 4, 1, 5, 3], 4: [2, 1]} # всего 15 друзей

{0: [1, 10800], 1: [5, 10800, 2, 10801, 4, 10802], 2: [1, 10800], 3: [3, 10800, 1, 10801, 5, 10802], 4: [2, 10800]} # всего 18 проверяемых субъектов

{0: [1], 1: [1, 3, 2, 5, 4], 2: [1, 2], 3: [4, 1, 2, 3, 5], 4: [1, 2]} # всего 15 друзей

જેમ તમે જોઈ શકો છો, ચકાસવા માટે શબ્દકોશમાં 10 થી વધુની તમામ ID ચોક્કસપણે તે છે જે ચોક્કસપણે જવાબ ખોટા આપશે. "મિત્રો" દાખલ કરવું, તપાસવું અને કાઢી નાખવું એ શબ્દકોશમાં ઉલ્લેખિત ક્રમમાં બરાબર કરવામાં આવે છે.

આ પ્રયોગ વિન્ડોઝ 10 ચલાવતા લેપટોપ પર કરવામાં આવ્યો હતો, જ્યાં એક ડોકર કન્ટેનરમાં HBase ચાલી રહ્યું હતું, અને બીજામાં Jupyter Notebook સાથે Python ચાલી રહ્યું હતું. ડોકરને 2 CPU કોરો અને 2 GB RAM ફાળવવામાં આવી હતી. પરીક્ષણ ડેટા જનરેટ કરવા અને સમય માપવા માટે "શરતી એપ્લિકેશન" નું અનુકરણ અને "પાઈપિંગ" બંને તમામ તર્ક, પાયથોનમાં લખવામાં આવ્યા હતા. પુસ્તકાલયનો ઉપયોગ HBase સાથે કામ કરવા માટે થતો હતો હેપીબેઝ, વિકલ્પ 5 માટે હેશ (MD5) ની ગણતરી કરવા - hashlib

ચોક્કસ લેપટોપની કમ્પ્યુટિંગ શક્તિને ધ્યાનમાં લેતા, n = 10, 30, … માટે લોન્ચ પ્રાયોગિક રીતે પસંદ કરવામાં આવ્યું હતું. 170 – જ્યારે સંપૂર્ણ પરીક્ષણ ચક્રનો કુલ ઓપરેટિંગ સમય (બધા n માટેના તમામ વિકલ્પો માટેના તમામ દૃશ્યો) એક ટી પાર્ટી (સરેરાશ 15 મિનિટ) દરમિયાન વધુ કે ઓછા વાજબી અને યોગ્ય હતો.

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

પ્રયોગનું પરિણામ

પ્રથમ કસોટી એ છે કે મિત્રોની યાદી ભરવામાં વિતાવેલો સમય કેવી રીતે બદલાય છે. પરિણામ નીચેના ગ્રાફમાં છે.

વિકલ્પો 3-5, અપેક્ષા મુજબ, લગભગ સતત "વ્યવસાય વ્યવહાર" સમય દર્શાવે છે, જે નેટવર્કના કદની વૃદ્ધિ અને પ્રદર્શનમાં અસ્પષ્ટ તફાવત પર આધારિત નથી.
વિકલ્પ 2 પણ સતત, પરંતુ સહેજ ખરાબ પ્રદર્શન દર્શાવે છે, વિકલ્પો 2-3ની તુલનામાં લગભગ 5 ગણું. અને આ આનંદ કરી શકતું નથી, કારણ કે તે સિદ્ધાંત સાથે સંબંધિત છે - આ સંસ્કરણમાં HBase થી/થી I/O ઑપરેશન્સની સંખ્યા બરાબર 2 ગણી વધારે છે. આ પરોક્ષ પુરાવા તરીકે સેવા આપી શકે છે કે અમારી ટેસ્ટ બેન્ચ, સૈદ્ધાંતિક રીતે, સારી ચોકસાઈ પ્રદાન કરે છે.
વિકલ્પ 1 પણ, અપેક્ષા મુજબ, સૌથી ધીમું નીકળે છે અને નેટવર્કના કદમાં એક બીજાને ઉમેરવામાં વિતાવેલા સમયમાં રેખીય વધારો દર્શાવે છે.
ચાલો હવે બીજી પરીક્ષાના પરિણામો જોઈએ.

વિકલ્પો 3-5 ફરીથી અપેક્ષા મુજબ વર્તે છે - સતત સમય, નેટવર્કના કદથી સ્વતંત્ર. વિકલ્પો 1 અને 2 નેટવર્કના કદમાં વધારો અને સમાન કાર્યક્ષમતા સાથે સમયની રેખીય વધારો દર્શાવે છે. તદુપરાંત, વિકલ્પ 2 થોડો ધીમો નીકળે છે - દેખીતી રીતે વધારાની "ગણતરી" કૉલમને પ્રૂફરીડ કરવાની અને પ્રક્રિયા કરવાની જરૂરિયાતને કારણે, જે n વધે તેમ વધુ ધ્યાનપાત્ર બને છે. પરંતુ હું હજી પણ કોઈપણ તારણો દોરવાનું ટાળીશ, કારણ કે આ સરખામણીની ચોકસાઈ પ્રમાણમાં ઓછી છે. વધુમાં, આ ગુણોત્તર (કયો વિકલ્પ, 1 અથવા 2, ઝડપી છે) રનથી રનમાં બદલાયો (જ્યારે અવલંબનનું સ્વરૂપ જાળવી રાખ્યું અને "ગળા અને ગરદન પર જાઓ").

ઠીક છે, છેલ્લો ગ્રાફ એ દૂર કરવાના પરીક્ષણનું પરિણામ છે.

ફરીથી, અહીં કોઈ આશ્ચર્ય નથી. વિકલ્પો 3-5 સતત સમય માં દૂર કરે છે.
વધુમાં, રસપ્રદ રીતે, વિકલ્પો 4 અને 5, અગાઉના દૃશ્યોથી વિપરીત, વિકલ્પ 3 કરતાં નોંધપાત્ર રીતે સહેજ ખરાબ પ્રદર્શન દર્શાવે છે. દેખીતી રીતે, પંક્તિ કાઢી નાખવાની કામગીરી કૉલમ કાઢી નાખવાની કામગીરી કરતાં વધુ ખર્ચાળ છે, જે સામાન્ય રીતે તાર્કિક છે.

વિકલ્પો 1 અને 2, અપેક્ષા મુજબ, સમય માં રેખીય વધારો દર્શાવે છે. તે જ સમયે, વિકલ્પ 2 વિકલ્પ 1 કરતાં સતત ધીમો છે - ગણતરી કૉલમને "જાળવવા" માટે વધારાના I/O ઑપરેશનને કારણે.

પ્રયોગના સામાન્ય તારણો:

• વિકલ્પો 3-5 વધુ કાર્યક્ષમતા દર્શાવે છે કારણ કે તેઓ HBase નો લાભ લે છે; તદુપરાંત, તેમનું પ્રદર્શન સતત એકબીજાની તુલનામાં અલગ પડે છે અને નેટવર્કના કદ પર આધારિત નથી.
• વિકલ્પો 4 અને 5 વચ્ચેનો તફાવત નોંધવામાં આવ્યો ન હતો. પરંતુ આનો અર્થ એ નથી કે વિકલ્પ 5 નો ઉપયોગ કરવો જોઈએ નહીં. સંભવ છે કે ઉપયોગમાં લેવાયેલ પ્રાયોગિક દૃશ્ય, પરીક્ષણ બેંચની કામગીરીની લાક્ષણિકતાઓને ધ્યાનમાં લેતા, તેને શોધવાની મંજૂરી આપી ન હતી.
• ડેટા સાથે "વ્યવસાયિક કામગીરી" કરવા માટે જરૂરી સમયના વધારાની પ્રકૃતિ સામાન્ય રીતે તમામ વિકલ્પો માટે અગાઉ મેળવેલ સૈદ્ધાંતિક ગણતરીઓની પુષ્ટિ કરે છે.

ઉપસંહાર

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

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

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

સોર્સ: www.habr.com