ક્લિકહાઉસમાં ખસેડવું: 3 વર્ષ પછી

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

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

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

પૂર્વદર્શન: 3 વર્ષ પહેલાં શું થયું હતું

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

• જૂન 2016. માં ખુલ્લા સ્ત્રોત દેખાયા ક્લીકહાઉસ અને અમારો પ્રોજેક્ટ શરૂ થયો;
• ઓગસ્ટ. ખ્યાલનો પુરાવો: વિશાળ જાહેરાત નેટવર્ક, ઈન્ફ્રાસ્ટ્રક્ચર અને 200-300 ટેરાબાઈટ ડેટા;
• ઓક્ટોબર. પ્રથમ ઉત્પાદન ડેટા;
• ડિસેમ્બર. સંપૂર્ણ ઉત્પાદન લોડ દરરોજ 10-50 બિલિયન ઇવેન્ટ્સ છે.
• જૂન 2017. વપરાશકર્તાઓનું સફળ સ્થળાંતર ક્લીકહાઉસ, 2,5 સર્વર્સના ક્લસ્ટર પર 60 પેટાબાઇટ્સ ડેટા.

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

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

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

શા માટે ખસેડો ક્લીકહાઉસ

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

લાંબા સમયથી લોકો સાથે કામ કરતા લોકોના રેન્ડમ અવતરણો ક્લીકહાઉસ.

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

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

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

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

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

ક્લિકહાઉસમાં ખસેડવું

પર જાઓ ક્લીકહાઉસ કેટલાક કારણોસર, તમારે ફક્ત ત્રણ વસ્તુઓની જરૂર છે:

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

ખસેડવાની સમસ્યા

ત્યાં ફક્ત એક જ છે “પરંતુ”: જો તમે ખસેડો ક્લીકહાઉસ કંઈક બીજું, પછી સામાન્ય રીતે કંઈક ખોટું થાય છે. અમે કેટલીક પ્રથાઓ અને વસ્તુઓથી ટેવાયેલા છીએ જે અમારા મનપસંદ ડેટાબેઝમાં કામ કરે છે. ઉદાહરણ તરીકે, કોઈપણ સાથે કામ કરે છે SQL-ડેટાબેઝ નીચેના કાર્યોના સમૂહને ફરજિયાત માને છે:

• વ્યવહારો;
• અવરોધો;
• સુસંગતતા;
• સૂચકાંકો;
• અપડેટ/ડિલીટ કરો;
• NULLs;
• મિલિસેકન્ડ્સ;
• સ્વચાલિત પ્રકારના કાસ્ટ્સ;
• બહુવિધ જોડાઓ;
• મનસ્વી પાર્ટીશનો;
• ક્લસ્ટર મેનેજમેન્ટ સાધનો.

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

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

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

હાઉસ સ્ક્રિપ્ટ્સ પર ક્લિક કરો

1960 માં, હંગેરિયન મૂળના અમેરિકન ગણિતશાસ્ત્રી વિગ્નર ઇપી એક લેખ લખ્યો "પ્રાકૃતિક વિજ્ઞાનમાં ગણિતની ગેરવાજબી અસરકારકતા” (“કુદરતી વિજ્ઞાનમાં ગણિતની અગમ્ય અસરકારકતા”) કે આપણી આસપાસની દુનિયા કેટલાક કારણોસર ગાણિતિક કાયદાઓ દ્વારા સારી રીતે વર્ણવેલ છે. ગણિત એ અમૂર્ત વિજ્ઞાન છે, અને ગાણિતિક સ્વરૂપમાં દર્શાવવામાં આવતા ભૌતિક કાયદાઓ તુચ્છ નથી, અને વિગ્નર ઇપી ભારપૂર્વક જણાવ્યું હતું કે આ ખૂબ જ વિચિત્ર છે.

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

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

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

В સમય શ્રેણી સામાન્ય રીતે સાંકડી કોષ્ટકનો ઉપયોગ થાય છે - ઘણા નાના કૉલમ. મોનિટરિંગમાંથી ઘણો ડેટા આવી શકે છે - સેકન્ડ દીઠ લાખો રેકોર્ડ્સ - અને તે સામાન્ય રીતે નાના વિસ્ફોટોમાં આવે છે (વાસ્તવિક સમય સ્ટ્રીમિંગ). તેથી, એક અલગ નિવેશ સ્ક્રિપ્ટની જરૂર છે, અને પ્રશ્નોની પોતાની વિશિષ્ટતાઓ છે.

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

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

