HighLoad++, Yuri Nasretdinov (VKontakte): VK કેવી રીતે હજારો સર્વર્સમાંથી ક્લિકહાઉસમાં ડેટા દાખલ કરે છે

હાઇલોડ++ મોસ્કો 2018, કોંગ્રેસ હોલ. નવેમ્બર 9, 15:00

અમૂર્ત અને પ્રસ્તુતિ: http://www.highload.ru/moscow/2018/abstracts/4066

યુરી નસરેટડિનોવ (વીકોન્ટાક્ટે): રિપોર્ટ અમારી કંપનીમાં ક્લિકહાઉસના અમલીકરણના અનુભવ વિશે વાત કરશે - અમને તેની શા માટે જરૂર છે, અમે કેટલો ડેટા સ્ટોર કરીએ છીએ, અમે તેને કેવી રીતે લખીએ છીએ, વગેરે.

વધારાની સામગ્રી: ELK, Big Query અને TimescaleDB ના રિપ્લેસમેન્ટ તરીકે ક્લિકહાઉસનો ઉપયોગ

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

લોગ શું છે અને શા માટે તેને એકત્રિત કરો?

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

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

અમે શા માટે નક્કી કર્યું? અમારી પાસે કદાચ લૉગ્સ સ્ટોર કરવા માટેના ઉકેલો હતા. અહીં - આવી જાહેર "બેકએન્ડ વીકે" છે. હું તેને સબ્સ્ક્રાઇબ કરવાની ખૂબ ભલામણ કરું છું.

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

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

ક્લિકહાઉસ અને સ્પર્ધકો: જરૂરિયાતો અને તકો

આપણે શું જોઈએ છે? અમે ખાતરી કરવા માંગીએ છીએ કે અમારે ઑપરેશન વિશે વધુ ચિંતા કરવાની જરૂર નથી, જેથી તે બૉક્સની બહાર કામ કરે, પ્રાધાન્યમાં ન્યૂનતમ ગોઠવણી સાથે. અમારે ઘણું લખવું છે, અને ઝડપથી લખવું છે. અને અમે તેને તમામ પ્રકારના મહિનાઓ, વર્ષો, એટલે કે લાંબા સમય સુધી રાખવા માંગીએ છીએ. અમે કેટલીક સમસ્યા સમજવા માંગીએ છીએ જે તેઓ અમારી પાસે આવ્યા હતા અને કહ્યું હતું કે, "અહીં કંઈક કામ કરતું નથી," અને તે 3 મહિના પહેલા હતું), અને અમે 3 મહિના પહેલા શું થયું તે જોવા માટે સમર્થ થવા માંગીએ છીએ " ડેટા કમ્પ્રેશન - તે સ્પષ્ટ છે કે તે શા માટે વત્તા હશે - કારણ કે તે જે જગ્યા લે છે તે ઘટાડે છે.

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

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

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

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

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

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

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

અમે તેને કેવી રીતે દાખલ કરવા જઈ રહ્યા છીએ? મર્જટ્રી

તમારામાંથી કોણે "ક્લિકહાઉસ" વિશે સાંભળ્યું નથી અથવા જાણ્યું નથી? મારે તમને કહેવાની જરૂર છે, નહીં? ખૂબ જ ઝડપી. ત્યાં નિવેશ - 1-2 ગીગાબાઈટ પ્રતિ સેકન્ડ, 10 ગીગાબીટ પ્રતિ સેકન્ડ સુધીનો વિસ્ફોટ ખરેખર આ રૂપરેખાંકનનો સામનો કરી શકે છે - ત્યાં બે 6-કોર Xeons (એટલે ​​કે સૌથી શક્તિશાળી પણ નથી), 256 ગીગાબાઈટ રેમ, 20 ટેરાબાઈટ છે RAID માં (કોઈએ ગોઠવેલ નથી, ડિફોલ્ટ સેટિંગ્સ). એલેક્સી મિલોવિડોવ, ક્લિકહાઉસ ડેવલપર, સંભવતઃ ત્યાં રડતા બેઠા છે કારણ કે અમે કંઈપણ ગોઠવ્યું નથી (બધું અમારા માટે તે પ્રમાણે કામ કરે છે). તદનુસાર, જો ડેટાને સારી રીતે સંકુચિત કરવામાં આવે તો સેકન્ડ દીઠ લગભગ 6 બિલિયન લાઇનની સ્કેનિંગ ઝડપ મેળવી શકાય છે. જો તમે ટેક્સ્ટ સ્ટ્રિંગ પર % પસંદ કરો છો - 100 મિલિયન લાઇન પ્રતિ સેકન્ડ, એટલે કે, તે ખૂબ ઝડપી લાગે છે.

