વાસ્તવિક એપ્લિકેશનમાં ક્લિકહાઉસનો ઉપયોગ કરવાનો સિદ્ધાંત અને પ્રેક્ટિસ. એલેક્ઝાન્ડર ઝૈત્સેવ (2018)

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

બેકએન્ડ કોન્ફ 2018 નો અહેવાલ અને તે સ્પીકરની પરવાનગીથી પ્રકાશિત કરવામાં આવ્યો છે.

હું કોણ છું અને શા માટે હું ક્લિકહાઉસ વિશે વાત કરી રહ્યો છું? હું લાઇફસ્ટ્રીટનો વિકાસ નિર્દેશક છું, જે ક્લિકહાઉસનો ઉપયોગ કરે છે. ઉપરાંત, હું Altinityનો સ્થાપક છું. તે યાન્ડેક્ષ ભાગીદાર છે જે ક્લિકહાઉસને પ્રોત્સાહન આપે છે અને યાન્ડેક્સને ક્લિકહાઉસને વધુ સફળ બનાવવામાં મદદ કરે છે. ક્લિકહાઉસ વિશે જ્ઞાન શેર કરવા માટે પણ તૈયાર છે.

અને હું પેટ્યા ઝૈત્સેવનો ભાઈ નથી. મને વારંવાર આ વિશે પૂછવામાં આવે છે. ના, અમે ભાઈઓ નથી.

"દરેક જણ જાણે છે" તે ક્લિકહાઉસ:

• ખૂબ જ ઝડપી,
• ખૂબ આરામદાયક
• યાન્ડેક્ષમાં વપરાય છે.

કઈ કંપનીઓમાં અને કેવી રીતે તેનો ઉપયોગ થાય છે તે થોડું ઓછું જાણીતું છે.

હું તમને કહીશ કે શા માટે, ક્યાં અને કેવી રીતે ક્લિકહાઉસનો ઉપયોગ થાય છે, યાન્ડેક્સ સિવાય.

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

મેં ત્રણ ઉદાહરણો લીધા છે જે વિવિધ ખૂણાઓથી ક્લિકહાઉસ દર્શાવે છે. મને લાગે છે કે તે રસપ્રદ રહેશે.

પ્રથમ પ્રશ્ન છે: "અમને ક્લિકહાઉસની કેમ જરૂર છે?". તે એકદમ સ્પષ્ટ પ્રશ્ન લાગે છે, પરંતુ તેના એક કરતા વધુ જવાબો છે.

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

ક્લિકહાઉસમાં આ સમસ્યાઓ નથી.

હવે ક્લિકહાઉસ ક્યાં વપરાય છે? યાન્ડેક્સ ઉપરાંત, ક્લિકહાઉસનો ઉપયોગ વિવિધ વ્યવસાયો અને કંપનીઓના સમૂહમાં થાય છે.

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

અને કદ વાંધો નથી. એવી ઘણી કંપનીઓ છે જે એક નાના સર્વરનો ઉપયોગ કરે છે. અને તે તેમને તેમની સમસ્યાઓ હલ કરવા દે છે. અને તેનાથી પણ વધુ કંપનીઓ ઘણા સર્વર્સ અથવા ડઝનેક સર્વર્સના મોટા ક્લસ્ટરોનો ઉપયોગ કરે છે.

અને જો તમે રેકોર્ડ્સ જુઓ, તો પછી:

• યાન્ડેક્ષ: 500+ સર્વર્સ, તેઓ ત્યાં એક દિવસમાં 25 બિલિયન રેકોર્ડ્સ સ્ટોર કરે છે.
• લાઇફસ્ટ્રીટ: 60 સર્વર્સ, દરરોજ આશરે 75 બિલિયન રેકોર્ડ્સ. યાન્ડેક્ષ કરતાં ઓછા સર્વર્સ, વધુ રેકોર્ડ્સ છે.
• CloudFlare: 36 સર્વર્સ, તેઓ એક દિવસમાં 200 બિલિયન રેકોર્ડ બચાવે છે. તેમની પાસે પણ ઓછા સર્વર છે અને તે પણ વધુ ડેટા સ્ટોર કરે છે.
• બ્લૂમબર્ગ: 102 સર્વર્સ, દરરોજ લગભગ એક ટ્રિલિયન એન્ટ્રીઓ. રેકોર્ડ ધારક.

