Уақыт қатарларының дерекқорын пайдалансаңыз (дб тайм сериялары, ) статистикасы бар сайттың негізгі қоймасы ретінде, онда мәселені шешудің орнына сіз көп бас ауруы аласыз. Мен осындай дерекқорды пайдаланатын жобада жұмыс істеп жатырмын, кейде талқыланатын InfluxDB мүлдем күтпеген тосын сыйларды ұсынды.
Жауапкершіліктен бас тарту: Тізімдегі мәселелер InfluxDB 1.7.4 нұсқасына қатысты.
Неліктен уақыт қатары?
Жоба әртүрлі блокчейндердегі транзакцияларды қадағалау және статистиканы көрсету болып табылады. Атап айтқанда, біз тұрақты монеталардың эмиссиясы мен жағуын қарастырамыз (). Осы транзакциялар негізінде графиктер құру және жиынтық кестелерді көрсету керек.
Транзакцияларды талдау кезінде идея пайда болды: InfluxDB уақыт сериясының дерекқорын негізгі жады ретінде пайдалану. Транзакциялар уақыттың нүктелері болып табылады және олар уақыт сериясының үлгісіне жақсы сәйкес келеді.
Агрегация функциялары да өте ыңғайлы болып көрінді - ұзақ мерзімді диаграммаларды өңдеу үшін өте қолайлы. Пайдаланушыға бір жыл бойы диаграмма қажет, ал дерекқорда бес минуттық уақыт шеңбері бар деректер жиынтығы бар. Оған барлық жүз мың нүктелерді жіберу мағынасыз - ұзақ өңдеуден басқа, олар тіпті экранға сыймайды. Уақыт аралығын ұлғайту үшін өзіңіздің жеке іске асыруыңызды жаза аласыз немесе Influx ішіне енгізілген біріктіру функцияларын пайдалана аласыз. Олардың көмегімен деректерді күні бойынша топтап, қажетті 365 ұпай жіберуге болады.
Мұндай дерекқорлар әдетте көрсеткіштерді жинау үшін пайдаланылатыны аздап түсініксіз болды. Серверлердің, IOT құрылғыларының мониторингі, олардың барлығынан миллиондаған нүктелер «ағын» түріндегі: [<уақыт> - <метрикалық мән>]. Бірақ егер деректер базасы үлкен деректер ағынымен жақсы жұмыс істейтін болса, онда неге шағын көлем проблемалар туғызуы керек? Осыны ескере отырып, біз InfluxDB жұмысына кірістік.
InfluxDB-де тағы не ыңғайлы
Жоғарыда аталған біріктіру функцияларынан басқа, тағы бір керемет нәрсе бар - үздіксіз сұраулар (). Бұл кесте бойынша деректерді өңдей алатын дерекқорға енгізілген жоспарлаушы. Мысалы, әр 24 сағат сайын сіз өзіңіздің велосипедтеріңізді жазбай-ақ, күннің барлық жазбаларын топтауға, орташа мәнді есептеуге және басқа кестеге бір жаңа нүктені жазуға болады.
Сондай-ақ бар сақтау саясаты ()—белгілі бір кезеңнен кейін деректерді жоюды орнату. Бұл, мысалы, секундына бір рет өлшеулермен CPU жүктемесін бір апта бойы сақтау қажет болғанда пайдалы, бірақ бірнеше айлық қашықтықта мұндай дәлдік қажет емес. Мұндай жағдайда сіз мұны істей аласыз:
- мәліметтерді басқа кестеге біріктіру үшін үздіксіз сұраныс құру;
- бірінші кесте үшін сол аптадан асқан көрсеткіштерді жою саясатын анықтаңыз.
Ал Influx деректердің көлемін дербес азайтады және қажет емес нәрселерді жояды.
Сақталған деректер туралы
Деректер көп сақталмайды: шамамен 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Мен тізімде кестені көрмеймін, бірақ жаңа деректер сұрауы әлі де бірдей транзакциялар жинағын қайтарады.
Мәселе менде тек бір рет болды, себебі жою ісі оқшауланған жағдай болды. Бірақ дерекқордың бұл әрекеті «дұрыс» операция шеңберіне сәйкес келмейтіні анық. Кейінірек мен оны github-та ашық деп таптым шамамен бір жыл бұрын осы тақырыпта.
Нәтижесінде бүкіл дерекқорды жою, содан кейін қалпына келтіру көмектесті.
2. Жылжымалы нүктелі сандар
InfluxDB ішіндегі кірістірілген функцияларды пайдалану кезіндегі математикалық есептеулерде дәлдік қателері бар. Бұл әдеттен тыс нәрсе емес, бірақ бұл жағымсыз.
Менің жағдайда деректердің қаржылық құрамдас бөлігі бар және мен оны жоғары дәлдікпен өңдеуді қалаймын. Осыған байланысты біз үздіксіз сұраулардан бас тартуды жоспарлап отырмыз.
3. Үздіксіз сұрауларды әртүрлі уақыт белдеулеріне бейімдеу мүмкін емес
Қызметте күнделікті транзакциялар статистикасы бар кесте бар. Әр күн үшін сол күндегі барлық транзакцияларды топтау керек. Бірақ әр пайдаланушының күні басқа уақытта басталады, сондықтан транзакциялар жиынтығы әртүрлі болады. UTC бойынша иә деректерді біріктіру қажет ауысымдар.
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 1SELECT * FROM dominance_info ORDER BY time DESC LIMIT 1SELECT * FROM transactions WHERE time >= NOW() - 24h ORDER BY time DESCТүсіндіру:
- Бірінші сұрауда біз нарықтық деректермен әрбір монета үшін соңғы ұпайларды аламыз. Менің жағдайда сегіз монета үшін сегіз ұпай.
- Екінші сұрау ең жаңа ұпайлардың бірін алады.
- Үшіншісі соңғы XNUMX сағаттағы транзакциялар тізімін сұрайды; олардың бірнеше жүз болуы мүмкін.
InfluxDB сұрауларды жылдамдататын тегтер мен уақытқа негізделген индексті автоматты түрде құрастыратынын түсіндірейін. Бірінші өтініште символы тег болып табылады.
Мен осы API әдісінде стресс-тест жүргіздім. 25 RPS үшін сервер алты процессордың толық жүктемесін көрсетті:
Сонымен қатар, NodeJs процесі ешқандай жүктемені қамтамасыз етпеді.
Орындау жылдамдығы қазірдің өзінде 7-10 RPS төмендеді: егер бір клиент 200 мс ішінде жауап ала алса, 10 клиент бір секунд күтуге тура келді. 25 RPS - тұрақтылық бұзылған шек; клиенттерге 500 қате қайтарылды.
Мұндай өнімділікпен біздің жобада Influx пайдалану мүмкін емес. Оған қоса: бақылауды көптеген клиенттерге көрсету қажет жобада ұқсас мәселелер пайда болуы мүмкін және метрика сервері шамадан тыс жүктеледі.
қорытынды
Алынған тәжірибеден ең маңызды қорытынды - жеткілікті талдаусыз белгісіз технологияны жобаға қабылдауға болмайды. Github жүйесіндегі ашық мәселелердің қарапайым скринингі InfluxDB-ті негізгі деректер қоймасы ретінде таңдаудан аулақ болу үшін ақпарат бере алады.
InfluxDB менің жобамның тапсырмаларына жақсы сәйкес болуы керек еді, бірақ тәжірибе көрсеткендей, бұл дерекқор қажеттіліктерге сай емес және көптеген қателер бар.
Сіз жоба репозиторийінде 2.0.0-бета нұсқасын таба аласыз, тек екінші нұсқада айтарлықтай жақсартулар болады деп үміттенеміз. Әзірше мен TimescaleDB құжаттамасын зерттеймін.
Ақпарат көзі: www.habr.com