સમય શ્રેણી

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

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

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

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

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

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

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

પર્કોના બિલ્ટ ઇન ક્લીકહાઉસ તમારી અંદર પીએમએમવિવિધ મોનીટરીંગ સંગ્રહ કરવા માટે MySQL.

ચોક્કસ જરૂરિયાતો

સમય-શ્રેણી ડેટાબેઝની પોતાની ચોક્કસ જરૂરિયાતો હોય છે.

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

ચાલો જોઈએ કે આ જરૂરિયાતો કેવી રીતે પૂરી થાય છે ક્લીકહાઉસ.

આ યોજના

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

નિયમિત ડેટા. કૉલમ. યોજના સરળ છે - જરૂરી પ્રકારો સાથે કૉલમ:

CREATE TABLE cpu (
  created_date Date DEFAULT today(),  
  created_at DateTime DEFAULT now(),  
  time String,  
  tags_id UInt32,  /* join to dim_tag */
  usage_user Float64,  
  usage_system Float64,  
  usage_idle Float64,  
  usage_nice Float64,  
  usage_iowait Float64,  
  usage_irq Float64,  
  usage_softirq Float64,  
  usage_steal Float64,  
  usage_guest Float64,  
  usage_guest_nice Float64
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

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

અનિયમિત ડેટા. અરે:

CREATE TABLE cpu_alc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metrics Nested(
    name LowCardinality(String),  
    value Float64
  )
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

SELECT max(metrics.value[indexOf(metrics.name,'usage_user')]) FROM ...

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

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

SELECT max(metrics.value[indexOf(metrics.name,'usage_user')]) FROM ...

પરંતુ તે હજુ પણ ખૂબ ઝડપથી કામ કરે છે. અનિયમિત ડેટા સ્ટોર કરવાની બીજી રીત પંક્તિ દ્વારા છે.

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

CREATE TABLE cpu_rlc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metric_name LowCardinality(String),  
  metric_value Float64
) ENGINE = MergeTree(created_date, (metric_name, tags_id, created_at), 8192);


SELECT 
    maxIf(metric_value, metric_name = 'usage_user'),
    ... 
FROM cpu_r
WHERE metric_name IN ('usage_user', ...)

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

ચાલો ત્રણ અભિગમોની તુલના કરીએ:

Детали

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

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

આ અભિગમનો ઉપયોગ કરતી કંપનીઓમાંની એકમાં (ઉદાહરણ તરીકે, ઉબેર), એરે 128 તત્વોના ટુકડાઓમાં કાપવામાં આવે છે. 200 TB ડેટા/દિવસના વોલ્યુમ સાથે કેટલાક હજાર મેટ્રિક્સનો ડેટા એક એરેમાં નહીં, પરંતુ વિશિષ્ટ સ્ટોરેજ લોજિક સાથે 10 અથવા 30 એરેમાં સંગ્રહિત થાય છે.

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

હાઇબ્રિડ યોજના

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

CREATE TABLE cpu_alc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metrics Nested(
    name LowCardinality(String),  
    value Float64
  ),
  usage_user Float64 
             MATERIALIZED metrics.value[indexOf(metrics.name,'usage_user')],
  usage_system Float64 
             MATERIALIZED metrics.value[indexOf(metrics.name,'usage_system')]
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

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

કોડેક્સ અને કમ્પ્રેશન

માટે સમય શ્રેણી તમે ડેટાને કેટલી સારી રીતે પેક કરો છો તે મહત્વનું છે કારણ કે માહિતીની માત્રા ઘણી મોટી હોઈ શકે છે. IN ક્લીકહાઉસ 1:10, 1:20 અને ક્યારેક વધુની સંકોચન અસર પ્રાપ્ત કરવા માટે સાધનોનો સમૂહ છે. આનો અર્થ છે કે ડિસ્ક પર 1 TB અનપેક્ડ ડેટા 50-100 GB લે છે. નાની સાઇઝ સારી છે, ડેટાને ઝડપથી વાંચી અને પ્રોસેસ કરી શકાય છે.

કમ્પ્રેશનનું ઉચ્ચ સ્તર પ્રાપ્ત કરવા માટે, ક્લીકહાઉસ નીચેના કોડેકને સપોર્ટ કરે છે:

ઉદાહરણ કોષ્ટક:

CREATE TABLE benchmark.cpu_codecs_lz4 (
    created_date Date DEFAULT today(), 
    created_at DateTime DEFAULT now() Codec(DoubleDelta, LZ4), 
    tags_id UInt32, 
    usage_user Float64 Codec(Gorilla, LZ4), 
    usage_system Float64 Codec(Gorilla, LZ4), 
    usage_idle Float64 Codec(Gorilla, LZ4), 
    usage_nice Float64 Codec(Gorilla, LZ4), 
    usage_iowait Float64 Codec(Gorilla, LZ4), 
    usage_irq Float64 Codec(Gorilla, LZ4), 
    usage_softirq Float64 Codec(Gorilla, LZ4), 
    usage_steal Float64 Codec(Gorilla, LZ4), 
    usage_guest Float64 Codec(Gorilla, LZ4), 
    usage_guest_nice Float64 Codec(Gorilla, LZ4), 
    additional_tags String DEFAULT ''
)
ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

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

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

• ડિસ્ક પર GZIP ફાઇલમાં;
• કોડેક્સ વિના ક્લિકહાઉસમાં, પરંતુ ZSTD કમ્પ્રેશન સાથે;
• કોડેક્સ અને કમ્પ્રેશન LZ4 અને ZSTD સાથે ક્લિકહાઉસમાં.

તે જોઈ શકાય છે કે કોડેક્સવાળા કોષ્ટકો ઘણી ઓછી જગ્યા લે છે.

કદ બાબતો

ઓછું મહત્વનું નથી પસંદ કરવા માટે સાચો ડેટા પ્રકાર:

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

જો તમે ઉપયોગ કરી શકો છો int32 вместо int64, પછી પ્રદર્શનમાં લગભગ બમણા વધારાની અપેક્ષા રાખો. ડેટા ઓછી મેમરી લે છે, અને તમામ "અંકગણિત" ખૂબ ઝડપથી કામ કરે છે. ક્લીકહાઉસ આંતરિક રીતે તે ખૂબ જ કડક રીતે ટાઇપ કરેલી સિસ્ટમ છે; તે આધુનિક સિસ્ટમો પ્રદાન કરે છે તે તમામ શક્યતાઓનો મહત્તમ ઉપયોગ કરે છે.

એકત્રીકરણ અને ભૌતિક દ્રષ્ટિકોણ

એકત્રીકરણ અને ભૌતિક દૃશ્યો તમને વિવિધ પ્રસંગો માટે એકત્રીકરણ બનાવવાની મંજૂરી આપે છે:

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

ટીટીએલ - જૂના ડેટાને "ભૂલી જાઓ".

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

CREATE TABLE aggr_by_minute
…
TTL time + interval 1 day

CREATE TABLE aggr_by_day
…
TTL time + interval 30 day

CREATE TABLE aggr_by_week
…
/* no TTL */

બહુ-સ્તરીય - ડિસ્ક પર ડેટાને વિભાજીત કરો

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

તમે સ્ટોરેજ પોલિસી ગોઠવી શકો છો (સંગ્રહ નીતિ) તેથી ક્લીકહાઉસ ચોક્કસ શરતો પર પહોંચ્યા પછી આપમેળે અન્ય સ્ટોરેજમાં ડેટા ટ્રાન્સફર કરશે.

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

CREATE TABLE 
... 
TTL date + INTERVAL 7 DAY TO VOLUME 'cold_volume', 
    date + INTERVAL 180 DAY DELETE

અનન્ય લક્ષણો ક્લીકહાઉસ

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

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

મુશ્કેલ પ્રશ્નો

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

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

SELECT *
  FROM cpu 
 WHERE (tags_id, created_at) IN 
    (SELECT tags_id, max(created_at)
        FROM cpu 
        GROUP BY tags_id)

બીજી પદ્ધતિ એ જ વસ્તુ કરે છે પરંતુ એકંદર કાર્યનો ઉપયોગ કરે છે argMax:

SELECT 
    argMax(usage_user), created_at),
    argMax(usage_system), created_at),
...
 FROM cpu 

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

SELECT now() as created_at,
       cpu.*
  FROM (SELECT DISTINCT tags_id from cpu) base 
  ASOF LEFT JOIN cpu USING (tags_id, created_at)

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

વિશ્લેષણાત્મક કાર્યો

ધોરણમાં SQL-2003 તમે આના જેવું લખી શકો છો:

SELECT origin,
       timestamp,
       timestamp -LAG(timestamp, 1) OVER (PARTITION BY origin ORDER BY timestamp) AS duration,
       timestamp -MIN(timestamp) OVER (PARTITION BY origin ORDER BY timestamp) AS startseq_duration,
       ROW_NUMBER() OVER (PARTITION BY origin ORDER BY timestamp) AS sequence,
       COUNT() OVER (PARTITION BY origin ORDER BY timestamp) AS nb
  FROM mytable
ORDER BY origin, timestamp;

В ક્લીકહાઉસ તમે તે કરી શકતા નથી - તે ધોરણને સમર્થન આપતું નથી SQL-2003 અને કદાચ તે ક્યારેય કરશે નહીં. તેના બદલે, માં ક્લીકહાઉસ આના જેવું લખવાનો રિવાજ છે:

મેં લેમ્બદાસને વચન આપ્યું હતું - તેઓ અહીં છે!

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

ખાસ કાર્યો

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

સામાન્ય રીતે, ક્લિકહાઉસ ઘણા હેતુઓ માટે વિશિષ્ટ કાર્યો ધરાવે છે:

• રનિંગ ડિફરન્સ, રનિંગ એક્યુમ્યુલેટ, પાડોશી;
• sumMap(કી, મૂલ્ય);
• timeSeriesGroupSum(uid, ટાઇમસ્ટેમ્પ, મૂલ્ય);
• timeSeriesGroupRateSum(uid, ટાઇમસ્ટેમ્પ, મૂલ્ય);
• skewPop, skewSamp, kurtPop, kurtSamp;
• ભરણ સાથે / ટાઈ સાથે;
• સરળ લીનિયર રીગ્રેશન, સ્ટોકેસ્ટીક લીનિયર રીગ્રેશન.

આ કાર્યોની સંપૂર્ણ સૂચિ નથી, કુલ 500-600 છે. સંકેત: માં તમામ કાર્યો ક્લીકહાઉસ સિસ્ટમ કોષ્ટકમાં છે (બધા દસ્તાવેજીકૃત નથી, પરંતુ બધા રસપ્રદ છે):

select * from system.functions order by name

ક્લીકહાઉસ તે પોતાના વિશે ઘણી બધી માહિતી સંગ્રહિત કરે છે, સહિત લોગ કોષ્ટકો, query_log, ટ્રેસ લોગ, ડેટા બ્લોક્સ સાથેની કામગીરીનો લોગ (ભાગ_લોગ), મેટ્રિક્સ લોગ અને સિસ્ટમ લોગ, જે તે સામાન્ય રીતે ડિસ્ક પર લખે છે. લોગ મેટ્રિક્સ છે સમય શ્રેણી в ક્લીકહાઉસ હકિકતમાં ક્લીકહાઉસ: ડેટાબેઝ પોતે જ ભૂમિકા ભજવી શકે છે સમય શ્રેણી ડેટાબેસેસ, આમ પોતે "ભક્ષી" કરે છે.

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

મોટા ક્લસ્ટર અથવા ઘણા નાના ક્લીકહાઉસ

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

В ક્લીકહાઉસ તમે તેને અલગ રીતે કરી શકો છો. તમે દરેક એપ્લિકેશનને તમારી પોતાની બનાવી શકો છો ક્લીકહાઉસ:

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

પરંતુ જો આપણી પાસે ઘણું છે ક્લીકહાઉસ, અને તમારે તેને વારંવાર ઇન્સ્ટોલ કરવાની જરૂર છે, પછી તમે આ પ્રક્રિયાને સ્વચાલિત કરવા માંગો છો. આ માટે આપણે, ઉદાહરણ તરીકે, ઉપયોગ કરી શકીએ છીએ ક્યુબર્નેટિસ и ક્લિકહાઉસ-ઓપરેટર. IN કુબરનેટ્સ ક્લિકહાઉસ તમે તેને “ઓન-ક્લિક” મૂકી શકો છો: હું એક બટન ક્લિક કરી શકું છું, મેનિફેસ્ટ ચલાવી શકું છું અને ડેટાબેઝ તૈયાર છે. હું તરત જ ડાયાગ્રામ બનાવી શકું છું, ત્યાં મેટ્રિક્સ અપલોડ કરવાનું શરૂ કરી શકું છું અને 5 મિનિટમાં મારી પાસે ડેશબોર્ડ તૈયાર છે ગ્રાફના. તે ખૂબ સરળ છે!

અંતે શું?

અને તેથી, ક્લીકહાઉસ - આ:

• Строыстро. દરેક વ્યક્તિ આ જાણે છે.
• જસ્ટ. થોડો વિવાદાસ્પદ, પરંતુ હું માનું છું કે તે તાલીમમાં મુશ્કેલ છે, લડાઇમાં સરળ છે. જો તમે સમજો છો કે કેવી રીતે ક્લીકહાઉસ તે કામ કરે છે, પછી બધું ખૂબ સરળ છે.
• સાર્વત્રિક. તે વિવિધ પરિસ્થિતિઓ માટે યોગ્ય છે: DWH, સમય શ્રેણી, લોગ સંગ્રહ. પરંતુ તે નથી ઓએલટીપી ડેટાબેઝ, તેથી ત્યાં ટૂંકા દાખલ અને વાંચન કરવાનો પ્રયાસ કરશો નહીં.
• રસપ્રદ છે. કદાચ જેની સાથે કામ કરે છે ક્લીકહાઉસ, સારા અને ખરાબ અર્થમાં ઘણી રસપ્રદ ક્ષણોનો અનુભવ કર્યો. ઉદાહરણ તરીકે, એક નવું પ્રકાશન બહાર આવ્યું, બધું કામ કરવાનું બંધ કરી દીધું. અથવા જ્યારે તમે બે દિવસ સુધી કોઈ કાર્ય સાથે સંઘર્ષ કર્યો, પરંતુ ટેલિગ્રામ ચેટમાં પ્રશ્ન પૂછ્યા પછી, કાર્ય બે મિનિટમાં ઉકેલાઈ ગયું. અથવા લેશા મિલોવિડોવના અહેવાલ પરની કોન્ફરન્સમાં ગમે છે, જેનો સ્ક્રીનશોટ ક્લીકહાઉસ પ્રસારણ તોડ્યું હાઇલોડ++. આ પ્રકારની વસ્તુ હંમેશા થાય છે અને આપણું જીવન મુશ્કેલ બનાવે છે. ક્લીકહાઉસ તેજસ્વી અને રસપ્રદ!

તમે પ્રસ્તુતિ જોઈ શકો છો અહીં.

ખાતે હાઇ-લોડ સિસ્ટમ્સના વિકાસકર્તાઓની લાંબા સમયથી રાહ જોવાતી મીટિંગ હાઇલોડ++ સ્કોલ્કોવોમાં 9 અને 10 નવેમ્બરના રોજ યોજાશે. છેવટે, આ એક ઑફલાઇન કોન્ફરન્સ હશે (તમામ સાવચેતીઓ હોવા છતાં), કારણ કે HighLoad++ ની ઊર્જા ઓનલાઈન પેક કરી શકાતી નથી.

કોન્ફરન્સ માટે, અમે તમને ટેક્નોલોજીની મહત્તમ ક્ષમતાઓ વિશેના કિસ્સાઓ શોધી અને બતાવીએ છીએ: HighLoad++ એ એકમાત્ર એવી જગ્યા હતી જ્યાં તમે Facebook, Yandex, VKontakte, Google અને Amazon કેવી રીતે કામ કરે છે તે બે દિવસમાં શીખી શકશો.

2007 થી કોઈપણ વિક્ષેપ વિના અમારી મીટિંગ્સ યોજીને, આ વર્ષે અમે 14મી વખત મળીશું. આ સમય દરમિયાન, કોન્ફરન્સમાં 10 ગણો વધારો થયો છે; ગયા વર્ષે, મુખ્ય ઉદ્યોગ ઇવેન્ટમાં 3339 સહભાગીઓ, 165 સ્પીકર્સ, રિપોર્ટ્સ અને મીટઅપ્સ અને 16 ટ્રેક એકસાથે ચાલી રહ્યા હતા.
ગયા વર્ષે 20 બસો, 5280 લિટર ચા-કોફી, 1650 લિટર ફ્રૂટ ડ્રિન્ક અને 10200 પાણીની બોટલો હતી. અને અન્ય 2640 કિલોગ્રામ ખોરાક, 16 પ્લેટો અને 000 કપ. માર્ગ દ્વારા, રિસાયકલ કરેલા કાગળમાંથી એકત્ર કરેલા નાણાં સાથે, અમે 25 ઓક રોપાઓ વાવ્યા :)

તમે ટિકિટ ખરીદી શકો છો અહીં, કોન્ફરન્સ વિશે સમાચાર મેળવો - અહીં, અને તમામ સામાજિક નેટવર્ક્સ પર વાત કરો: Telegram, ફેસબુક, Vkontakte и Twitter.

સોર્સ: www.habr.com