ભૌગોલિક રીતે, આ પણ ઘણું છે. આ નકશો અહીંનો હીટમેપ બતાવે છે જ્યાં ક્લિકહાઉસ વિશ્વમાં ઉપયોગમાં લેવાય છે. રશિયા, ચીન, અમેરિકા અહીં સ્પષ્ટ રીતે ઉભા છે. ત્યાં થોડા યુરોપિયન દેશો છે. અને ત્યાં 4 ક્લસ્ટર છે.

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

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

આ ઘણી કંપનીઓમાં વાસ્તવિક ક્લિકહાઉસના ઉપયોગના ઉદાહરણો છે.

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

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

કંપનીએ લાંબો અને કાંટાળો રસ્તો કાઢ્યો છે. અને મેં હાઇલોડ પર તેના વિશે વાત કરી. પ્રથમ, લાઇફસ્ટ્રીટ MySQL (ઓરેકલ પર ટૂંકા સ્ટોપ સાથે) થી વર્ટિકામાં ખસેડવામાં આવી. અને તમે તેના વિશે વાર્તા શોધી શકો છો.

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

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

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

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

અને કોમર્શિયલ ડેટાબેસેસમાં અને ઓપન સોર્સમાં હોય તે તમામ ફ્રીને ભેગા કરવા માટે કંઈ જ નહોતું.

ત્યાં સુધી કશું જ નહોતું, જ્યાં સુધી અણધારી રીતે, યાન્ડેક્ષે ક્લિકહાઉસને બહાર કાઢ્યું, ટોપીમાંથી જાદુગરની જેમ, સસલાની જેમ. અને તે એક અણધાર્યો નિર્ણય હતો, તેઓ હજી પણ પ્રશ્ન પૂછે છે: "શા માટે?", પરંતુ તેમ છતાં.

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

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

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

અને પરીક્ષણ પરિણામો પ્રાપ્ત કર્યા પછી, અને તેને વિવિધ ખૂણાઓથી જોતા, લાઇફસ્ટ્રીટ ક્લિકહાઉસ પર ગઈ.

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

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

પરિણામો છે:

• સફળ સ્થળાંતર અને એક વર્ષથી વધુ સમય સિસ્ટમ પહેલેથી જ ઉત્પાદનમાં કામ કરી રહી છે.
• ઉત્પાદકતા અને સુગમતા વધી છે. 10 બિલિયન રેકોર્ડ્સ કે જે અમે દરરોજ અને પછી થોડા સમય માટે સંગ્રહિત કરી શકીએ છીએ તેમાંથી, LifeStreet હવે દરરોજ 75 બિલિયન રેકોર્ડ્સ સ્ટોર કરે છે અને આ 3 મહિના કે તેથી વધુ સમય માટે કરી શકે છે. જો તમે ટોચ પર ગણતરી કરો છો, તો આ પ્રતિ સેકન્ડ એક મિલિયન ઇવેન્ટ્સ સુધી છે. આ સિસ્ટમમાં દરરોજ એક મિલિયનથી વધુ SQL ક્વેરીઝ આવે છે, મોટાભાગે વિવિધ રોબોટ્સમાંથી.
• વર્ટીકા કરતાં ક્લિકહાઉસ માટે વધુ સર્વર્સનો ઉપયોગ કરવામાં આવ્યો હોવા છતાં, તેઓ હાર્ડવેર પર પણ સાચવવામાં આવ્યા હતા, કારણ કે વર્ટિકામાં મોંઘી એસએએસ ડિસ્કનો ઉપયોગ થતો હતો. ક્લિકહાઉસ SATA નો ઉપયોગ કરે છે. અને શા માટે? કારણ કે વર્ટિકામાં ઇન્સર્ટ સિંક્રનસ છે. અને સિંક્રનાઇઝેશન માટે જરૂરી છે કે ડિસ્ક ખૂબ ધીમી ન થાય, અને એ પણ કે નેટવર્ક ખૂબ ધીમું ન થાય, એટલે કે, તેના બદલે ખર્ચાળ કામગીરી. અને ClickHouse માં ઇન્સર્ટ એસિંક્રોનસ છે. તદુપરાંત, તમે હંમેશા સ્થાનિક રીતે બધું જ લખી શકો છો, આ માટે કોઈ વધારાના ખર્ચ નથી, તેથી ધીમી ડ્રાઇવ પર પણ વર્ટિકામાં કરતાં ક્લિકહાઉસમાં ડેટા વધુ ઝડપથી દાખલ કરી શકાય છે. અને વાંચન લગભગ સમાન છે. SATA પર વાંચન, જો તેઓ RAID માં હોય, તો આ બધું પૂરતું ઝડપી છે.
• લાયસન્સ દ્વારા મર્યાદિત નથી, એટલે કે 3 સર્વર્સમાં 60 પેટાબાઇટ્સ ડેટા (20 સર્વર્સ એક પ્રતિકૃતિ છે) અને હકીકતો અને એકત્રીકરણમાં 6 ટ્રિલિયન રેકોર્ડ્સ. વર્ટિકામાં આવું કંઈ જ પરવડી શકે તેમ નથી.

