Node 생태계를 열심히 연습하고 있었습니다. (NodeJS로 몇가지 연습). 하지만 졸업작품 빔을 맞아버려서, 졸업작품을 준비하게 되었습니다. 졸업 작품에 제가 자신있는 기술들을 통해서, 담백하게 진행하려고 했는데 , 교수님들이 AI를 묻히는 바람에,AI 웹 서비스가 될 것 같습니다.
AI 서비스가 힘든 이유
- 고성능 서버가 없어, 학습 / 테스팅 과정이 오래 걸린다.
- AI 서비스를 위해서는 대용량의 데이터를 확보하는 작업이 필요한데, 대용량 데이터가 쌓이는 것 자체가 만만치 않은 과제입니다.
하지만, 오히려 좋아. AI 웹 서비스 간지 나잖아?
대규모 처리를 해봤다면 , 뭔가 간지 나잖아? Shit.. 신인류 느낌도 나고
AI팀을 맡은 친구와 기술스택에 대한 협의를 진행해봤습니다.
SHark: 야, 너네 AI에서 TesorFlow 쓰잖아 , 그거 Python이지
노예1: 어 그거 Python이지.
SHark: 어, 그럼, FAST API나 Django로 Python으로 좀 통일 시킬까?
노예1: 그래, 그러자!
SHark : 노예1아, 근데 우리 DB는 설계 어케함? 우리 데이터 1초당 300개씩 발생하는 시계열 데이터인데, 엌ㅋㅋㅋㅋㅋ RDBMS 가능?
노예1 : 나도 맨날 Excel(CSV파일)에서 데이터 긁어온 경험밖에 없는데 엌ㅋㅋㅋㅋㅋㅋㅋㅋㅋ
데이터에 대한 이해도가 먼저였다.
JavaScript 생태계에 있던 나 였기 때문에, JSON은 무척 친숙한 데이터 포맷이다. 하지만,관계형 데이터 베이스에서는 JSON 형태가아니라, Row/column 형태의 2차원 테이블 형태로 데이터를 나타내고, 하나의 필드에는 하나의 데이터 밖에 못들어간다.
결국, 여러번의 회의를 거치다가 후보군이 좁혀졌다.
- MySQL (국밥) , JSON 가능. SQL
- MongoDB , NoSQL 기반.
- Postgre SQL , JSON 가능 . SQL
MySQL은 친숙하고 당장 적용할 수 있다는 장점이 있지만, 확장성에서 아쉬움이 있었다.
MongoDB는 NoSQL을 한번도 다루어 본적이 없고, NoSQL을 어떻게 설계해야하는지에 대한 당장의 러닝커브가 꽤 크다는 단점이 있었다.
Postgre SQL은 RDBMS 처럼 쓸 수도 있지만, 여러가지 확장기능(timescaledb)이 있다는 장점이 있다.
Third Party API를 보자.
데이터가 발생하는 부분은 결국 실험장비고, 실험장비의 API에서 어떻게 데이터를 던져주는지 한번 확인해보기로 했다. C언어 API이었고, Python convert(Cpython)이있어서, python, c++,go 와같은 언어에서 API를 쓰는데는 문제가 없었고, DB는 array형태로 돌아오는 걸 확인했다. 음.. NoSQL의 러닝커브가 우선적으로 꽤 크니까,관계형 DB로 쓰기로 했고, 확장기능이 준비되어있는 Postgre SQL을 선택하기로 했다.
