પ્રશ્નો અને જવાબોમાં અદ્યતન વપરાશકર્તાઓ માટે હાઉસ પર ક્લિક કરો

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

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

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

અનુક્રમણિકા

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

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

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

ક્લિકહાઉસ સતત અપડેટ કરવામાં આવે છે, અને અમારો ડેટા, જે અંતિમ પ્રક્રિયા માટે ઑપ્ટિમાઇઝ કરવામાં આવ્યો હતો, તે અપડેટ થતો નથી અને તે બેકઅપ કોપીમાં છે.

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

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

ક્લિકહાઉસમાંથી ડેટાનો બેકઅપ લેવા માટેની વર્તમાન શ્રેષ્ઠ પદ્ધતિઓ શું છે?

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

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

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

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

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

જો ડેટા સાથેનું ટેબલ માત્ર થોડા ગીગાબાઇટ્સ ધરાવે છે, તો બેકઅપ આ રીતે કરી શકાય છે:

1. ટેબલ વ્યાખ્યા સાચવો એટલે કે મેટાડેટા − બનાવો ટેબલ બતાવો.
2. ક્લિકહાઉસ ક્લાયંટનો ઉપયોગ કરીને ડમ્પ બનાવો - પસંદ * ટેબલ પરથી ફાઈલ કરવા માટે. મૂળભૂત રીતે તમને TabSeparated ફોર્મેટમાં ફાઇલ પ્રાપ્ત થશે. જો તમે વધુ કાર્યક્ષમ બનવા માંગતા હો, તો તમે મૂળ ફોર્મેટનો ઉપયોગ કરી શકો છો.

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

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

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

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

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

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

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

શું શાફ્ટમાં પ્રતિકૃતિઓનો નિયંત્રિત લેગ ગોઠવવાનું શક્ય બનશે?

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

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

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

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

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

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

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

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

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

આ જ પરિવર્તનો જેવા કે પરિવર્તનોને લાગુ પડે છે. જ્યારે તમે કરો છો કાઢી નાખો અથવા અપડેટ બદલો, તે ભાગને બદલતું નથી, પરંતુ એક નવું બનાવે છે. અને પછી જૂનાને કાઢી નાખે છે.

જો ટેબલનું માળખું બદલાઈ ગયું હોય તો શું?

જૂની સ્કીમ સાથે બનેલા બેકઅપને કેવી રીતે રિસ્ટોર કરવું? અને બીજો પ્રશ્ન સ્નેપશોટ અને ફાઇલ સિસ્ટમ ટૂલ્સ સાથેના કેસ વિશે છે. શું Linux LVM પર ZFS ને બદલે Btrfs અહીં સારું છે?

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

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

ડેટા રીશાર્ડિંગમાં વર્તમાન શ્રેષ્ઠ પ્રયાસો શું છે?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

વ્લાદિમીર કોલોબેવ: હકીકત એ છે કે આપણે ઘણી વાર ઐતિહાસિક ડેટાને અપીલ કરીએ છીએ, કારણ કે આપણે વર્તમાન પરિસ્થિતિની વાસ્તવિક સમયની ઐતિહાસિક સાથે સરખામણી કરીએ છીએ. અને અમારા માટે મોટી માત્રામાં ડેટાની ઝડપી ઍક્સેસ મેળવવી મહત્વપૂર્ણ છે, અને ClickHouse આ સાથે ઉત્તમ કામ કરે છે.

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

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

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

Yandex.Metrica ઇવેન્ટ્સ સાથેનું મુખ્ય ક્લસ્ટર છે. ઇવેન્ટ્સ એ પૃષ્ઠ દૃશ્યો, ક્લિક્સ અને રૂપાંતરણો છે. મોટાભાગની વિનંતીઓ ચોક્કસ વેબસાઇટ પર જાય છે. તમે Yandex.Metrica સેવા ખોલો છો, તમારી પાસે એક વેબસાઇટ છે - avito.ru, રિપોર્ટ પર જાઓ, અને તમારી વેબસાઇટ માટે વિનંતી કરવામાં આવે છે.

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

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

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

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

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

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

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

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