અમે તેને કેવી રીતે દાખલ કરવા જઈ રહ્યા છીએ? સારું, તમે જાણો છો કે VK PHP નો ઉપયોગ કરે છે. અમે દરેક PHP કાર્યકર પાસેથી HTTP મારફતે “ClickHouse” માં, દરેક રેકોર્ડ માટે MergeTree ટેબલમાં દાખલ કરીશું. આ યોજનામાં સમસ્યા કોણ જુએ છે? કેટલાક કારણોસર, દરેક વ્યક્તિએ તેમના હાથ ઉભા કર્યા નથી. ચાલો હું તમને કહું.

પ્રથમ, ત્યાં ઘણા બધા સર્વર્સ છે - તે મુજબ, ઘણા બધા જોડાણો (ખરાબ) હશે. પછી MergeTree માં સેકન્ડ દીઠ એક કરતા વધુ વાર ડેટા દાખલ કરવો વધુ સારું છે. અને કોણ જાણે કેમ? ઠીક ઠીક. હું તમને આ વિશે થોડી વધુ કહીશ. બીજો રસપ્રદ પ્રશ્ન એ છે કે અમે એનાલિટિક્સ નથી કરી રહ્યા, અમારે ડેટાને સમૃદ્ધ બનાવવાની જરૂર નથી, અમને મધ્યવર્તી સર્વરની જરૂર નથી, અમે સીધું જ “ClickHouse” માં દાખલ કરવા માગીએ છીએ (પ્રાધાન્ય - વધુ સીધું, વધુ સારું).

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

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

અહીં કલ્પના કરો કે લગભગ એક હજાર સર્વર છે જેના પર અમે લોન્ચ કર્યું છે, ત્યાં માત્ર PHP છે. અને દરેક સર્વર પર અમારો સ્થાનિક એજન્ટ છે, જેને અમે “Kittenhouse” કહીએ છીએ, જે “ClickHouse” સાથે એક જોડાણ જાળવી રાખે છે અને દર થોડીક સેકન્ડમાં ડેટા દાખલ કરે છે. ડેટાને MergeTree માં નહીં, પરંતુ બફર કોષ્ટકમાં દાખલ કરે છે, જે સીધા જ MergeTree માં દાખલ કરવાનું ટાળવા માટે ચોક્કસ રીતે સેવા આપે છે.

બફર કોષ્ટકો સાથે કામ

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

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

કિટનહાઉસ શું છે અને તે કેવી રીતે કામ કરે છે?

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

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

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

nginx ઉમેરો

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

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

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

ઉકેલથી એક પગલું દૂર

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

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

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

રિવર્સ પ્રોક્સી સાથે nginx ને બદલીને

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

તે શુ કરી રહ્યો છે? તે fasthttp લાઇબ્રેરી “goshnoy” પર આધારિત કામ કરે છે, એટલે કે ઝડપી, લગભગ nginx જેટલી ઝડપી. માફ કરશો, ઇગોર, જો તમે અહીં હાજર છો (નોંધ: ઇગોર સિસોએવ એક રશિયન પ્રોગ્રામર છે જેણે nginx વેબ સર્વર બનાવ્યું છે). તે સમજી શકે છે કે આ કયા પ્રકારની ક્વેરીઝ છે – INSERT અથવા SELECT – તે મુજબ, તે વિવિધ પ્રકારની ક્વેરીઝ માટે અલગ અલગ કનેક્શન પૂલ ધરાવે છે.

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

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

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

