ક્લિકહાઉસનો અસરકારક ઉપયોગ. એલેક્સી મિલોવિડોવ (યાન્ડેક્ષ)

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

કેમ છો બધા! મારું નામ એલેક્સી છે, હું ક્લિકહાઉસ બનાવું છું.

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

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

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

તો, રેક્સ શું છે? મૂળભૂત રીતે હું સ્પષ્ટ વસ્તુઓ વિશે વાત કરીશ. દરેક વસ્તુ દરેક માટે સ્પષ્ટ છે, દરેક જણ બધું સમજે છે અને ખુશ થઈ શકે છે કે તેઓ ઘણા સ્માર્ટ છે, અને જેઓ સમજી શકતા નથી તેઓ કંઈક નવું શીખશે.

પ્રથમ સરળ ઉદાહરણ, જે, કમનસીબે, ઘણીવાર થાય છે, નાની બેચેસ સાથે મોટી સંખ્યામાં ઇન્સર્ટ્સ છે, એટલે કે મોટી સંખ્યામાં નાના ઇન્સર્ટ્સ.

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

અને ચાલો જોઈએ કે લાક્ષણિક પ્રદર્શન શું હશે. ઉદાહરણ તરીકે, અમારી પાસે Yandex.Metrics ડેટા સાથેનું ટેબલ છે. હિટ. 105 કેટલીક કૉલમ. 700 બાઇટ્સ બિનસંકુચિત. અને અમે સારી રીતે એક મિલિયન લાઇનની બેચ દાખલ કરીશું.

અમે MergeTree કોષ્ટકમાં દાખલ કરીએ છીએ, પ્રતિ સેકન્ડ અડધા મિલિયન પંક્તિઓ મેળવવામાં આવે છે. મહાન. નકલ કરેલ કોષ્ટકમાં - તે થોડું ઓછું હશે, લગભગ 400 પંક્તિઓ પ્રતિ સેકન્ડ.

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

* 2020 મુજબ, પહેલેથી જ દસ્તાવેજીકૃત.

જો તમે ખોટું કરો તો શું થશે? અમે MergeTree કોષ્ટકમાં એક પંક્તિ દાખલ કરીએ છીએ અને અમને પ્રતિ સેકન્ડ 59 પંક્તિઓ મળે છે. આ 10 ગણી ધીમી છે. ReplicatedMergeTree માં - 000 પંક્તિઓ પ્રતિ સેકન્ડ. અને જો કોરમ ચાલુ થાય, તો પ્રતિ સેકન્ડમાં 6 લીટીઓ મળે છે. મારા મતે, આ એકદમ વાહિયાત પ્રકાર છે. તમે આવી રીતે કેવી રીતે ધીમું કરી શકો? તે મારા ટી-શર્ટ પર પણ લખે છે કે ક્લિકહાઉસ ધીમું ન થવું જોઈએ. પરંતુ તેમ છતાં તે ક્યારેક થાય છે.

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

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

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

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

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

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

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

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

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

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

જો કે, આ કિસ્સામાં, ડેટા તરત જ ક્લિકહાઉસને મોકલવામાં આવશે. અને ક્લિકહાઉસ પોતે જ તેમને બફર કરશે.

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

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

*2020 મુજબ, પણ વિચારણામાં ઉમેરવું જોઈએ બિલાડીનું બચ્ચું હાઉસ.

પદ્ધતિ 6. બીજી રીત બફર કોષ્ટકોનો ઉપયોગ કરવાનો છે. આ પદ્ધતિનો ફાયદો એ છે કે તેનો ઉપયોગ શરૂ કરવો ખૂબ જ સરળ છે. બફર ટેબલ બનાવો અને તેમાં દાખલ કરો.

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

અને બફર કોષ્ટકોમાં પણ લોગ નથી. અને જો તમારા સર્વરમાં કંઈક ખોટું છે, તો ડેટા ખોવાઈ જશે.

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

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

* 2020 સુધી, માટે સમાન સમર્થન છે રેબિટમ્યુક્યુ.

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