નવી યોજનામાં, બધી સાઇટ્સને બે શ્રેણીઓમાં વહેંચવામાં આવી છે - મોટી અને નાની. મને ખબર નથી કે થ્રેશોલ્ડ કેવી રીતે પસંદ કરવામાં આવ્યું હતું, પરંતુ પરિણામ એ આવ્યું કે મોટી સાઇટ્સ એક ક્લસ્ટર પર રેકોર્ડ કરવામાં આવી છે, જ્યાં દરેકમાં ત્રણ પ્રતિકૃતિઓ સાથે 120 શાર્ડ્સ છે - એટલે કે, 360 સર્વર્સ. અને શાર્ડિંગ સ્કીમ એવી છે કે કોઈપણ વિનંતી એક જ સમયે તમામ શાર્ડ પર જાય છે. જો તમે હવે Yandex.Metrica માં avito.ru માટે કોઈપણ અહેવાલ પૃષ્ઠ ખોલો છો, તો વિનંતી 120 સર્વર્સ પર જશે. RuNet માં થોડી મોટી સાઇટ્સ છે. અને વિનંતીઓ એક હજાર પ્રતિ સેકન્ડ નથી, પરંતુ સો કરતાં પણ ઓછી છે. આ બધું શાંતિથી વિતરિત ટેબલ દ્વારા ચાવવામાં આવે છે, જેમાંથી દરેક 120 સર્વર સાથે પ્રક્રિયા કરે છે.

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

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

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

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

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

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

તમારી પાસે રીશાર્ડિંગ નામની પાઇલટ વસ્તુ હતી. તેની સાથે શું?

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

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

શું તે ધીમી ડિસ્ક પર ખસેડતા પહેલા ડેટાના તમામ ટુકડાઓને એકસાથે મર્જ કરવું શક્ય છે?

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

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

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

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

જો અગાઉથી સુસંગતતા તપાસવાની કોઈ રીત ન હોય તો ક્લિકહાઉસના નવા સંસ્કરણો પર કેવી રીતે સ્થાનાંતરિત કરવું?

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

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

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

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

વર્ઝન 20.3.4 છે. 20 નંબર ઉત્પાદનનું વર્ષ સૂચવે છે - 2020. અંદર શું છે તેના દૃષ્ટિકોણથી, આ કોઈ વાંધો નથી, તેથી અમે તેના પર ધ્યાન આપીશું નહીં. આગળ - 20.3. અમે બીજી સંખ્યા વધારીએ છીએ - આ કિસ્સામાં 3 - દર વખતે જ્યારે આપણે કેટલીક નવી કાર્યક્ષમતા સાથે રિલીઝ રિલીઝ કરીએ છીએ. જો આપણે ક્લિકહાઉસમાં કેટલીક વિશેષતા ઉમેરવા માંગીએ છીએ, તો આપણે આ સંખ્યા વધારવી પડશે. એટલે કે, સંસ્કરણ 20.4 માં ક્લિકહાઉસ વધુ સારું કામ કરશે. ત્રીજો અંક 20.3.4 છે. અહીં 4 એ પેચ રીલીઝની સંખ્યા છે જેમાં અમે નવા ફીચર્સ ઉમેર્યા નથી, પરંતુ કેટલીક ભૂલો સુધારી છે. અને 4 એટલે કે આપણે તે ચાર વખત કર્યું.

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

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

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

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

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

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

એલેક્સી મિલોવિડોવ: હું તમને કહીશ કે Yandex.Metrica ના અમારા મિત્રોનું પરીક્ષણ વાતાવરણ કેવું છે. એક ક્લસ્ટરમાં 600-વિચિત્ર સર્વર્સ હતા, બીજામાં 360 હતા, અને ત્રીજા અને કેટલાક ક્લસ્ટરો છે. તેમાંથી એક માટે પરીક્ષણ વાતાવરણ બે પ્રતિકૃતિઓ સાથે ફક્ત બે શાર્ડ્સ છે. શા માટે બે કટકા? જેથી તમે એકલા ન હોવ. અને પ્રતિકૃતિઓ પણ હોવી જોઈએ. માત્ર એક ચોક્કસ ન્યૂનતમ રકમ જે તમે પરવડી શકો.

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

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

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

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

કિલ ક્વેરી ક્વેરીઝને મારી નાખે તેવું માનવામાં આવે છે, પરંતુ તે થતું નથી. શા માટે?

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

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

હવે એક વિચિત્ર જવાબ હશે. મુદ્દો એ છે કે કિલ ક્વેરી ક્વેરી મારતી નથી.

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

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

રીડિંગ લોડ હેઠળ પ્રતિભાવ સમયની ગણતરી કેવી રીતે કરવી?