હું હવે આ ઉદાહરણમાં વ્યવહારિક બાબતો તરફ વળું છું.

• પ્રથમ એક કાર્યક્ષમ યોજના છે. ઘણું બધું સ્કીમા પર આધાર રાખે છે.
• બીજું કાર્યક્ષમ SQL જનરેશન છે.

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

અને ઘણીવાર આ સ્ટાર-સ્કીમના સ્વરૂપમાં બનાવવામાં આવે છે, જ્યારે કિરણો સાથે બાજુઓ સાથે આ હકીકતની કેન્દ્રિય હકીકત અને લાક્ષણિકતાઓ હોય છે.

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

પરંતુ તે ClickHouse માં સારી રીતે કામ કરતું નથી. ત્યાં બે કારણો છે:

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

અને ક્લિકહાઉસમાં આમાંથી બહાર નીકળવાનો એક માર્ગ છે. બે પણ:

• પ્રથમ શબ્દકોશનો ઉપયોગ છે. એક્સટર્નલ ડિક્શનરીઝ એ સ્ટાર-સ્કીમા, અપડેટ્સ વગેરે સાથે 99% સમસ્યા ઉકેલવામાં મદદ કરે છે.
• બીજું એરેનો ઉપયોગ છે. એરે જોડા અને નોર્મલાઇઝેશનની સમસ્યાઓથી છુટકારો મેળવવામાં પણ મદદ કરે છે.

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

• તમારે જોડાવાની પણ જરૂર નથી.
• આ એક કોમ્પેક્ટ 1-થી-ઘણી રજૂઆત છે.
• અને મારા મતે, એરે ગીક્સ માટે બનાવવામાં આવે છે. આ લેમ્બડા ફંક્શન્સ છે અને તેથી વધુ.

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

લાક્ષણિક ઉદાહરણો કે જે એરે ઉકેલવામાં મદદ કરે છે. આ ઉદાહરણો સરળ અને પૂરતા સ્પષ્ટ છે:

• ટૅગ્સ દ્વારા શોધો. જો તમારી પાસે ત્યાં હેશટેગ છે અને હેશટેગ દ્વારા કેટલીક પોસ્ટ્સ શોધવા માંગો છો.
• કી-વેલ્યુ જોડી દ્વારા શોધો. મૂલ્ય સાથે કેટલીક વિશેષતાઓ પણ છે.
• કીની સૂચિ સંગ્રહિત કરવી કે જેને તમારે અન્ય કોઈ વસ્તુમાં અનુવાદિત કરવાની જરૂર છે.

આ તમામ કાર્યો એરે વિના ઉકેલી શકાય છે. ટૅગ્સ અમુક લાઇનમાં મૂકી શકાય છે અને નિયમિત અભિવ્યક્તિ સાથે અથવા અલગ કોષ્ટકમાં પસંદ કરી શકાય છે, પરંતુ પછી તમારે જોડાવું પડશે.

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