* આ ક્ષણે, સમસ્યા સંપૂર્ણપણે હલ થઈ ગઈ છે, VALUES માં અભિવ્યક્તિઓનો ઉપયોગ કરતી વખતે કોઈ વધુ પ્રદર્શન રીગ્રેસન નથી.

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

* તાજેતરમાં ક્લિકહાઉસમાં પ્રાયોગિક મોડમાં રાઈટ-હેડ લોગ સાથે RAM માં હિસ્સા અને હિસ્સાના કોમ્પેક્ટ ફોર્મેટ માટે સમર્થન ઉમેર્યું છે, જે સમસ્યાને લગભગ સંપૂર્ણપણે હલ કરે છે.

હવે બીજા પ્રકારની સમસ્યાનો વિચાર કરો - ડેટા ટાઇપિંગ.

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

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

ઉદાહરણ તરીકે, અમારી પાસે IP સરનામું છે. એક કિસ્સામાં, અમે તેને શબ્દમાળા તરીકે સાચવ્યું. ઉદાહરણ તરીકે, 192.168.1.1. નહિંતર, તે સંખ્યાબંધ પ્રકાર UInt32* હશે. IPv32 સરનામા માટે 4 બિટ્સ પર્યાપ્ત છે.

પ્રથમ, વિચિત્ર રીતે, ડેટા સમાન વિશે સંકુચિત કરવામાં આવશે. ચોક્કસ તફાવત હશે, પણ એટલો મોટો નહીં. તેથી ડિસ્ક I/O સાથે કોઈ ખાસ સમસ્યા નથી.

પરંતુ CPU સમય અને ક્વેરી એક્ઝેક્યુશન સમયમાં ગંભીર તફાવત છે.

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

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

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

ચાલો વિવિધ કેસો ધ્યાનમાં લઈએ.

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

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

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

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

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

* ClickHouse ના તાજેતરના સંસ્કરણોમાં, ALTER સંપૂર્ણપણે બિન-અવરોધિત છે.

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

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

અહીં એક ઉદાહરણ છે. ત્યાં Yandex.Direct છે. અને ત્યાં એક જાહેરાત કંપની અને બેનરો છે. ત્યાં કદાચ લાખો જાહેરાત કંપનીઓ છે. અને લગભગ RAM માં ફિટ. અને અબજો બેનરો છે, તે ફિટ થતા નથી. અને અમે MySQL માંથી કેશ્ડ ડિક્શનરીનો ઉપયોગ કરી રહ્યા છીએ.

એકમાત્ર સમસ્યા એ છે કે જો હિટ રેટ 100% ની નજીક હોય તો કેશ્ડ ડિક્શનરી સારું કામ કરશે. જો તે નાનું હોય, તો દરેક ડેટા પેક માટેની વિનંતીઓ પર પ્રક્રિયા કરતી વખતે, ખરેખર ખૂટતી કી લેવી અને MySQL માંથી ડેટા લેવા જવું જરૂરી રહેશે. ક્લિકહાઉસ વિશે, હું હજી પણ ખાતરી આપી શકું છું કે - હા, તે ધીમું થતું નથી, હું અન્ય સિસ્ટમો વિશે વાત કરીશ નહીં.

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

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

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

અને આવી રીતે જાહેરાત કંપનીઓના નામ હેશ કરવા તે બહુ સારું નહીં હોય. જો વિવિધ કંપનીઓની જાહેરાત ઝુંબેશ ભળી જશે, તો કંઈક અગમ્ય હશે.

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

બોનસ તરીકે, ઘણા ઓપરેશન્સ માટે, ફક્ત હેશ જ પૂરતા છે અને સ્ટ્રિંગ્સ પોતે ક્યાંય સંગ્રહિત કરી શકાતી નથી.

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

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

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

અને જો ડેટા સ્થાને સંગ્રહિત હોય, તો તે ફાઇલ સિસ્ટમમાંથી યોગ્ય ક્રમમાં વાંચવામાં આવે છે અને બધું બરાબર છે.

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

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

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