ત્યાં એક ટેબલ છે જે આઇટમ એગ્રીગેટ્સ સ્ટોર કરે છે - વિવિધ કાઉન્ટર્સ. લાઈનોની સંખ્યા લગભગ એકસો મિલિયન છે. જો તમે 1K આઇટમ્સ માટે 1K RPS રેડો તો શું અનુમાનિત પ્રતિભાવ સમય પર ગણતરી કરવી શક્ય છે?

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

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

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

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

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

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

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

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

હું ક્લિકહાઉસમાં શું ટ્વિક કરી શકું જેથી વધુ ડેટા કેશમાં હોય?

ચાલો એક પરિસ્થિતિની કલ્પના કરીએ - સર્વર પાસે 256 GB RAM છે, દૈનિક દિનચર્યામાં ક્લિકહાઉસ લગભગ 60-80 GB લે છે, ટોચ પર - 130 સુધી. શું સક્ષમ અને ટ્વિક કરી શકાય છે જેથી વધુ ડેટા કેશમાં હોય અને તે મુજબ, ડિસ્ક પર ઓછા પ્રવાસો છે?

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

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

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

હું RAM માં સ્ટોરેજ માટે સ્ટોરેજ_કોન્ફિગરેશન કેવી રીતે ગોઠવી શકું?

નવા ક્લિકહાઉસ દસ્તાવેજીકરણમાં મેં સંબંધિત વિભાગ વાંચ્યો ડેટા સ્ટોરેજ સાથે. વર્ણનમાં ઝડપી SSD સાથેનું ઉદાહરણ છે.

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

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

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

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

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

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

લો કાર્ડિનલિટી કેટલા અનન્ય મૂલ્યો સુધી અસરકારક છે?

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

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

પાંચ અબજ પંક્તિઓ સાથે કોષ્ટકને સંપૂર્ણ-ટેક્સ્ટ શોધવા માટેની શ્રેષ્ઠ પદ્ધતિઓ શું છે?

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

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

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

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

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

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

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

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

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

મોટી સંખ્યામાં વપરાશકર્તાઓ માટે ક્લિકહાઉસની ઍક્સેસ ગોઠવવાની શ્રેષ્ઠ રીત કઈ છે?

અમને કહો કે મોટી સંખ્યામાં ગ્રાહકો અને વિશ્લેષકો માટે ઍક્સેસને કેવી રીતે શ્રેષ્ઠ રીતે ગોઠવવું. કતાર કેવી રીતે બનાવવી, મહત્તમ સહવર્તી પ્રશ્નોને પ્રાથમિકતા આપવી અને કયા સાધનો સાથે?

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

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

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

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

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

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

આગલી પ્રાથમિકતા સેટિંગ કહેવામાં આવે છે OS થ્રેડ અગ્રતા. તે ફક્ત Linux શેડ્યૂલર માટે તમામ વિનંતી અમલ થ્રેડો માટે સરસ મૂલ્ય સેટ કરે છે. તે આમ-તેમ કામ કરે છે, પરંતુ તે હજુ પણ કામ કરે છે. જો તમે ન્યૂનતમ સરસ મૂલ્ય સેટ કરો છો - તે મૂલ્યમાં સૌથી મોટું છે, અને તેથી સૌથી નીચી પ્રાધાન્યતા - અને ઉચ્ચ અગ્રતાવાળી વિનંતીઓ માટે -19 સેટ કરો છો, તો CPU ઉચ્ચ-અગ્રતાવાળી વિનંતીઓ કરતાં લગભગ ચાર ગણી ઓછી-પ્રાધાન્યતા વિનંતીઓનો વપરાશ કરશે.

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

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

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

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

શું એક ક્વેરીનું પરિણામ દસ ક્લાયન્ટને આપવું શક્ય છે?

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

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

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

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

ત્યાં એક વૈકલ્પિક ઉકેલ છે જે ક્લિકહાઉસની બાજુમાં સાઇડકાર તરીકે મૂકવામાં આવે છે - હાઉસ પ્રોક્સી પર ક્લિક કરો.

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

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

અસુમેળ કામગીરી અને ભૌતિક દૃશ્યો વિશે શું?

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

એક સ્પષ્ટ ઉકેલ છે - અસુમેળ પતન કામગીરી દરમિયાન ચોક્કસ વર્ગના મેટવ્યુઝ પર ટ્રિગરનો અમલ કરવો. શું કોઈ સિલ્વર બુલેટ્સ અથવા સમાન કાર્યક્ષમતાને અમલમાં મૂકવાની યોજના છે?

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

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

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