નેસ્ટેડ સ્ટ્રક્ચર શ્રેષ્ઠ નામ ન હોઈ શકે. આ બે એરે છે જે નામમાં સામાન્ય ભાગ અને કેટલીક સંબંધિત લાક્ષણિકતાઓ ધરાવે છે.

અને ટેગ દ્વારા શોધવું ખૂબ જ સરળ છે. એક કાર્ય છે has, જે ચકાસે છે કે એરેમાં એક તત્વ છે. દરેક વ્યક્તિને, અમારી કોન્ફરન્સથી સંબંધિત બધી એન્ટ્રીઓ મળી.

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

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

બીજું ઉદાહરણ. તમારી પાસે એક એરે છે જ્યાં તમે ID સ્ટોર કરો છો. અને તમે તેમને નામોમાં અનુવાદિત કરી શકો છો. કાર્ય arrayMap. આ એક લાક્ષણિક લેમ્બડા ફંક્શન છે. તમે ત્યાં લેમ્બડા અભિવ્યક્તિઓ પસાર કરો છો. અને તે શબ્દકોશમાંથી દરેક ID માટે નામની કિંમત બહાર કાઢે છે.

શોધ એ જ રીતે કરી શકાય છે. એક પ્રિડિકેટ ફંક્શન પસાર કરવામાં આવે છે જે તપાસે છે કે તત્વો શું મેળ ખાય છે.

આ વસ્તુઓ સર્કિટને મોટા પ્રમાણમાં સરળ બનાવે છે અને સમસ્યાઓનો સમૂહ ઉકેલે છે.

પરંતુ આગામી સમસ્યાનો આપણે સામનો કરી રહ્યા છીએ, અને જેનો હું ઉલ્લેખ કરવા માંગુ છું, તે કાર્યક્ષમ પ્રશ્નો છે.

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

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

અહીં એક ઉદાહરણ છે. ડાબી બાજુએ એક ક્વેરી છે જે ટોચના 5 દેશો દર્શાવે છે. અને તે મારા મતે 2,5 સેકન્ડ લે છે. અને જમણી બાજુએ, સમાન ક્વેરી, પરંતુ સહેજ ફરીથી લખાયેલ. શબ્દમાળા દ્વારા જૂથબદ્ધ કરવાને બદલે, અમે કી (int) દ્વારા જૂથ બનાવવાનું શરૂ કર્યું. અને તે ઝડપી છે. અને પછી અમે પરિણામ સાથે એક શબ્દકોશ જોડ્યો. 2,5 સેકન્ડને બદલે, વિનંતી 1,5 સેકન્ડ લે છે. આ સારું છે.

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

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

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

ત્યાં અન્ય તકનીકો છે, અને માત્ર તે જ નહીં જે મેં દર્શાવી છે. અને તે બધા કેટલીકવાર પ્રશ્નોના અમલીકરણને નોંધપાત્ર રીતે ઝડપી બનાવી શકે છે.

ચાલો આગળના ઉદાહરણ પર જઈએ. યુએસએથી કંપની એક્સ. તે શું કરી રહી છે?

ત્યાં એક કાર્ય હતું:

• જાહેરાત વ્યવહારોની ઑફલાઇન લિંકિંગ.
• વિવિધ બંધનકર્તા મોડેલોનું મોડેલિંગ.

દૃશ્ય શું છે?

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

વાજબી પ્રશ્નો: "જો જરૂરી હોય તો જાહેરાત માટે કોણે ચૂકવણી કરવી જોઈએ?" અને "કઈ જાહેરાતે તેને પ્રભાવિત કર્યો, જો કોઈ હોય તો?". એટલે કે, તેણે શા માટે ખરીદી કરી અને આ વ્યક્તિ જેવા લોકોને પણ કેવી રીતે ખરીદવી?

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

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

ત્યાં ઘણા બંધનકર્તા મોડેલો છે.

સૌથી વધુ લોકપ્રિય છે:

