느슨한 실시간성을 만족해야하는 대시보드 구현에 대한 조언을 구합니다.

Question

느슨한 실시간성(가급적 빨리)을 만족해야하는 대시보드가 있습니다다수 테이블에 접근다수 통계 쿼리소수 인원만 사용느슨한 실시간성(1~2초)을 만족 사실 기존 구현에서는...많은 고민이 없이 대시보드 특성상 많은 통계쿼리가 발생한다는 이유로 가급적 통계쿼리를 적게 수행하도록, 웹브라우져 상에서 20초 주기로 서버에 요청을 반복하고 서버에서 통계쿼리 들을 수행한 결과 값을 돌려주는식이였습니다. 이로인해 대시보드는 평균적으로 10초의 늦은 반응성을 보였습니다 다시 구현해야하는 위와 같은 새 요구사항에서는... 20초가 아니라 가급적 빠른 1~2초의 느슨한 실시간성을 보여줘야합니다. 이에 구현상 몇가지 예상되는 이슈가 있는데 조언 부탁드립니다. 통계 쿼리 특성상 다수 테이블에 접근하며, 이에 따라 데드락(교착상태)가 발생하지 않을까 라고 부정확하게 추측하고 있습니다, 실제로 발생 가능성이 있다면 해당 커넥션에 대해서만 격리레벨을 낮추면 이를 최대한 피할 수 있을까요?통계 쿼리 특성상 실행에 부하가 많을테고, 가급적 데이터의 변동이 있을때에만 관련 통계쿼리를 새로 수행하고 싶습니다. 테이블의 데이터 변동을 지속적으로 추적해야 할텐데, 어떤 방법이 있을까요?새로운 대시보드 데이터가 발생했을시, 업데이트를 위해 웹브라우져로 랜더링할 데이터를 보내줘야 할텐데, 웹브라우져에서 서버로 단순히 1초 주기로 새로운 데이터가 존재하는지 질의를 하도록 하면 부하가 클까요? 아니면 웹소켓으로 하는게 나을까요? 많은 조언 부탁드립니다.

yeori · Answer

모릅니다.- 데이터가 쌓이는 규모(초당 몇건?)를 모름- 통계 데이터의 지역성을 모름(이를테면 3주전 , 심지어 2년전 데이터를 조회하는 경우가 있는지 최근 1일 또는 3시간 데이터만 필요한지 등)- 스키마도 모름(인덱스를 걸어서 속도가 개선될 수 있는지 모름. 통계용 테이블을 쓰고 있는지 모름)- 업무를 모름(&#34;데이터의 변동이 있을때에만&#34; 이라고 하셨는데, 여기서의 변동이 기존에 쌓인 데이터가 수정되는 것인지, 계속 새로 쌓이는 것인지)제 3자들은 모릅니다

Dive_Drink_Develope · Answer

1. 통계데이터가 업데이트 되는 별도 테이블을 생성하고 조회만 한다. 2. 추적 테이블 데이터 변동시 통계 테이블을 업데이트한다 (trigger) (트리거링 되는 조건의 발생빈도에 따라 통계테이블 통계 결과물을 쌓을지 통계 기반데이터를 쌓을지 결정) 2.1. 지속적으로 통계테이블을 Select해서 변동을 감지하거나 통계테이블이 무거우면 별도의 데이터 변동 관련 플래그테이블을 생성한다.(Polling) / 2.2. Polling 방식이 구리면 약간의 보안을 희생해서 트리거에서 외부프로시저를 실행하도록 한다. / 구글 검색어 db trigger call url 3. SSE로 이벤트를 전송한다. Server Sent Event (SSE) - https://spoqa.github.io/2014/01/20/sse.html SSE 저도 얼마전에 봤는데 완전 신박합니다. ㅎㅎ

느슨한 실시간성을 만족해야하는 대시보드 구현에 대한 조언을 구합니다.

2개의 답변

Q&A 목록