કિલર એ અસ્થાયી ઉકેલ છે, બિલાડીનું બચ્ચું કાયમી છે

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

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

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

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

બફર ટેબલ ઉદાસી છે

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

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

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

કોણ જાણતું હતું કે આ વ્યક્તિનું નામ સ્પોટી હતું? વીકેના કર્મચારીઓએ હાથ ઉંચા કર્યા. બરાબર.

"કિટનહાઉસ" માટેની યોજનાઓ વિશે

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

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

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

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

વાંચન વિશે વાત કરીએ

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

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

અને તે સિક્વલ પ્રો જેવું જ લાગે છે, પરંતુ માત્ર Twitter ના બુટસ્ટ્રેપ અને બીજા સંસ્કરણ પર બનાવેલ છે. તમે પૂછો: "યુરી, બીજા સંસ્કરણ પર કેમ?" કયા વર્ષ? 2018? સામાન્ય રીતે, મેં "સ્નાયુ" (MySQL) માટે આ ખૂબ લાંબા સમય પહેલા કર્યું હતું અને ત્યાં ક્વેરીઝમાં માત્ર બે લીટીઓ બદલી હતી, અને તે "ક્લિકહાઉસ" માટે કામ કરવાનું શરૂ કર્યું હતું, જેના માટે ખાસ આભાર! કારણ કે પાર્સર "સ્નાયુ" એક જેવું જ છે, અને પ્રશ્નો ખૂબ સમાન છે - ખૂબ અનુકૂળ, ખાસ કરીને શરૂઆતમાં.

સારું, તે કોષ્ટકોને ફિલ્ટર કરી શકે છે, કોષ્ટકની રચના અને સામગ્રીઓ બતાવી શકે છે, તમને સૉર્ટ કરવા, કૉલમ દ્વારા ફિલ્ટર કરવાની મંજૂરી આપે છે, પરિણામમાં પરિણમેલી ક્વેરી દર્શાવે છે, અસરગ્રસ્ત પંક્તિઓ (પરિણામે કેટલી), એટલે કે, ડેટા જોવા માટે મૂળભૂત બાબતો. ખૂબ ઝડપી.

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

"ક્લિકહાઉસ" ડેન્સ માટે યોગ્ય છે

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

TCP? સામાન્ય રીતે, વીકેમાં યુડીપીનો ઉપયોગ કરવાનો રિવાજ છે. અને જ્યારે મેં TCP નો ઉપયોગ કર્યો... અલબત્ત, કોઈએ મને કહ્યું નહીં: “યુરી, તમે શેની વાત કરો છો! તમે કરી શકતા નથી, તમારે UDPની જરૂર છે." તે બહાર આવ્યું છે કે TCP એટલી ડરામણી નથી. એકમાત્ર વસ્તુ એ છે કે, જો તમારી પાસે હજારો સક્રિય સંયોજનો છે જે તમે લખો છો, તો તમારે તેને થોડી વધુ કાળજીપૂર્વક તૈયાર કરવાની જરૂર છે; પરંતુ તે શક્ય છે, અને તદ્દન સરળ છે.

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

લીડ: - મિત્રો, હવે પ્રશ્નો માટે. અમે પ્રશંસાનું પ્રમાણપત્ર અને VHS પર તમારો રિપોર્ટ રજૂ કરીએ તે પછી જ.

યુરી નસરેટદીનોવ (ત્યારબાદ YN તરીકે ઓળખાય છે): - જો તે હમણાં જ સમાપ્ત થયો હોય તો તમે VHS પર મારો રિપોર્ટ કેવી રીતે રેકોર્ડ કરી શક્યા?

લીડ: - તમે "ક્લિકહાઉસ" કેવી રીતે કાર્ય કરશે કે નહીં તે પણ સંપૂર્ણપણે નિર્ધારિત કરી શકતા નથી! મિત્રો, પ્રશ્નો માટે 5 મિનિટ!