• છેલ્લી ક્રિયાપ્રતિક્રિયા, જ્યાં ક્રિયાપ્રતિક્રિયા એક ક્લિક અથવા છાપ છે.
• પ્રથમ ક્રિયાપ્રતિક્રિયા, એટલે કે પ્રથમ વસ્તુ જે વ્યક્તિને સાઇટ પર લાવે છે.
• રેખીય સંયોજન - બધા સમાન.
• એટેન્યુએશન.
• અને તેથી વધુ.

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

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

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

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

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

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

એટલે કે, એન્ટિપેટર્નનો સમૂહ.

પરંતુ તેમ છતાં તે એક સિસ્ટમ બનાવવા માટે બહાર આવ્યું જે ખૂબ જ સારી રીતે કામ કરે છે.

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

તે આ સ્વરૂપમાં હતું કે તે ખૂબ સારી રીતે કામ કરતું ન હતું. અને ક્લિકહાઉસ માટે તેને સરળ બનાવવા માટે, જ્યારે વિઝિટ આઈડી દ્વારા વિનંતી કરવામાં આવી હતી, ત્યારે તેઓએ આ વિનંતીઓને 1-000 વિઝિટ આઈડીના બ્લોકમાં જૂથબદ્ધ કરી હતી અને 2-000 લોકો માટે તમામ વ્યવહારો ખેંચી લીધા હતા. અને પછી તે બધું કામ કર્યું.

જો તમે ક્લિકહાઉસની અંદર જુઓ, તો ત્યાં ફક્ત 3 મુખ્ય કોષ્ટકો છે જે આ બધું આપે છે.

પ્રથમ કોષ્ટક જેમાં લોગ અપલોડ કરવામાં આવે છે અને લોગ લગભગ પ્રક્રિયા કર્યા વગર અપલોડ કરવામાં આવે છે.

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

અહીં SQL માં લખાયેલ ટેક્સ્ટ છે. હું તેમાં કેટલીક મહત્વપૂર્ણ બાબતો પર ટિપ્પણી કરવા માંગુ છું.

પ્રથમ મહત્વની વસ્તુ ક્લિકહાઉસમાં json માંથી કૉલમ અને ફીલ્ડ્સ ખેંચવાની ક્ષમતા છે. એટલે કે, ક્લિકહાઉસ પાસે json સાથે કામ કરવાની કેટલીક પદ્ધતિઓ છે. તેઓ ખૂબ, ખૂબ આદિમ છે.

visitParamExtractInt તમને json માંથી વિશેષતાઓ કાઢવા માટે પરવાનગી આપે છે, એટલે કે પ્રથમ હિટ કામ કરે છે. અને આ રીતે તમે ટ્રાન્ઝેક્શન આઈડી અથવા મુલાકાત આઈડી ખેંચી શકો છો. આ સમયે.

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

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

બીજી મહત્વની બાબત છે index_granularity. જો તમે MergeTree જોયું હોય, તો તે સામાન્ય રીતે 8 બાય ડિફોલ્ટ index_granularity છે. તે શુ છે? આ ઇન્ડેક્સ સ્પાર્સનેસ પેરામીટર છે. ક્લિકહાઉસમાં અનુક્રમણિકા છૂટીછવાઈ છે, તે દરેક એન્ટ્રીને ક્યારેય અનુક્રમિત કરતી નથી. તે દર 192 માં આ કરે છે. અને જ્યારે ઘણા બધા ડેટાની ગણતરી કરવી જરૂરી હોય ત્યારે આ સારું છે, પરંતુ જ્યારે થોડું ઓછું હોય ત્યારે ખરાબ છે, કારણ કે ત્યાં મોટી ઓવરહેડ છે. અને જો આપણે ઇન્ડેક્સ ગ્રેન્યુલારિટી ઘટાડીએ, તો આપણે ઓવરહેડ ઘટાડીએ છીએ. તે એકમાં ઘટાડી શકાતું નથી, કારણ કે ત્યાં પૂરતી મેમરી નથી. ઇન્ડેક્સ હંમેશા મેમરીમાં સંગ્રહિત થાય છે.

સ્નેપશોટ કેટલીક અન્ય રસપ્રદ ક્લિકહાઉસ સુવિધાઓનો પણ ઉપયોગ કરે છે.

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

