내가 데베 아직 공부는 시작안했는데

업무하다보니까

db캐쉬가 ㅈㄴ 중요해

이게 뭐 row cache 정도는 디비엔진들이 자체적으로 하는걸로 알고있지만

그것보다는 query cache가 필요하고

더 나아가서

원본테이블들을 통한 select 자체가 transient table인데

이 테이블 자체를 persist하고 계속 반응형형식으로 연동을 시키고 싶다고


그리고 이 연동이

persist될것이냐 => xtdb
persist 되지 않고 최신데이터의 캐쉬이냐 => redis 로 나뉘어


이런 반응형적인 관점은

oltp보단 olap쪽이야

데이터를 가공하는데 시간이 드는데
해당 가공결과물이 계속쓰이니

가공된 데이터를

persist하거나
cache하자는 개념

즉 olap특화


여기에 이렇게 반응형으로 변경된 항목이 역으로 카프카나 웹소켓으로 발송되어야하거든?

웹소켓은 보안이슈가 있으니

결국은 카프카야


유저가 화면ㅇㅔ 인풋을 주면
그게 반응형으로 동기화가 이뤄지고

결과론적으론

다른유저의 화면에 출력이 나가는

그런 구조



근데 이렇게되면

OLTP적인 큰 손실을 입어



여기서 내가 택한방식은

헤테로한 복제야


즉

OLTP서비스는 포스트그레스를 사용해

그리고 싱크로나이저한테 이벤트디스패칭하고 빠르게 persist완료해

어차피 OLAP쪽은 이벤트를 늦게봐도 되거든

그러면 결국 포스트그레스쪽의 변경이 XTDB(혹은 Redis 혹은 Firebase 실시간 디비)쪽으로 넘어가고

그렇게 넘어간게 OLAP쪽 반응형으로 이어지는 연쇄체인



결국

인풋 OLTP OLAP 아웃풋

구조로 엮는거라고



자 그런데 이거 확장이 가능하지


일단

초고성능의 레디스
반응형 로직최적화의 XTDB(특히 쿼리복잡도를 위해선 XTDB가 레디스보다 더 디폴트로 박힘)
OLTP담당의 포스트그레  (몽고디비도 생각중)

자 여기까진 좋아

얘네 셋 헤테로복제 해


근데 한가지 더 남았지.


빅데이터


여기에 hdfs랑 하이브까지 OLAP로


즉


OLTP는 포스트그레에 맡겨서 게이트웨이로 쓰고

싱크로나이저는 아마 카프카 중앙집권으로 만들고

OLAP는

일상의 XTDB
미시의 Redis
거시의 Hive 박아


자

불만있냐?




지금 고작

테이블 하나 만들자고

아키텍처가 ㅈㄴ 쌓였어

이걸 이제 컨테이너화하고 클러스터화하는건 머리아프긴한데

그걸 떠나서


나 거시가 약해

hdfs는 부족하냐?


근데 hdfs단점이 변경에 약하다는건데

이것도 oltp olap 분할 헤테로구조로 ㅈㄴ ㅇㅇㅇ 6문이면 떡을치는거 아님?


나 디비공부 1도없이 직관 대단하지?