InfluxDB-യിൽ പ്രവർത്തിക്കുമ്പോൾ കോപം, വിലപേശൽ, വിഷാദം

നിങ്ങൾ ഒരു സമയ ശ്രേണി ഡാറ്റാബേസ് ഉപയോഗിക്കുകയാണെങ്കിൽ (ടൈം സീരീസ് db, വിക്കി) സ്ഥിതിവിവരക്കണക്കുകളുള്ള ഒരു സൈറ്റിന്റെ പ്രധാന സംഭരണം എന്ന നിലയിൽ, പ്രശ്നം പരിഹരിക്കുന്നതിന് പകരം നിങ്ങൾക്ക് ധാരാളം തലവേദനകൾ ലഭിക്കും. അത്തരമൊരു ഡാറ്റാബേസ് ഉപയോഗിക്കുന്ന ഒരു പ്രോജക്റ്റിൽ ഞാൻ പ്രവർത്തിക്കുന്നു, ചിലപ്പോൾ InfluxDB, ചർച്ച ചെയ്യപ്പെടും, തികച്ചും അപ്രതീക്ഷിതമായ ആശ്ചര്യങ്ങൾ അവതരിപ്പിക്കും.

നിരാകരണം: ലിസ്റ്റുചെയ്തിരിക്കുന്ന പ്രശ്നങ്ങൾ InfluxDB പതിപ്പ് 1.7.4-ന് ബാധകമാണ്.

എന്തുകൊണ്ട് സമയ പരമ്പര?

വിവിധ ബ്ലോക്ക് ചെയിനുകളിലെ ഇടപാടുകൾ ട്രാക്ക് ചെയ്യുകയും സ്ഥിതിവിവരക്കണക്കുകൾ പ്രദർശിപ്പിക്കുകയും ചെയ്യുന്നതാണ് പദ്ധതി. പ്രത്യേകിച്ചും, സ്ഥിരമായ നാണയങ്ങളുടെ ഉദ്വമനവും കത്തുന്നതും ഞങ്ങൾ നോക്കുന്നു (വിക്കി). ഈ ഇടപാടുകളെ അടിസ്ഥാനമാക്കി, നിങ്ങൾ ഗ്രാഫുകൾ നിർമ്മിക്കുകയും സംഗ്രഹ പട്ടികകൾ കാണിക്കുകയും വേണം.

ഇടപാടുകൾ വിശകലനം ചെയ്യുമ്പോൾ, ഒരു ആശയം വന്നു: പ്രധാന സംഭരണമായി InfluxDB ടൈം സീരീസ് ഡാറ്റാബേസ് ഉപയോഗിക്കാൻ. ഇടപാടുകൾ സമയത്തിന്റെ പോയിന്റുകളാണ്, അവ സമയ ശ്രേണി മോഡലുമായി നന്നായി യോജിക്കുന്നു.

അഗ്രഗേഷൻ ഫംഗ്‌ഷനുകളും വളരെ സൗകര്യപ്രദമായി കാണപ്പെട്ടു - ദീർഘകാല ചാർട്ടുകൾ പ്രോസസ്സ് ചെയ്യുന്നതിന് അനുയോജ്യം. ഉപയോക്താവിന് ഒരു വർഷത്തേക്ക് ഒരു ചാർട്ട് ആവശ്യമാണ്, കൂടാതെ ഡാറ്റാബേസിൽ അഞ്ച് മിനിറ്റ് സമയ ഫ്രെയിം ഉള്ള ഒരു ഡാറ്റ സെറ്റ് അടങ്ങിയിരിക്കുന്നു. അദ്ദേഹത്തിന് ഒരു ലക്ഷം ഡോട്ടുകൾ അയയ്‌ക്കുന്നതിൽ അർത്ഥമില്ല - നീണ്ട പ്രോസസ്സിംഗിന് പുറമെ, അവ സ്‌ക്രീനിൽ പോലും യോജിക്കില്ല. ടൈംഫ്രെയിം വർദ്ധിപ്പിക്കുന്നതിനുള്ള നിങ്ങളുടെ സ്വന്തം നിർവ്വഹണം നിങ്ങൾക്ക് എഴുതാം, അല്ലെങ്കിൽ ഇൻഫ്ലക്സിൽ നിർമ്മിച്ച അഗ്രഗേഷൻ ഫംഗ്ഷനുകൾ ഉപയോഗിക്കുക. അവരുടെ സഹായത്തോടെ, നിങ്ങൾക്ക് ദിവസം അനുസരിച്ച് ഡാറ്റ ഗ്രൂപ്പുചെയ്യാനും ആവശ്യമായ 365 പോയിന്റുകൾ അയയ്ക്കാനും കഴിയും.