પ્રશ્નો

પ્રેક્ષકો તરફથી પ્રશ્ન (ત્યારબાદ Q તરીકે ઓળખવામાં આવે છે): - શુભ બપોર. અહેવાલ માટે તમારો ખૂબ ખૂબ આભાર. મારા બે પ્રશ્નો છે. હું કંઈક વ્યર્થથી શરૂ કરીશ: શું આકૃતિઓમાં (3, 4, 7...) "બિલાડીનું ઘર" નામમાં t અક્ષરોની સંખ્યા બિલાડીઓના સંતોષને અસર કરે છે?

YN: - શું જથ્થો?

З: - પત્ર ટી. ત્યાં ત્રણ ટી છે, ક્યાંક ત્રણ ટીની આસપાસ.

YN: - શું મેં તેને ઠીક કર્યું નથી? ઠીક છે, અલબત્ત તે કરે છે! આ અલગ-અલગ પ્રોડક્ટ્સ છે - આટલો સમય હું તમને છેતરતો હતો. ઠીક છે, હું મજાક કરું છું - તે કોઈ વાંધો નથી. આહ, અહીં જ! ના, તે જ વસ્તુ છે, મેં એક ટાઇપો કર્યો છે.

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

YN: - હા.

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

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

З: - એટલે કે, "બિલાડીનું ઘર" વિન્ડોને લાંબા સમય સુધી પકડી રાખે છે અને, પડી જવાના કિસ્સામાં, તેને ઓળખી શકે છે અને તેને રીવાઇન્ડ કરી શકે છે?

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

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

YN: - આપણે TCP શું વાપરીએ છીએ?

З: - અનિવાર્યપણે હા.

YN: - ના.

З: - ફાસ્ટhttp સાથે તમને સમસ્યાઓ હતી, કનેક્શનમાં તમને સમસ્યાઓ હતી. જો તમે હમણાં જ UDP નો ઉપયોગ કર્યો હોત તો તમે તમારો થોડો સમય બચાવી લીધો હોત. ઠીક છે, લાંબા સંદેશાઓ અથવા અન્ય કંઈક સાથે સમસ્યા હશે...

YN: - શેની સાથે?

З: - લાંબા સંદેશાઓ સાથે, કારણ કે તે MTU માં બંધબેસતું નથી, બીજું કંઈક... સારું, તેમની પોતાની સમસ્યાઓ હોઈ શકે છે. પ્રશ્ન એ છે કે યુડીપી કેમ નહીં?

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

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

YN: - મને બંનેની જરૂર છે - મારે ડિલિવરીની ગેરંટી સાથે અને ડિલિવરીની ગેરંટી વિના બંને મોકલવા સક્ષમ હોવા જોઈએ. આ બે અલગ અલગ દૃશ્યો છે. મારે અમુક લૉગ્સ ગુમાવવાની જરૂર નથી અથવા તેમને કારણસર ગુમાવવાની જરૂર નથી.

З: - હું સમય બગાડીશ નહીં. આ અંગે વધુ ચર્ચા કરવાની જરૂર છે. આભાર.

લીડ: - કોને પ્રશ્નો છે - આકાશ તરફ હાથ!

З: - હેલો, હું સાશા છું. અહેવાલની મધ્યમાં ક્યાંક, એક લાગણી દેખાઈ કે, TCP ઉપરાંત, તૈયાર સોલ્યુશનનો ઉપયોગ કરવો શક્ય છે - અમુક પ્રકારના કાફકા.

YN: - સારું... મેં તમને કહ્યું કે હું મધ્યવર્તી સર્વર્સનો ઉપયોગ કરવા માંગતો નથી, કારણ કે... કાફકામાં, તે તારણ આપે છે કે અમારી પાસે દસ હજાર યજમાનો છે; હકીકતમાં, અમારી પાસે વધુ છે - હજારો યજમાનો. કોઈપણ પ્રોક્સી વિના કાફકા સાથે કરવું પણ દુઃખદાયક હોઈ શકે છે. વધુમાં, સૌથી અગત્યનું, તે હજી પણ "લેટન્સી" આપે છે, તે વધારાના હોસ્ટ આપે છે જે તમારી પાસે હોવું જરૂરી છે. પરંતુ હું તે મેળવવા માંગતો નથી - હું ઈચ્છું છું ...

