10.28(목) 데일리 스크럼 & 프로젝트 설계 회의록
어제 닭도리탕을 먹었습니다. 엽떡 = 특이식성
닭가슴살 그만 먹고 싶어요
짱구 장패드 샀습니다. 한입에 들어오는 닭가슴살 GOOD! 컵떡볶이에 삶은계란 넣어주세요. BHC 콜팝 너무 비싸요.
닭다리보다 닭가슴살이 좋은데 닭껍질은 싫어요~ 컵떡볶이 얘기가 나와서 콜팝 얘기도 함 순대는 소금
시스템 아키텍처 DB분리를 위한 자료리서칭
정의했던거
데이터베이스 네이밍컨벤션
공통 규칙 : 모두 소문자, snake_case를 활용합니다.
테이블 이름 명명 규칙 : 단수
primary key = [tablename]_id
foreign key = [ref_column_name]
계정관리를 어떻게 할래요 ?? 구글로 로그인하던 네이버로 로그인하던 하나의 계정에 접속하도록 하는게 맞을까요? 아니면 구글로 로그인하면 구글에 할당된 아무개의 계정이고 네이버로 로그인하면 네이버로 할당된 아무개의 계정이 맞을까요???
1번안. 나중에 생각해보면 전화번호인증이나, 개인식별번호인증이나, 계좌인증이나 어찌됬건 한사람은 한 아이디로 거래를 하게될 거라고 생각하는데 그럴거면 어떤 인증기관을 이용하던 하나의 계정으로 해야하는게 맞지 않아요??? 근데 그럴러면 네이버랑 깃허브랑 둘다 확인할 수 있는 하나의 ID가 있어야되요 예를들면 전화번호나 개인식별번호로 ...
2번안. 네이버면 네이버아이디로 하게끔하고 깃허브면 깃허브아이디로 하게끔 해요 걍
3번안. 그냥 소셜로그인을 하나로만 하죠 일단은
회의결과 : 개발의 난이도를 낮추고 중요한 것에 포커스를 맞추기 위해서 3번안으로 결정했습니다. -> 깃허브 로그인으로 하는걸로(?) 어제 들었던 밋업이 깨우침을 줘써요
배경 : 거래 내역은 데이터가 쌓이는 속도가 매우 빠를 것이고 RDBMS의 확장성은 제한되있기 때문에 문제가 발생할 것이다.
1번안. 거래내역은 MongoDB를 활용하기로...
회의결과 : 히스토리는 종목별로 정리될 수 있을 것이라 예상 DocumentDB를 쓰고 종목별 Document에 history가 기록.
배경 : 모든 거래 데이터를 가공해서 그래프를 그린다면(1분 캔들, 5분 캔들, 15분 캔들, 30분 캔들, 60분 캔들) 데이터가 수정될 때마다 그래프를 그리기 위해서 데이터를 가공하는 부하가 과도할 것이다.
1번안. 모든 거래 데이터를 이용해서 캔들 기준에 따라서 가공해야한다.
2번안. 캔들별로 데이터를 저장해야 한다.
회의결과 : 이거는 설계의 문제라고 보는데 데이터베이스 확장이 큰 부담이 없고 프로세스 성능 확장이 큰 부담이 있을 것이라고 예상됩니다. 고로 데이터를 저장해서 꺼내먹는걸로 합시다.
배경 : 1분 캔들, 5분 캔들, 15분 캔들, 30분 캔들, 60분 캔들 다 각각 저장할까요?? (논의주제 1번 확장)
1번안. 각각 캔들 요청 시마다 1분 캔들 이용해서 가공합시다.(만약 15분 캔들일 경우 1분 캔들 0분~14분 범위로 가져와서 가공)
2번안. 캔들 뿌려줄 일이 많을텐데 데이터베이스 커지는건 신경쓰지말고 15분마다, 30분마다, 50분마다 캔들 생성하고 데이터베이스에 기록한 다음 요청올 때마다 빠른 응답 합시다.
회의결과 : 우선 1번으로 해봅시다. 시간이 되면 비교해보구요.
배경 : 현재시각이 13분일 때 15분 캔들을 그리기 위한 방법에 대한 논의 매수, 매도가 발생할 때마다 현재 시간을 기록하는 로우를 직접 수정하면서 READ -> 편집 -> UPDATE가 반복적으로 수행될 경우 데이터베이스에 오버헤드가 발생할 것이다.
1번안. 인메모리 디비가 현재 시간에 해당하는 그래프정보를 관리하도록 한다.
- 장점 : 빠르다.
- 단점 : 터지면 큰일이다. (히스토리는 기록되고 있어서 괜찮을지도)
- 확인과제 : 인메모리 디비의 장애복구능력을 확인해보고 싶은데요... 어케확인해요???
2번안. 각각의 인스턴스가 현재 시간에 해당하는 그래프정보를 관리하도록 한다.
- 문제점 : 여러 인스턴스일 경우 모든 인스턴스에 각각 매수 매도 내용을 전달할 건가요??
- 그러면 인스턴스별로 데이터를 수신하지 못한 인스턴스, 수신한 인스턴스가 다른 값을 반환할 것 같은데...
3번안. 중요한 데이터이니만큼 데이터베이스에서 현재 시간에 해당하는 그래프정보를 관리하도록 한다.
- 문제점 : (종목 수 * 캔들 종류)만큼의 쿼리가 틱마다 발생하나요??
- 확인과제 : mysql의 프로시져, 트리거 역할을 하는 mongoDB의 기능을 파악해보아야 한다.
회의결과 : 프로시져, 트리거 역할을 하는 mongoDB의 기능을 파악해보고 3번안으로 진행해볼 계획.
(출처 - 삼성증권)
시작가, 종가, 최고가, 최저가, 시간