ഇത്തരം ഡാറ്റാബേസുകൾ സാധാരണയായി മെട്രിക്‌സ് ശേഖരിക്കുന്നതിന് വേണ്ടിയാണ് ഉപയോഗിക്കുന്നത് എന്നത് അൽപ്പം ആശയക്കുഴപ്പമുണ്ടാക്കി. സെർവറുകൾ, ഐഒടി ഉപകരണങ്ങൾ, "ഫ്ലോ" എന്ന ഫോമിന്റെ ദശലക്ഷക്കണക്കിന് പോയിന്റുകൾ എന്നിവയുടെ നിരീക്ഷണം: [<time> - <മെട്രിക് മൂല്യം>]. എന്നാൽ ഒരു വലിയ ഡാറ്റാ ഫ്ലോയ്‌ക്കൊപ്പം ഡാറ്റാബേസ് നന്നായി പ്രവർത്തിക്കുന്നുണ്ടെങ്കിൽ, ഒരു ചെറിയ വോളിയം എന്തുകൊണ്ട് പ്രശ്‌നങ്ങൾ ഉണ്ടാക്കണം? ഇത് മനസ്സിൽ വെച്ചുകൊണ്ട്, ഞങ്ങൾ InfluxDB പ്രവർത്തനത്തിലേക്ക് എടുത്തു.

InfluxDB-യിൽ മറ്റെന്താണ് സൗകര്യപ്രദം

സൂചിപ്പിച്ച അഗ്രഗേഷൻ ഫംഗ്‌ഷനുകൾ കൂടാതെ, മറ്റൊരു മഹത്തായ കാര്യമുണ്ട് - തുടർച്ചയായ അന്വേഷണങ്ങൾ (ഡോക്). ഒരു ഷെഡ്യൂളിൽ ഡാറ്റ പ്രോസസ്സ് ചെയ്യാൻ കഴിയുന്ന ഡാറ്റാബേസിൽ നിർമ്മിച്ച ഒരു ഷെഡ്യൂളറാണിത്. ഉദാഹരണത്തിന്, ഓരോ 24 മണിക്കൂറിലും നിങ്ങൾക്ക് ഒരു ദിവസത്തെ എല്ലാ റെക്കോർഡുകളും ഗ്രൂപ്പുചെയ്യാനും ശരാശരി കണക്കാക്കാനും നിങ്ങളുടെ സ്വന്തം സൈക്കിളുകൾ എഴുതാതെ മറ്റൊരു പട്ടികയിൽ ഒരു പുതിയ പോയിന്റ് രേഖപ്പെടുത്താനും കഴിയും.

ഉണ്ട് നിലനിർത്തൽ നയങ്ങൾ (ഡോക്)-ഒരു നിശ്ചിത കാലയളവിനുശേഷം ഡാറ്റ ഇല്ലാതാക്കൽ സജ്ജീകരിക്കുന്നു. ഉദാഹരണത്തിന്, നിങ്ങൾ സെക്കൻഡിൽ ഒരിക്കൽ അളവുകൾ ഉപയോഗിച്ച് സിപിയു ലോഡ് ഒരാഴ്ചത്തേക്ക് സംഭരിക്കേണ്ടിവരുമ്പോൾ ഇത് ഉപയോഗപ്രദമാണ്, എന്നാൽ കുറച്ച് മാസത്തെ ദൂരത്തിൽ അത്തരം കൃത്യത ആവശ്യമില്ല. അത്തരമൊരു സാഹചര്യത്തിൽ, നിങ്ങൾക്ക് ഇത് ചെയ്യാൻ കഴിയും:

1. മറ്റൊരു പട്ടികയിലേക്ക് ഡാറ്റ സമാഹരിക്കാൻ തുടർച്ചയായ അന്വേഷണം സൃഷ്ടിക്കുക;
2. ആദ്യ പട്ടികയ്‌ക്കായി, അതേ ആഴ്‌ചയേക്കാൾ പഴയ മെട്രിക്‌സ് ഇല്ലാതാക്കുന്നതിനുള്ള ഒരു നയം നിർവ്വചിക്കുക.