અને એક કિસ્સામાં, અમે ફક્ત url મેળવીશું અને ડોમેનની ગણતરી કરીશું. તે 166 મિલિસેકન્ડ્સ બહાર વળે છે. અને જો તમે તૈયાર ડોમેન લો છો, તો તે ફક્ત 67 મિલિસેકન્ડ્સ જ બહાર આવે છે, એટલે કે, લગભગ ત્રણ ગણું ઝડપી. અને ઝડપી, એટલા માટે નહીં કે આપણે અમુક ગણતરીઓ કરવાની જરૂર છે, પરંતુ એટલા માટે કે આપણે ઓછો ડેટા વાંચીએ છીએ.

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

અને જો તમે ડિસ્ક પરના ડેટાની માત્રા જુઓ છો, તો તે તારણ આપે છે કે URL 126 મેગાબાઇટ્સ છે, અને ડોમેન ફક્ત 5 મેગાબાઇટ્સ છે. તે 25 ગણું ઓછું બહાર વળે છે. જો કે, ક્વેરી હજુ પણ માત્ર 4 ગણી ઝડપી છે. પરંતુ તે એટલા માટે છે કારણ કે ડેટા ગરમ છે. અને જો તે ઠંડું હતું, તો તે ડિસ્ક I / O ને કારણે કદાચ 25 ગણું ઝડપી હશે.

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

અને, અલબત્ત, તે યોગ્ય ડેટા પ્રકારોનો ઉપયોગ કરવા યોગ્ય છે જે ખાસ કરીને યોગ્ય મૂલ્યો અથવા તે ફિટ માટે રચાયેલ છે. જો તમે IPv4 માં હોવ તો UInt32* સ્ટોર કરો. જો IPv6, તો FixedString(16), કારણ કે IPv6 સરનામું 128 બિટ્સ છે, એટલે કે સીધા બાઈનરી ફોર્મેટમાં સ્ટોર કરો.

પરંતુ જો તમારી પાસે ક્યારેક IPv4 અને ક્યારેક IPv6 હોય તો? હા, તમે બંને રાખી શકો છો. એક કૉલમ IPv4 માટે, બીજી IPv6 માટે. અલબત્ત, IPv4 થી IPv6 ને મેપ કરવાનો વિકલ્પ છે. આ પણ કામ કરશે, પરંતુ જો તમને વારંવાર તમારી વિનંતીઓમાં IPv4 સરનામાંની જરૂર હોય, તો તેને અલગ કૉલમમાં મૂકવું સરસ રહેશે.

* ક્લિકહાઉસમાં હવે અલગ IPv4, IPv6 ડેટા પ્રકારો છે જે ડેટાને સંખ્યાઓ જેટલા કાર્યક્ષમ રીતે સંગ્રહિત કરે છે, પરંતુ તેને સ્ટ્રિંગ્સની જેમ અનુકૂળ રીતે રજૂ કરે છે.

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

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

તેથી આ કિસ્સામાં 4 કૉલમમાં વિભાજિત કરવું વધુ યોગ્ય રહેશે. અહીં ડરશો નહીં, કારણ કે આ ક્લિકહાઉસ છે. ક્લિકહાઉસ એ કૉલમ ડેટાબેઝ છે. અને વધુ સુઘડ નાની કૉલમ, વધુ સારી. 5 બ્રાઉઝર વર્ઝન હશે, 5 કોલમ બનાવો. આ સારું છે.

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

ઉદાહરણ તરીકે, અમારી એક એનાલિટિક્સ સેવામાં કેટલાક ઇવેન્ટ પરિમાણો છે. અને જો ઘટનાઓમાં ઘણા બધા પરિમાણો આવે છે, તો અમે ફક્ત પ્રથમ 512 ને સાચવીએ છીએ જે સામે આવે છે. કારણ કે 512 એ દયા નથી.

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