• બંધનકર્તા રનટાઇમમાંથી "ડીકપલ્ડ" છે.
• દર મહિને 3 બિલિયન સુધીના વ્યવહારો સંગ્રહિત અને પ્રક્રિયા કરવામાં આવે છે. આ એક સામાન્ય ટ્રાન્ઝેક્શન સિસ્ટમમાં કેસાન્ડ્રા કરતાં વધુ તીવ્રતાનો ઓર્ડર છે.
• 2x5 ક્લિકહાઉસ સર્વર્સનું ક્લસ્ટર. 5 સર્વર અને દરેક સર્વરની પ્રતિકૃતિ છે. ક્લિક આધારિત એટ્રિબ્યુશન કરવા માટે આ કેસન્ડ્રા કરતાં પણ ઓછું છે, અને અહીં અમારી પાસે છાપ આધારિત છે. એટલે કે, સર્વરની સંખ્યામાં 30 ગણો વધારો કરવાને બદલે, તેઓ તેમને ઘટાડવામાં સફળ થયા.

અને છેલ્લું ઉદાહરણ નાણાકીય કંપની Y છે, જેણે શેરના ભાવમાં થતા ફેરફારોના સહસંબંધોનું વિશ્લેષણ કર્યું હતું.

અને કાર્ય હતું:

• અંદાજે 5 શેર છે.
• દર 100 મિલીસેકન્ડે અવતરણો જાણીતા છે.
• ડેટા 10 વર્ષથી એકઠા કરવામાં આવ્યો છે. દેખીતી રીતે, કેટલીક કંપનીઓ માટે વધુ, કેટલીક ઓછી.
• કુલ મળીને અંદાજે 100 અબજ પંક્તિઓ છે.

અને ફેરફારોના સહસંબંધની ગણતરી કરવી જરૂરી હતી.

અહીં બે સ્ટોક્સ અને તેમના ક્વોટ્સ છે. જો એક ઉપર જાય છે અને બીજો ઉપર જાય છે, તો આ એક સકારાત્મક સંબંધ છે, એટલે કે એક ઉપર જાય છે અને બીજો ઉપર જાય છે. જો એક ઉપર જાય છે, જેમ કે ગ્રાફના અંતે, અને બીજો નીચે જાય છે, તો આ નકારાત્મક સહસંબંધ છે, એટલે કે જ્યારે એક વધે છે, ત્યારે બીજો નીચે જાય છે.

આ પરસ્પર ફેરફારોનું વિશ્લેષણ કરીને, વ્યક્તિ નાણાકીય બજારમાં આગાહી કરી શકે છે.

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

અને તે પછી, તમારે સહસંબંધની ગણતરી કરવાની જરૂર છે, અને દરેક જોડી માટે સહસંબંધની ગણતરી કરવી આવશ્યક છે. 5 શેર માટે, જોડીઓ 000 મિલિયન છે. અને આ ઘણું છે, એટલે કે આવા સહસંબંધ કાર્યની ગણતરી કરવા માટે 12,5 વખત જરૂરી છે.

અને જો કોઈ ભૂલી ગયું હોય, તો ͞x અને ͞y એ ચેકમેટ છે. નમૂનાની અપેક્ષા. એટલે કે, માત્ર મૂળ અને સરવાળોની જ ગણતરી કરવી જરૂરી નથી, પણ આ રકમની અંદર એક વધુ સરવાળો પણ હોવો જરૂરી છે. ગણતરીઓનો સમૂહ 12,5 મિલિયન વખત કરવાની જરૂર છે, અને કલાકો દ્વારા જૂથબદ્ધ પણ. અમારી પાસે પણ ઘણા કલાકો છે. અને તમારે તે 60 સેકન્ડમાં કરવાનું છે. તે એક મજાક છે.

ઓછામાં ઓછું કોઈક રીતે સમય હોવો જરૂરી હતો, કારણ કે ક્લિકહાઉસ આવે તે પહેલાં આ બધું ખૂબ જ ધીમે ધીમે કામ કરતું હતું.

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

અને પછી ક્લિકહાઉસ આવ્યું અને વસ્તુઓ ઘણી સારી થઈ.

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