കൂടാതെ ഇൻഫ്ലക്സ് സ്വതന്ത്രമായി ഡാറ്റയുടെ വലുപ്പം കുറയ്ക്കുകയും അനാവശ്യ കാര്യങ്ങൾ ഇല്ലാതാക്കുകയും ചെയ്യും.

സംഭരിച്ച ഡാറ്റയെക്കുറിച്ച്

കൂടുതൽ ഡാറ്റ സംഭരിച്ചിട്ടില്ല: ഏകദേശം 70 ആയിരം ഇടപാടുകളും വിപണി വിവരങ്ങളുള്ള മറ്റൊരു ദശലക്ഷം പോയിന്റുകളും. പുതിയ എൻട്രികൾ ചേർക്കുന്നു - പ്രതിദിനം 3000 പോയിന്റിൽ കൂടരുത്. സൈറ്റിനായി മെട്രിക്കുകളും ഉണ്ട്, പക്ഷേ അവിടെ കുറച്ച് ഡാറ്റയുണ്ട്, നിലനിർത്തൽ നയമനുസരിച്ച്, അവ ഒരു മാസത്തിൽ കൂടുതൽ സൂക്ഷിക്കില്ല.

പ്രശ്നങ്ങൾ

സേവനത്തിന്റെ വികസനത്തിലും തുടർന്നുള്ള പരിശോധനയിലും, InfluxDB യുടെ പ്രവർത്തനത്തിൽ കൂടുതൽ കൂടുതൽ ഗുരുതരമായ പ്രശ്നങ്ങൾ ഉയർന്നു.

1. ഡാറ്റ ഇല്ലാതാക്കുന്നു

ഇടപാടുകൾക്കൊപ്പം ഡാറ്റയുടെ ഒരു പരമ്പരയുണ്ട്:

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

ഫലം:

ഡാറ്റ ഇല്ലാതാക്കാൻ ഞാൻ ഒരു കമാൻഡ് അയയ്ക്കുന്നു:

DELETE FROM transactions WHERE symbol=’USDT’

അടുത്തതായി, ഇതിനകം ഇല്ലാതാക്കിയ ഡാറ്റ സ്വീകരിക്കാൻ ഞാൻ ഒരു അഭ്യർത്ഥന നടത്തുന്നു. ശൂന്യമായ പ്രതികരണത്തിന് പകരം, ഇല്ലാതാക്കേണ്ട ഡാറ്റയുടെ ഒരു ഭാഗം ഇൻഫ്ലക്സ് നൽകുന്നു.

ഞാൻ മുഴുവൻ പട്ടികയും ഇല്ലാതാക്കാൻ ശ്രമിക്കുന്നു:

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-ലേക്ക് തിരികെ തുടങ്ങും (ഇൻഫ്‌ലക്‌സ് ഡിബി ഔദ്യോഗികമായി ഈ വർഷം മുതലുള്ള സമയ പരിധിയെ പിന്തുണയ്ക്കുന്നു):

ഈ പ്രശ്നം പരിഹരിക്കാൻ, ഞങ്ങൾ താൽക്കാലികമായി 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 തിരഞ്ഞെടുക്കുന്നത് ഒഴിവാക്കാൻ github-ലെ തുറന്ന പ്രശ്നങ്ങളുടെ ലളിതമായ സ്ക്രീനിംഗ് വിവരങ്ങൾ നൽകും.

എന്റെ പ്രോജക്റ്റിന്റെ ചുമതലകൾക്ക് InfluxDB അനുയോജ്യമാകണം, എന്നാൽ പ്രാക്ടീസ് കാണിക്കുന്നത് പോലെ, ഈ ഡാറ്റാബേസ് ആവശ്യങ്ങൾ നിറവേറ്റുന്നില്ല, കൂടാതെ ധാരാളം ബഗുകളും ഉണ്ട്.

പ്രോജക്റ്റ് റിപ്പോസിറ്ററിയിൽ നിങ്ങൾക്ക് ഇതിനകം 2.0.0-ബീറ്റ പതിപ്പ് കണ്ടെത്താൻ കഴിയും; രണ്ടാമത്തെ പതിപ്പിന് കാര്യമായ മെച്ചപ്പെടുത്തലുകൾ ഉണ്ടാകുമെന്ന് ഞങ്ങൾ പ്രതീക്ഷിക്കുന്നു. അതിനിടയിൽ, ഞാൻ TimescaleDB ഡോക്യുമെന്റേഷൻ പഠിക്കാൻ പോകും.

അവലംബം: www.habr.com