* હવે ક્લિકહાઉસ પાસે ડેટા પ્રકાર છે લો કાર્ડિનલિટી જે તમને ઓછા પ્રયત્નો સાથે કાર્યક્ષમ રીતે સ્ટ્રીંગ્સ સ્ટોર કરવા દે છે.

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

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

સૈદ્ધાંતિક રીતે, હું અન્ય લોકોના અનુભવનો આદર કરું છું, જેમાં આ અનુભવ કેવા પ્રકારની વેદના મેળવી શકાય છે તે સમજવાનો સમાવેશ થાય છે.

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

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

અથવા, ઉદાહરણ તરીકે, માઇક્રોશાર્ડિંગ, પરંતુ તેના પર પછીથી વધુ.

ક્લિકહાઉસમાં, તમારે આ કરવાની જરૂર નથી, કારણ કે, પ્રથમ, પ્રાથમિક કી ક્લસ્ટર થયેલ છે, ડેટા પ્રાથમિક કી દ્વારા ઓર્ડર કરવામાં આવે છે.

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

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

જો કોલમ ઉમેરો/છોડો બદલો તો ક્લિકહાઉસમાં અલ્ટર મફત છે.

અને તમારે નાના કોષ્ટકો બનાવવા જોઈએ નહીં, કારણ કે જો તમારી પાસે તમારા ટેબલમાં 10 પંક્તિઓ અથવા 10 પંક્તિઓ છે, તો તે કોઈ વાંધો નથી. ક્લિકહાઉસ એ એક એવી સિસ્ટમ છે જે થ્રુપુટને ઑપ્ટિમાઇઝ કરે છે, વિલંબિતતાને નહીં, તેથી 000 રેખાઓ પર પ્રક્રિયા કરવાનો કોઈ અર્થ નથી.

એક મોટા ટેબલનો ઉપયોગ કરવો યોગ્ય છે. જૂની સ્ટીરિયોટાઇપ્સથી છૂટકારો મેળવો, બધું સારું થઈ જશે.

અને બોનસ તરીકે, નવીનતમ સંસ્કરણમાં, વ્યક્તિગત પાર્ટીશનો પર તમામ પ્રકારની જાળવણી કામગીરી કરવા માટે અમારી પાસે મનસ્વી પાર્ટીશન કી બનાવવાની તક છે.

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

* હવે ક્લિકહાઉસમાં વધુ છે ટેબલ ફંક્શન ઇનપુટ.

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

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

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

અને બીજું કારણ એ છે કે તમારી પાસે TCP પર ઇન્ટરપ્રોસેસર કમ્યુનિકેશન હશે. ડેટાને સીરીયલાઇઝ્ડ, ડીસીરિયલાઇઝ કરવું પડશે અને આ મોટી સંખ્યામાં માઇક્રોશાર્ડ્સ છે. તે માત્ર કામ કરશે નહિં.

અન્ય એન્ટિપેટર્ન, જોકે તેને ભાગ્યે જ એન્ટિપેટર્ન કહી શકાય. આ પ્રી-એગ્રિગેશનનો મોટો જથ્થો છે.

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

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

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

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

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

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

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

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

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

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

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

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

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

* પહેલેથી જ વાપરી રહ્યા છીએ; વચન મુજબ બધું ઠીક કરવામાં આવ્યું હતું.

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

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

અને ક્લિકહાઉસમાં એક વિશિષ્ટ સુવિધા છે - આ ક્વોટાની ગણતરી છે. વધુમાં, તમે તમારી ક્વોટા કી ટ્રાન્સફર કરી શકો છો. આ, ઉદાહરણ તરીકે, આંતરિક વપરાશકર્તા ID છે. અને તેમાંના દરેક માટે ક્વોટાની ગણતરી સ્વતંત્ર રીતે કરવામાં આવશે.

હવે બીજી રસપ્રદ વાત. આ મેન્યુઅલ પ્રતિકૃતિ છે.

હું એવા ઘણા કિસ્સાઓ જાણું છું કે જ્યાં ક્લિકહાઉસમાં બિલ્ટ-ઇન રેપ્લિકેશન સપોર્ટ હોવા છતાં, લોકો ક્લિકહાઉસ મેન્યુઅલી નકલ કરે છે.

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

