InfluxDB સાથે કામ કરતી વખતે ગુસ્સો, સોદાબાજી અને હતાશા

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

જવાબદારીનો ઇનકાર: સૂચિબદ્ધ મુદ્દાઓ InfluxDB સંસ્કરણ 1.7.4 પર લાગુ થાય છે.

શા માટે સમય શ્રેણી?

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

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

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

તે થોડું ગૂંચવણભર્યું હતું કે આવા ડેટાબેસેસનો ઉપયોગ સામાન્ય રીતે મેટ્રિક્સ એકત્રિત કરવાના હેતુ માટે થાય છે. સર્વરનું મોનિટરિંગ, iot ઉપકરણો, દરેક વસ્તુ જેમાંથી "ફ્લો" ફોર્મના લાખો પોઈન્ટ્સ: [<time> - <metric value>]. પરંતુ જો ડેટાબેઝ મોટા ડેટા ફ્લો સાથે સારી રીતે કામ કરે છે, તો પછી નાના વોલ્યુમ શા માટે સમસ્યા ઊભી કરે છે? આને ધ્યાનમાં રાખીને, અમે InfluxDB ને કામ કરવા માટે લીધું.

InfluxDB માં બીજું શું અનુકૂળ છે

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

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

1. અન્ય કોષ્ટકમાં ડેટા એકત્ર કરવા માટે સતત ક્વેરી બનાવો;
2. પ્રથમ કોષ્ટક માટે, તે જ અઠવાડિયા કરતાં જૂના મેટ્રિક્સને કાઢી નાખવા માટેની નીતિ વ્યાખ્યાયિત કરો.

અને ઇન્ફ્લક્સ સ્વતંત્ર રીતે ડેટાનું કદ ઘટાડશે અને બિનજરૂરી વસ્તુઓ કાઢી નાખશે.

સંગ્રહિત ડેટા વિશે

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

સમસ્યાઓ

સેવાના વિકાસ અને અનુગામી પરીક્ષણ દરમિયાન, InfluxDB ના સંચાલનમાં વધુ અને વધુ જટિલ સમસ્યાઓ ઊભી થઈ.

1. ડેટા કાઢી રહ્યું છે

વ્યવહારો સાથે ડેટાની શ્રેણી છે:

SELECT time, amount, block, symbol FROM transactions WHERE symbol='USDT'

પરિણામ:

હું ડેટા કાઢી નાખવા માટે આદેશ મોકલી રહ્યો છું:

DELETE FROM transactions WHERE symbol=’USDT’

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

હું આખું કોષ્ટક કાઢી નાખવાનો પ્રયાસ કરી રહ્યો છું:

DROP MEASUREMENT transactions

હું કોષ્ટક કાઢી નાખવાની તપાસ કરું છું:

SHOW MEASUREMENTS

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

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

પરિણામે, સમગ્ર ડેટાબેઝને કાઢી નાખવા અને પછી પુનઃસ્થાપિત કરવામાં મદદ મળી.

2. ફ્લોટિંગ પોઈન્ટ નંબર્સ

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

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

3. સતત ક્વેરીઝને જુદા જુદા સમય ઝોનમાં સ્વીકારી શકાતી નથી

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

InfluxDB માં, જ્યારે સમય પ્રમાણે જૂથબદ્ધ કરવામાં આવે છે, ત્યારે તમે વધુમાં એક શિફ્ટનો ઉલ્લેખ કરી શકો છો, ઉદાહરણ તરીકે મોસ્કો સમય (UTC+3):

SELECT MEAN("supply") FROM transactions GROUP BY symbol, time(1d, 3h) fill(previous)

પરંતુ ક્વેરીનું પરિણામ ખોટું હશે. કેટલાક કારણોસર, દિવસ દ્વારા જૂથબદ્ધ થયેલ ડેટા 1677 થી શરૂ થશે (InfluxDB સત્તાવાર રીતે આ વર્ષથી સમયગાળાને સમર્થન આપે છે):

આ સમસ્યાને દૂર કરવા માટે, અમે અસ્થાયી રૂપે સેવાને UTC+0 પર સ્વિચ કરી છે.

4. પ્રદર્શન

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

હું તમને મારો કેસ કહીશ.

સેવા એક API પદ્ધતિ પ્રદાન કરે છે જે છેલ્લા દિવસના આંકડા આપે છે. ગણતરીઓ કરતી વખતે, પદ્ધતિ નીચેની ક્વેરીઝ સાથે ડેટાબેઝને ત્રણ વખત ક્વેરી કરે છે:

SELECT * FROM coins_info WHERE time <= NOW() GROUP BY symbol ORDER BY time DESC LIMIT 1

SELECT * FROM dominance_info ORDER BY time DESC LIMIT 1

SELECT * FROM transactions WHERE time >= NOW() - 24h ORDER BY time DESC

સમજૂતી:

1. પ્રથમ વિનંતીમાં, અમને બજારના ડેટા સાથે દરેક સિક્કા માટે છેલ્લા બિંદુઓ મળે છે. મારા કિસ્સામાં આઠ સિક્કા માટે આઠ પોઈન્ટ.
2. બીજી વિનંતીને સૌથી નવા મુદ્દાઓમાંથી એક મળે છે.
3. ત્રીજો વ્યક્તિ છેલ્લા XNUMX કલાકના વ્યવહારોની સૂચિની વિનંતી કરે છે; તેમાંના કેટલાક સો હોઈ શકે છે.

મને સ્પષ્ટ કરવા દો કે InfluxDB આપમેળે ટૅગ્સ અને સમયના આધારે ઇન્ડેક્સ બનાવે છે, જે ક્વેરીઝને ઝડપી બનાવે છે. પ્રથમ વિનંતીમાં પ્રતીક એક ટેગ છે.

મેં આ API પદ્ધતિ પર તણાવ પરીક્ષણ ચલાવ્યું છે. 25 RPS માટે, સર્વરે છ CPU નો સંપૂર્ણ લોડ દર્શાવ્યો:

તે જ સમયે, NodeJs પ્રક્રિયાએ કોઈપણ ભાર પૂરો પાડ્યો નથી.

એક્ઝેક્યુશન સ્પીડ પહેલેથી જ 7-10 RPS દ્વારા ઘટી ગઈ છે: જો એક ક્લાયંટ 200 ms માં પ્રતિસાદ પ્રાપ્ત કરી શકે, તો 10 ક્લાયન્ટે એક સેકન્ડ રાહ જોવી પડી. 25 RPS એ મર્યાદા છે કે જેના પર સ્થિરતાનો સામનો કરવો પડ્યો હતો; 500 ભૂલો ક્લાયંટને પરત કરવામાં આવી હતી.

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

નિષ્કર્ષ

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

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

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

સોર્સ: www.habr.com