અને તે પણ મહત્વનું છે કે તે ભૌતિક દૃષ્ટિકોણ માટે કેવી રીતે કાર્ય કરે છે. જો મુખ્ય કોષ્ટકમાં દાખલ કરવામાં આવે ત્યારે ડેટાનું ડુપ્લિકેટ કરવામાં આવ્યું હતું, તો તે ભૌતિક દૃશ્યમાં પણ જશે નહીં.

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

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

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

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

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

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

ક્લિકહાઉસમાં ઘણા બધા લોગ છે. સર્વર સાથે જે થાય છે તે બધું હું એક નજરમાં કેવી રીતે જોઈ શકું?

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

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

ત્યાં ડેશબોર્ડ્સ છે, જો કે તે પ્રમાણિત નથી. અમારી કંપનીમાં, લગભગ 60 ટીમો ક્લિકહાઉસનો ઉપયોગ કરે છે, અને સૌથી વિચિત્ર બાબત એ છે કે તેમાંના ઘણા ડેશબોર્ડ્સ ધરાવે છે જે તેઓએ પોતાના માટે બનાવ્યા છે, અને થોડા અલગ છે. કેટલીક ટીમો આંતરિક Yandex.Cloud ઇન્સ્ટોલેશનનો ઉપયોગ કરે છે. કેટલાક તૈયાર અહેવાલો છે, જો કે તમામ જરૂરી નથી. બીજા પાસે પોતાના છે.

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

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

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

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

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

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

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

મર્જને કેવી રીતે પ્રભાવિત કરવું જેથી સર્વર OOM માં ક્રેશ ન થાય?

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

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

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

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

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

વ્લાદિમીર કોલોબેવ: દંડ. અહીં ક્ષણ એવી છે કે બગ ફિક્સ થયા પછી, મેં મારા માટે એક નવું સંસ્કરણ ડાઉનલોડ કર્યું, અને બીજા ટેબલ પર, એક નાનું, જ્યાં ઘણા બધા પાર્ટીશનો છે, મેં સમાન ઓપરેશન કર્યું. અને મર્જ દરમિયાન, સર્વર પર લગભગ 100 GB RAM બળી ગઈ હતી. મારી પાસે 150 રોકાયેલ, 100 ખાધા અને 50 GB વિન્ડો બાકી હતી, તેથી હું OOM માં ન પડ્યો.

જો તે ખરેખર 100 GB RAM વાપરે તો OOM માં પડવાથી મને હાલમાં શું રક્ષણ આપે છે? જો અચાનક મર્જ પરની RAM સમાપ્ત થઈ જાય તો શું કરવું?

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

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

ક્લિકહાઉસ માટે ગોલાંગ ડ્રાઈવર કેવી રીતે વિકસિત થશે?

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

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

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

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

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

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

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

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

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

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

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

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

lazy_load સેટિંગ સક્ષમ સાથે રીબૂટ કર્યા પછી બાહ્ય શબ્દકોશ લોડ થતો નથી. શુ કરવુ?

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

કદાચ અમારી પાસે ક્લિકહાઉસનું જૂનું સંસ્કરણ છે, તેથી શબ્દકોશ આપમેળે લોડ થયો નથી. આ કેસ હોઈ શકે છે?

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

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

છેલ્લા પ્રશ્નનો જવાબ કાં તો સંસ્કરણ જૂનું છે અથવા તેને ડીબગ કરવાની જરૂર છે.

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

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

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

શું ક્લિકહાઉસ રૂપરેખામાં વિગતોને ગોઠવવાની કોઈ રીત છે, પરંતુ ભૂલોના કિસ્સામાં તેને પ્રદર્શિત ન કરવી?

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

અમે ODBC ડ્રાઇવર રૂપરેખામાં વિગતો ઉમેરીને આ ભૂલને ઉકેલી છે. ક્લિકહાઉસ રૂપરેખામાં વિગતોને ગોઠવવાની કોઈ રીત છે, પરંતુ ભૂલોના કિસ્સામાં આ વિગતો દર્શાવતી નથી?

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

બોનસ: મેળાવડામાંથી ઝૂમ માટે બેકગ્રાઉન્ડ

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

સોર્સ: www.habr.com