З: "પરંતુ અંતે તે કોઈપણ રીતે તે રીતે બહાર આવ્યું."

YN: - ના, ત્યાં કોઈ યજમાનો નથી! આ બધું ક્લિકહાઉસ હોસ્ટ પર કામ કરે છે.

З: - સારું, અને "બિલાડીનું ઘર", જે વિપરીત છે - તે ક્યાં રહે છે?

YN: - ક્લિકહાઉસ હોસ્ટ પર, તે ડિસ્ક પર કંઈપણ લખતું નથી.

З: - ચાલો ધારીએ.

લીડ: - તમને સંતોષ થયો છે? શું અમે તમને પગાર આપી શકીએ?

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

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

З: - મને કહો, શા માટે તમે કોઈ કતાર અથવા કોઈ સામાન્ય બસનો પ્રયાસ કર્યો નથી? કારણ કે તમે કહો છો કે અસુમેળ સાથે તમે કતાર દ્વારા લોગ્સ જાતે મોકલી શકો છો અને કતાર દ્વારા અસુમેળ રીતે પ્રતિસાદ પ્રાપ્ત કરી શકો છો?

YN: - કૃપા કરીને સૂચવો કે કઈ કતારોનો ઉપયોગ કરી શકાય?

З: - કોઈપણ, તેઓ ક્રમમાં છે તેની બાંયધરી વિના પણ. અમુક પ્રકારની Redis, RMQ...

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

લીડ: - યુરી, તમારો ખૂબ ખૂબ આભાર. હું અહીં પ્રશ્નો અને જવાબો સમાપ્ત કરવાનો પ્રસ્તાવ મૂકું છું અને કહું છું કે જેમણે પ્રશ્ન પૂછ્યો હતો તેમાંથી કોને અમે પુસ્તક આપીશું.

YN: – હું પ્રશ્ન પૂછનાર પ્રથમ વ્યક્તિને પુસ્તક આપવા માંગુ છું.

લીડ: - અદ્ભુત! મહાન! કલ્પિત! ખુબ ખુબ આભાર!

કેટલીક જાહેરાતો 🙂

અમારી સાથે રહેવા બદલ આભાર. શું તમને અમારા લેખો ગમે છે? વધુ રસપ્રદ સામગ્રી જોવા માંગો છો? ઓર્ડર આપીને અથવા મિત્રોને ભલામણ કરીને અમને ટેકો આપો, $4.99 થી વિકાસકર્તાઓ માટે ક્લાઉડ VPS, એન્ટ્રી-લેવલ સર્વર્સનું એક અનન્ય એનાલોગ, જેની શોધ અમારા દ્વારા તમારા માટે કરવામાં આવી છે: VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps વિશેનું સંપૂર્ણ સત્ય $19 થી અથવા સર્વર કેવી રીતે શેર કરવું? (RAID1 અને RAID10 સાથે ઉપલબ્ધ, 24 કોરો સુધી અને 40GB DDR4 સુધી).

એમ્સ્ટરડેમમાં ઇક્વિનિક્સ ટાયર IV ડેટા સેન્ટરમાં ડેલ R730xd 2 ગણું સસ્તું? માત્ર અહીં 2 x ઇન્ટેલ ટેટ્રાડેકા-કોર Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ટીવી $199 થી નેધરલેન્ડમાં! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 થી! વિશે વાંચો ઇન્ફ્રાસ્ટ્રક્ચર કોર્પોરેશન કેવી રીતે બનાવવું. ડેલ R730xd E5-2650 v4 સર્વર્સના ઉપયોગ સાથેનો વર્ગ એક પેની માટે 9000 યુરોના મૂલ્યના છે?

સોર્સ: www.habr.com