અને સમયાંતરે તમારે હજી પણ મેન્યુઅલી સિંક કરવું પડશે. ઉદાહરણ તરીકે, મહિનામાં એકવાર એડમિન rsync કરે છે.

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

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

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

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

અને સર્વરના નવા સંસ્કરણમાં, તમે સ્પષ્ટ પણ કરી શકો છો કે તમારી પાસે પાર્ટીશન કી વગર કસ્ટમ પાર્ટીશન છે. તે જ હશે.

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

અથવા મધ્યવર્તી પ્રક્રિયા માટે નાના વોલ્યુમો સંગ્રહિત કરવું એ StripeLog અથવા TinyLog છે.

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

ક્લિકહાઉસને પુનઃનોર્મલાઇઝ્ડ ડેટા બહુ ગમતો નથી.

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

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

* અને હવે ક્લિકહાઉસમાં મર્જ જોઇન પણ છે, અને તે એવી પરિસ્થિતિઓમાં કામ કરે છે જ્યાં મધ્યવર્તી ડેટા RAM માં બંધબેસતો નથી. પરંતુ આ બિનઅસરકારક છે અને ભલામણ માન્ય રહે છે.

થોડા વધુ ઉદાહરણો, પરંતુ મને પહેલેથી જ શંકા છે કે તે પેટર્ન વિરોધી છે કે નહીં.

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

* બેચ મોડમાં અપડેટ અને ડિલીટ માટે સપોર્ટ લાંબા સમયથી ઉમેરવામાં આવ્યો છે.

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

ક્લિકહાઉસમાં વિતરિત જોડાઓ - આ પણ ક્વેરી પ્લાનર દ્વારા ખરાબ રીતે નિયંત્રિત થાય છે.

ખરાબ, પરંતુ ક્યારેક ઠીક.

સિલેક્ટ* સાથે ડેટા બેક રીડ કરવા માટે ક્લિકહાઉસનો ઉપયોગ કરો.

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

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

પ્રશ્નો

રિપોર્ટ માટે આભાર! ક્લિકહાઉસ ક્રેશ વિશે ક્યાં ફરિયાદ કરવી?

તમે હમણાં મને વ્યક્તિગત રૂપે ફરિયાદ કરી શકો છો.

મેં તાજેતરમાં ક્લિકહાઉસનો ઉપયોગ કરવાનું શરૂ કર્યું. તરત જ cli ઈન્ટરફેસ છોડી દીધું.

શું સ્કોર.

થોડી વાર પછી, મેં એક નાની પસંદગી સાથે સર્વર છોડી દીધું.

તમારી પાસે પ્રતિભા છે.

મેં GitHub બગ ખોલ્યો, પરંતુ તેને અવગણવામાં આવ્યો.

અમે જોશો.

એલેક્સીએ મને રિપોર્ટમાં હાજરી આપવા માટે છેતર્યું, મને કહેવાનું વચન આપ્યું કે તમે કેવી રીતે ડેટાને અંદરથી સ્ક્વિઝ કરી રહ્યાં છો.

ખૂબ સરળ.

આ વાત મને ગઈ કાલે સમજાઈ. વધુ સ્પષ્ટીકરણો.

ત્યાં કોઈ ભયંકર યુક્તિઓ નથી. તે માત્ર બ્લોક-બાય-બ્લોક કમ્પ્રેશન છે. ડિફોલ્ટ LZ4 છે, તમે ZSTD* સક્ષમ કરી શકો છો. 64 કિલોબાઈટથી 1 મેગાબાઈટ સુધીના બ્લોક્સ.

* વિશિષ્ટ કમ્પ્રેશન કોડેક્સ માટે પણ સપોર્ટ છે જેનો ઉપયોગ અન્ય અલ્ગોરિધમ્સ સાથે સાંકળમાં થઈ શકે છે.

શું બ્લોક્સ માત્ર કાચો ડેટા છે?

