임베디드 시스템에서, 대량의 타임시리즈 데이터를 저장할 일이 있을까?

- 이런 의문이 들었습니다.

임베디드 시스템에서, 대량의 타임시리즈 데이터를 저장할 일이 있을까?

- 근대, 타임시리즈 데이터가 무엇인가요?

여기 참고하시면, 되구요, 시계열 데이터라고 해서, 시간순으로 엄청나게 많은 데이터가 들어오는 것입니다. 예를 들면, 레코드에 꼭 시간값이 있고, 한 레코드의 크기는 그렇게 크지 않은대, 레코드의 개수가 엄청나게 많은 데이터를 말합니다. 자세한 내용은 아래 링크 참고 :-)

https://docs.microsoft.com/ko-kr/azure/architecture/data-guide/scenarios/time-series

시계열 데이터 - Azure Architecture Center

- 엄청나게 많다는게 몇개쯤? 그냥 RDBMS로 저장하면 되지 않을까요?

(지금 부터 말하는 숫자는 다 뇌피셜입니다. ㅎㅎ)

MySQL/PostgreSQL/Oracle 같은 널리 사용되는 RDBMS를 사용해서, 어느정도로 규모로 클러스터를 구성한다고 해도, 초당 입력할 수 있는 레코드 수는, 현실적으로 약 10만~ 20만 정도 입니다. RDBMS가 좋은 DBMS이지만, 트랜잭션도 지원해야 하고, 샤딩/클러스터링 하는대 들어가는 시간 등등을 가만하면 저정도 숫자가 한계라고 할 수 있습니다. 계속 클러스터안의 노드를 늘린다고해도, 성능은 어느정도 올라가지만, 노드수가 늘어날 수록, 증가하는 성능 감소 or 어느 구간에 수렴하게 됩니다.

물론, 클러스터 겁나 크게 구축하면, 1~20만 건 보다 훨씬 많이 넣을 수 있겠지만, 그럴려면 매우 많은 비용이... ㄷㄷㄷ

- 그럼, 엄청 많은 타임 시리즈 데이터는 몇개 정도 되는 건가요?

예를 들면, 초당 약 100만 건 정도 되는 데이터가 계속 입력되는 상황입니다.

- 초당 100만 건은 너무 비현실적인 상황 아닌가요?

예를 들어보면, 어떤 공장이 있습니다. 기계설비가 고장이나면 공장은 생산을 못하니까, 큰 문제이겠죠?
그래서, 요즘에는 각 기계설비에 센서를 엄청나게 달고 있습니다.

센서에서 들어오는 데이터를 분석해서, 기계설비 진동이 이렇게 커지기 시작하면, 일주일쯤 뒤에, 어느 부품이 고장 나더라. 이런 예측을 해서, 최대한 공장의 가동률을 높이는 것입니다.

- 그래봐야 데이터 몇개나 될까요?

이글에서 말하는 센서는 이런 단위로 동작합니다. 진동 센서류가 빠르게 동작하는 센서입니다.

60hz / 어머 초당 60번?
10ms / 어머 초당 100번?

공장설비 가격은 억대넘어 가는 장비 수두룩합니다. 센서 하나만 달려 있을까요?
센서 100개 달려 있다고 해보면, 100 x 100(10ms) = 1만건

공장에 장비 한개만 있을까요? 중간에 생산라인에는 센서가 없어도 될까요?
이렇게 따저 보면, 초당 100만건을 입력할 수 있다고 해도, 사실 그렇게 만족스러운 성능은 아닙니다.

- 요즘 핫한 AI를 학습시키는 대는 엄청난 데이터가 필요합니다.

자 이제 저장한 데이터를 사용해서, AI를 학습시켜 볼께요.
보다 더 짧은 주기로 데이터를 수집해서 AI에 학습시킬 수도록, AI의 추론 정확도는 어느정도 비례해서 상승합니다.

즉 1초 주기로 데이터를 모아서 학습시키는 것 보다,
100ms 주기로 학습시키면, 추론 정확도가 더 올라가구요,
10ms 면 더 올라가겠죠 ^^)-b

- 그렇군요, Time Series DBMS 회사에 투자해야 겠어요!!!

이미 다른 분들이 투자 많이 하셨구요, Google / Amazon 같은 회사들도, 자체 Time series DBMS를 개발및 클라우드에서 지원하고 있습니다. ㅋㅋㅋ

서론이 길었습니다.

임베디드 시스템에서, 대량의 타임시리즈 데이터를 저장할 일이 있을까?

이런 요구사항이 있을지...? 모르겠어요. ㅎㅎ

일단은 임베디드 시스템에서, SQLite나, 기존 파일 시스템이 제공하는 성능보다는, 보다 빠른 속도로,
압축도 잘해서, 타임시리즈 데이터를 저장하는 라이브러리가 필요할까? 라는 생각이 좀 들어요.

필요한분 있으시면 댓글 남겨주세요~