InfluxDB 작업 시 분노, 협상 및 우울증

시계열 데이터베이스(timeseries db, 위키)을 통계가 있는 사이트의 기본 저장소로 사용하면 문제를 해결하는 대신 많은 골치 아픈 일을 겪을 수 있습니다. 저는 그러한 데이터베이스를 사용하는 프로젝트를 진행하고 있는데, 때때로 논의될 InfluxDB가 전혀 예상치 못한 놀라움을 선사했습니다.

책임 부인: 나열된 문제는 InfluxDB 버전 1.7.4에 적용됩니다.

왜 시계열인가?

이 프로젝트는 다양한 블록체인의 거래를 추적하고 통계를 표시하는 것입니다. 구체적으로는 스테이블 코인의 배출과 소각을 살펴본다(위키). 이러한 트랜잭션을 기반으로 그래프를 작성하고 요약 테이블을 표시해야 합니다.

트랜잭션을 분석하는 동안 InfluxDB 시계열 데이터베이스를 기본 저장소로 사용하는 아이디어가 떠올랐습니다. 거래는 특정 시점이며 시계열 모델에 잘 들어맞습니다.

집계 기능도 매우 편리해 보였습니다. 장기간 차트를 처리하는 데 이상적입니다. 사용자는 365년 동안의 차트가 필요하며 데이터베이스에는 XNUMX분 단위의 데이터 세트가 포함되어 있습니다. 그에게 십만 점을 모두 보내는 것은 의미가 없습니다. 긴 처리 시간을 제외하면 화면에 맞지도 않습니다. 기간을 늘리는 구현을 직접 작성하거나 Influx에 내장된 집계 기능을 사용할 수 있습니다. 이들의 도움을 받아 날짜별로 데이터를 그룹화하고 필요한 XNUMX개 포인트를 보낼 수 있습니다.

이러한 데이터베이스가 일반적으로 지표 수집을 목적으로 사용된다는 점이 약간 혼란스러웠습니다. 서버, IoT 장치, "흐름" 형태의 수백만 포인트가 있는 모든 것을 모니터링합니다: [<시간> - <메트릭 값>]. 그러나 데이터베이스가 대규모 데이터 흐름에서 잘 작동한다면 작은 볼륨이 문제를 일으키는 이유는 무엇입니까? 이를 염두에 두고 우리는 InfluxDB를 작업에 사용했습니다.

InfluxDB에서 또 무엇이 편리한가요?

언급된 집계 함수 외에도 또 다른 좋은 점이 있습니다. 연속 쿼리 (의사). 일정에 따라 데이터를 처리할 수 있는 데이터베이스에 내장된 스케줄러입니다. 예를 들어, 24시간마다 그날의 모든 기록을 그룹화하고, 평균을 계산하고, 자전거를 직접 작성하지 않고도 다른 테이블에 새로운 지점 하나를 기록할 수 있습니다.

또한있다 보존 정책 (의사)—특정 기간 이후 데이터 삭제를 설정합니다. 예를 들어, 초당 한 번씩 측정하여 일주일 동안 CPU 로드를 저장해야 하지만 몇 달 동안 이러한 정확도가 필요하지 않은 경우에 유용합니다. 이러한 상황에서는 다음과 같이 할 수 있습니다.

1. 데이터를 다른 테이블에 집계하기 위한 연속 쿼리를 생성합니다.
2. 첫 번째 테이블에 대해 같은 주보다 오래된 지표를 삭제하는 정책을 정의합니다.

그리고 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에서 열린 것을 발견했습니다. 티켓 거의 XNUMX년 전 이 주제에 관해.

결과적으로 전체 데이터베이스를 삭제한 후 복원하는 것이 도움이 되었습니다.

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. 첫 번째 요청에서는 시장 데이터를 사용하여 각 코인의 마지막 포인트를 얻습니다. 제 경우에는 동전 XNUMX개에 XNUMX점입니다.
2. 두 번째 요청은 최신 포인트 중 하나를 가져옵니다.
3. 세 번째는 지난 XNUMX시간 동안의 거래 목록을 요청하며 그 중 수백 개가 있을 수 있습니다.

InfluxDB는 태그와 시간을 기반으로 인덱스를 자동으로 구축하여 쿼리 속도를 높인다는 점을 분명히 하겠습니다. 첫 번째 요청에서는 상징 태그입니다.

이 API 메서드에 대해 스트레스 테스트를 실행했습니다. 25RPS의 경우 서버는 XNUMX개 CPU의 전체 로드를 시연했습니다.

동시에 NodeJs 프로세스는 전혀 로드를 제공하지 않았습니다.

실행 속도는 이미 7-10 RPS만큼 저하되었습니다. 한 클라이언트가 200ms 내에 응답을 받을 수 있다면 10개의 클라이언트는 25초를 기다려야 했습니다. 500RPS는 안정성이 저하되는 한계이며 XNUMX개의 오류가 클라이언트에 반환되었습니다.

이러한 성능으로 인해 우리 프로젝트에서는 Influx를 사용하는 것이 불가능합니다. 더욱이, 모니터링을 많은 클라이언트에게 시연해야 하는 프로젝트에서는 유사한 문제가 나타날 수 있으며 메트릭 서버가 과부하될 수 있습니다.

출력

얻은 경험에서 얻은 가장 중요한 결론은 충분한 분석 없이는 알려지지 않은 기술을 프로젝트에 도입할 수 없다는 것입니다. github에서 공개된 문제를 간단히 검사하면 InfluxDB를 기본 데이터 저장소로 선택하지 않도록 정보를 제공할 수 있습니다.

InfluxDB는 내 프로젝트 작업에 적합해야 했지만 실습에서 알 수 있듯이 이 데이터베이스는 요구 사항을 충족하지 못하고 버그가 많습니다.

프로젝트 저장소에서 이미 버전 2.0.0-베타를 찾을 수 있으며, 두 번째 버전에서는 상당한 개선이 이루어지기를 바랄 뿐입니다. 그동안 TimescaleDB 문서를 공부하러 가겠습니다.

출처 : habr.com