이전 내용
이전 포스팅에서는 현재 웹 모니터링 시스템에서의 DB를 TSDB로 교체하기 위해서 성능을 테스트 했었습니다.
그 결과는 매우 긍정적이었기 때문에 저는 연구실에서 현재 사용되는 센서 데이터의 저장과 조회를 RDB + Redis를 사용하던 DB구조에서 TSDB인 InfluxDB로 교체하는 역할을 전담하여서 프로젝트를 진행하게 되었습니다.
아래 포스팅은 SQL과 InfluxDB의 성능 테스트와 관련된 글 입니다 !!
SQL vs InfluxDB 쿼리 성능 비교 (1)
문제 상황 현재 우리 시스템에서는 SQL에 데이터를 쌓고 웹 에서는 redis를 이용하여 센서 데이터를 시각화하고있다. 하지만 아무리 Redis의 쿼리속도가 빠르고 좋다고 해도 SQL에 매 시간마다 쌓이
hello-jaemin.tistory.com
테스트를 성공적으로 마친 뒤, 저희 시스템에 바로 탑재할 수 있도록 기능을 개발하면서 현재 시스템에서 변경되는 과정을 기록용으로 남기는게 좋을 것 같다는 생각이 들어서 글을 포스팅하게 되었습니다.
Influx DB란 ?
먼저 InfluxDB에 대해 간략하게 다시 알아보자면 아래와 같습니다.
[1] 많은 쓰기 작업과 쿼리 부하의 처리를 위해 2013년에 Go 언어로 개발된 TSDB
[2] 가장 유명하고 많이 사용하는 TSDB ( 다른 TSDB에 비해 자료, 플러그인 풍부 )
- 저희 연구실에 경우에는 Nest-js와 OPC-UA와 관련된 오픈소스 플러그인을 활용하고 있는 상황입니다.
- https://www.influxdata.com/products/integrations/
[3] 기존 DB와 달리 TimeStamp 기반의 구조로 용량과 시간과 관련된 쿼리 성능 향상
- 기존 RDB와 달리 TSDB는 시간에 따라 파티셔닝[샤딩]하여 용량과 쿼리와 관련된 큰 성능 향상을 기대할 수 있습니다.
[4] 시간이 지남에 따라 축적된 데이터들은 최적화 되므로, 데이터 입력 속도 저하가 없음
- RDB의 경우에는 데이터 간의 관계나 인덱싱 작업 등으로 인해 데이터가 많아질수록 입력 시 속도 저하가 큰 폭으로 일어납니다.
- 하지만 Influx DB의 경우 시간에 따라 파티셔닝하여 저장하면서 그러한 입력 부하를 줄일 수 있습니다.
[5] 자동화된 기능 제공
시계열 DB에서 키 포인트는 대용량 데이터를 효율적으로 처리하여 양을 줄여서 관리하면서 이용 가치가 없는 데이터는 삭제하면서 용량을 관리해야 합니다.
이를 위해 InfluxDB에서는 CQ와 RP라는 기능을 제공하고 저희는 이를 적극적으로 활용하여 시스템을 구축하는데 목표로 하고 있습니다.
- CQ (continuous query) : 일정 주기마다 샘플링 후 데이터 적재
- RP (retention policy) : 특정 주기가 지난 데이터는 자동 삭제
현재 시스템의 문제 인식
현재 시스템과 문제상황
현제 웹 모니터링 대시보드 시스템에서는 관계형 DB인 MySQL과 Redis를 사용하여 시스템을 관리하는 중입니다.
- 회사, 센서 위치, 특징 정보 등 괸계형 DB가 필요한 정보는 MySQL에서 관리
- 센서 데이터 출력과 저장을 위한 저장소로는 Redis를 통해 조회 성능을 높임
하지만 캐시 DB인 Redis를 사용하면서 유지-보수나 관리적인 측면에서 문제가 다수 있었고, Redis로 다양한 쿼리를 제공하는데 한계가 있었기 때문에 이전부터 TSDB의 도입을 꾸준하게 고민하고 있었습니다.
Redis에서 발생한 약간의 문제에 대한 예시는 아래 자료로 나타냈습니다.
TSDB를 통해 해결
위의 내용을 해결하고자 시스템에 TSDB를 도입하고자 했고, 그 이전에 저희 시스템에 잘 탑재가 되고 성능적인 측면에서 유리한 면을 보인다면 유지-보수 측면에서 어려운 Redis 시스템을 아예 제외하거나, Redis의 비중을 최소한으로 줄이는 방향으로 시스템을 발전시키고자 했습니다.
그렇기 위해서는 DB에서 다뤄야 할 조회와 입력에 대한 측면과 DB를 유지하는데 필요한 측면에 대해서 분석이 필요했습니다.
분석 내용은 위에 참조한 이전 포스팅을 참고해서 비교하면 아래의 표와 같습니다.
물론 Redis에 비해 조회성능은 떨어지지만 1000만건에 대한 데이터에 대해 조건 쿼리를 걸었을 때 1초 이내로 데이터가 항상 출력되었기 때문에 충분히 적용할 만하다고 판단하게 되었습니다.
또한 테스트 환경에서 비교했을 때 인덱싱된 SQL과 10배 이상의 용량 차이를 보였고 샘플링과 데이터 관리 측면의 CQ와 RP가 지원되기 때문에 기존 시스템보다 유리한 측면이 더 크다고 판단하게 되었습니다.
시스템 적용
1. 기존에 구축된 센서 데이터 DataBase
현재 모니터링에서 사용하는 시스템 구조는 아래와 같습니다.
- DAQ에서 발생시키는 데이터가 웹 서버로 초마다 Post 합니다.
- 웹 서버에서는 데이터를 특정 주기마다 샘플링 시켜서 Redis의 해당하는 테이블에 입력
- Redis에서는 특정 기간 동안의 데이터 3600개를 유지하면서 그 이상되면 삭제시키는 큐 자료구조입니다.
- 한 시간치는 따로 main table에서 관리하면서 CMD 스케줄러를 통해 10분마다 MariaDB에 저장
위와 같이 조금 복잡한 구조를 가지게 됩니다.
2. InfluxDB를 사용하여 구축된 모델
하지만 InfluxDB의 구조를 사용하게 된다면 구조가 단순하게 됩니다.
왜냐하면 웹 서버에서 처리하던 관리 기간이 지난 데이터의 삭제나 샘플링 처리가 InfluxDB로 이전되었기 때문입니다.
웹 서버는 이제 단순히 DAQ에서 입력받은 데이터를 그대로 InfluxDB로 보내주는 중간자 역할만 수행합니다.
그 뒤, 나머지 작업은 InfluxDB에 탑재된 기능들로 대체됩니다.
웹 서버를 통해 들어온 데이터는 InfluxDB에서 샘플링 되고, RP에 따라서 데이터를 관리합니다.
따라서 웹서버에서 InfluxDB로 데이터를 관리하고 유지하는 기능이 넘어가면서 웹 서버의 부하를 줄일 수 있게 되었습니다.
또한 InfluxDB에서 제공하는 다양한 기능 ( 샘플링 옵션, 알람, 연산 옵션 ) 등을 사용할 수 있습니다.
위의 구조로 돌아가도록 InfluxDB 내에 RP와 CQ를 생성 한 뒤 , 현재 구축하여 가동하고 있는 웹 서버에서 테스트 환경의 웹 서버를 추가로 구축한 뒤, DAQ의 데이터를 두 곳으로 동시에 쏘면서 테스트 까지 진행해 보았습니다.
그 뒤 웹 서버를 통해 출력 결과를 확인했을 때 데이터가 성공적으로 들어오고 출력되는 것을 확인 할 수 있었습니다.
'Experience > Monthly Log' 카테고리의 다른 글
| [23/1월] 모니터링 시스템 시계열 DB 전환 (0) | 2023.02.19 |
|---|---|
| [22년] SQL vs InfluxDB 쿼리 성능 비교 (1) (0) | 2022.08.09 |