તેમણે શું કર્યું? શરૂઆતમાં, ડેટા સ્થાનિક છે. દરેક સર્વર શેરના ચોક્કસ સેટની કિંમત પર ડેટા સ્ટોર કરે છે. અને તેઓ ઓવરલેપ થતા નથી. તેથી, સમાંતર અને સ્વતંત્ર રીતે logReturn ની ગણતરી કરવી શક્ય છે, આ બધું અત્યાર સુધી સમાંતર અને વિતરિત રીતે થાય છે.

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

તે પછી, તે નકલ કરી શકાય છે. અક્ષર "r" નો અર્થ છે કે અમે આ ડેટાની નકલ કરી છે. એટલે કે, અમારી પાસે ત્રણેય સર્વર પર સમાન ડેટા છે - આ એરે છે.

અને પછી 12,5 મિલિયન સહસંબંધોના આ સમૂહમાંથી વિશિષ્ટ સ્ક્રિપ્ટ સાથે જેની ગણતરી કરવાની જરૂર છે, તમે પેકેજો બનાવી શકો છો. એટલે કે, 2 જોડી સહસંબંધો સાથે 500 કાર્યો. અને આ કાર્યની ગણતરી ચોક્કસ ક્લિકહાઉસ સર્વર પર કરવાની છે. તેની પાસે તમામ ડેટા છે, કારણ કે ડેટા સમાન છે અને તે ક્રમિક રીતે તેની ગણતરી કરી શકે છે.

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

ખ્યાલના પુરાવા પર, કાર્ય એક સબટાસ્ક હતું, એટલે કે, ઓછો ડેટા લેવામાં આવ્યો હતો. અને માત્ર ત્રણ સર્વર.

પ્રથમ બે તબક્કાઓ: લોગ_રીટર્નની ગણતરી કરવામાં અને એરેમાં વીંટાળવામાં લગભગ એક કલાકનો સમય લાગ્યો.

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

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

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

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

-રિપોર્ટ માટે આભાર! ખૂબ જ રસપ્રદ! શું અપાચે ફોનિક્સ સાથે કોઈ સરખામણી હતી?

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

• (એલેક્સી મિલોવિડોવ) અપાચે ફોનિક્સ એ Hbase દ્વારા સંચાલિત SQL એન્જિન છે. Hbase મુખ્યત્વે કી-વેલ્યુ વર્ક સિનારિયો માટે છે. ત્યાં, દરેક લાઇનમાં, મનસ્વી નામો સાથેની સ્તંભોની મનસ્વી સંખ્યા હોઈ શકે છે. આ Hbase, Cassandra જેવી સિસ્ટમો વિશે કહી શકાય. અને તે ચોક્કસપણે ભારે વિશ્લેષણાત્મક પ્રશ્નો છે જે તેમના માટે સામાન્ય રીતે કામ કરશે નહીં. અથવા તમે વિચારી શકો છો કે જો તમને ક્લિકહાઉસ સાથે કોઈ અનુભવ ન હોય તો તેઓ સારું કામ કરે છે.

• Спасибо

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

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

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

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

તે સ્પષ્ટ છે. તમે કહ્યું હતું કે 50 કલાકની પ્રક્રિયા કરવામાં આવી હતી. શું તે શરૂઆતથી જ છે, તમે ક્યારે ડેટા લોડ કર્યો અથવા પરિણામો મેળવ્યા?

હા હા.

તમારો ખુબ ખુબ આભાર.

આ 3 સર્વર ક્લસ્ટર પર છે.

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

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

નમસ્તે! તમે કહ્યું કે તમારે તરત જ ડેટા સ્કીમા પર વિચાર કરવાની જરૂર છે. એવું થયું તો? મારો ડેટા રેડી રહ્યો છે અને રેડી રહ્યો છે. છ મહિના પસાર થાય છે, અને હું સમજું છું કે આ રીતે જીવવું અશક્ય છે, મારે ડેટા ફરીથી અપલોડ કરવાની અને તેમની સાથે કંઈક કરવાની જરૂર છે.

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

Спасибо.

સોર્સ: www.habr.com