બરાબર કાચું નથી. ત્યાં એરે છે. જો તમારી પાસે સંખ્યાત્મક કૉલમ હોય, તો પછી એક પંક્તિમાંની સંખ્યાઓ એરેમાં સ્ટેક કરવામાં આવે છે.

તે સ્પષ્ટ છે.

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

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

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

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

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

એટલે કે આંશિક રીબૂટ?

હા હા. ત્યાં MySQL ફીલ્ડ સેટ કરવાની ક્ષમતાની જેમ, એટલે કે પછી અપડેટ કરો જેથી ડિક્શનરી ખૂબ મોટી હોય તો જ આ ડેટા લોડ થાય.

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

મને નથી લાગતું.

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

હા, પરંતુ કમનસીબે C++ માં નથી.

શું તમારા સાથીદારો C++ માં લખી શકે છે?

હું કોઈને શોધી લઈશ.

મહાન*.

* રિપોર્ટના બે મહિના પછી સુવિધા ઉમેરવામાં આવી હતી - તે પ્રશ્નના લેખક દ્વારા વિકસાવવામાં આવી હતી અને તેના દ્વારા સબમિટ કરવામાં આવી હતી વિનંતી ખેંચો.

આભાર!

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

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

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

પ્રથમ, લોગ સામાન્ય રીતે લાંબી લાઇન નથી હોતા. ત્યાં, અલબત્ત, અપવાદો છે. ઉદાહરણ તરીકે, java માં લખેલી કેટલીક સેવા અપવાદ દર્શાવે છે, તે લોગ થયેલ છે. અને તેથી અનંત લૂપમાં, અને હાર્ડ ડ્રાઇવની જગ્યા સમાપ્ત થઈ રહી છે. ઉકેલ ખૂબ જ સરળ છે. જો રેખાઓ ખૂબ લાંબી હોય, તો પછી તેને કાપી નાખો. લાંબા અર્થ શું છે? દસ કિલોબાઈટ ખરાબ છે *.

* ClickHouse ના તાજેતરના સંસ્કરણોમાં, "અનુકૂલનશીલ અનુક્રમણિકા ગ્રેન્યુલારિટી" સક્ષમ છે, જે મોટા ભાગના ભાગ માટે લાંબા તાર સંગ્રહવાની સમસ્યાને દૂર કરે છે.

શું એક કિલોબાઈટ સામાન્ય છે?

તે સામાન્ય છે

નમસ્તે! રિપોર્ટ માટે આભાર! મેં ચેટમાં આ વિશે પહેલેથી જ પૂછ્યું છે, પરંતુ મને યાદ નથી કે મને જવાબ મળ્યો કે નહીં. શું CTE ફેશનમાં WITH વિભાગને વિસ્તારવાની કોઈ યોજના છે?

હજી નહિં. WITH વિભાગ કંઈક અંશે વ્યર્થ છે. તે અમારા માટે એક નાનકડી સુવિધા જેવું છે.

હુ સમજયો. આભાર!

રિપોર્ટ માટે આભાર! ખૂબ જ રસપ્રદ! વૈશ્વિક પ્રશ્ન. શું તે કરવાનું આયોજન છે, કદાચ અમુક પ્રકારના સ્ટબના સ્વરૂપમાં, ડેટા કાઢી નાખવામાં ફેરફાર?

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

* કીબોર્ડ પરના બટનો દબાવ્યા અને બધું થઈ ગયું.

શું તે કોઈક રીતે સિસ્ટમની કામગીરીને અસર કરશે કે નહીં? શું ઇન્સર્ટ હવે જેટલું ઝડપી હશે?

કદાચ કાઢી નાખે છે, અપડેટ્સ પોતે જ ભારે હશે, પરંતુ આ પસંદગીના પ્રદર્શન અને ઇન્સર્ટ્સના પ્રદર્શનને કોઈપણ રીતે અસર કરશે નહીં.

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

હા.

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

હા.

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

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

સોર્સ: www.habr.com