대량 데이터 조회와 유지보수는 어떻게 해야될까?

[Hyune-c]

• Layered Architecture Deep Dive
• 초식 - 서버 성능 올리기 (처리량, 응답시간)

[102092]

최범균님 유투브 보시는군요..
저도 보고 있습니다 👍

[kyupid]

최범균님의 TDD 시작하기 얼마전에 구매해서 보구 있어요 ㅎㅎ

[102092]

대부분 조회 로직이 영속성 레이어에 집중되어 있음.

영속성 레이어가 어느 부분을 이야기 하는 건가요?
쿼리가 xml 파일로.. 관리된다는 뜻일까요?

[Hyune-c]

저희는 jooq를 사용하고 있는데, 그곳에 대부분의 로직이 들어가있습니다.
그래서 type safe 정도는 보장됩니다.

만약 업무 로직이 xml이나 mybatis로 관리된다고 생각하면 끔찍하군요..

[102092]

jooq!
저도 요즘 찾아보고 있습니다.
혹시 사용하시면서 느끼는 장단점 간단하게 알려주실 수 있나요?

저희 특정 서비스의 경우 mybatis로 관리되고 있어서, 추후에 jooq로 전환하면 어떨까 생각중에 있어요

[Hyune-c]

jooq 장점

• SQL 위주로 구성되어있던 레거시를 업그레이드하는데 용이하다.
• 타입 세이프 하다.
• mybatis를 쓰던 환경이라면 학습 난이도가 낮다.

jooq 단점

• querydsl의 QClass처럼 빌드해야 되는 과정이 필요하다.
• querydsl도 쓰는데 jooq를 또 써야되나..?

개인적으로는 타입세이프하면서도 코딩 편의성이 높은 querydsl을 좋아합니다.

[102092]

ETL..?

ETL은 어떤걸 말씀하시는거에요?
비정기적인 집계작업 데이터만을 보존하는 데이터베이스 같은 느낌인가요?
그렇다면 redis 같은 타입의 서버를 이용하시는 것도 생각해보셨나요?

대용량 조회는 D-2..

이런 업무적 합의는 꼭 필요한듯 싶네요
좋은 포인트인듯 싶습니다.

[Hyune-c]

ETL

추출(Extract), 변환(Transform), 적재(Load) 한다는 뜻인데, 실 예를 하나 들어보자면

• 모든 결제 정보가 들어있는 테이블이 있다.
• 관리자는 주로 모든 결제 정보가 아닌 카드사별로 조회하고 싶다.
  • 하지만 지금의 구성으로는 항상 모든 테이블을 조회해야되서 속도가 너무 느리다.
  • 인덱스를 써도 느리다.
    • 모수 자체가 너무 많고, 전체 모수 대비 카드사의 종류가 너무 적어 충분한 데이터 필터링이 힘들다.
• 따라서 카드사별로 별도의 테이블을 만들고 시배치 등을 이용해서 분리한다.

---

• 이것은 하나의 DB에서 하는 작업으로 index나 view 등으로 해결할 수도 있다고 생각할 수 있습니다.
  • 하지만 이 니즈는 꽤나 크고 반복되는 것이며, 어드민이 아니더라도 B2B에서는 필요할 수도 있는 대용량 조회입니다.
  • 따라서 기존 서비스에 영향이 가지 않기 위해 리소스를 물리적으로 분리하는 것이 권장됩니다.
• 과거 RDB 흐름에서는 파티셔닝/샤딩 개념으로 접근하였고, 현대에는 NoSQL 또는 ETL/Datawarehouse 도입으로 접근하고 있습니다.
  • 대표적으로는 AWS Athena, Redshift 등이 있습니다.
  • 또한 이렇게 ETL/Datawarehouse를 도입하면, 비개발자이더라도 쿼리를 다룰 줄 아는 사람이라면 자료를 뽑을 수 있고 머신 러닝을 위한 기초 데이터가 되기도 합니다.
    가끔 시니어 마케터나 기획자가 요구하기도 하는 이유입니다.

---

Redis는 비용이 매우 비싸기에 비정형적이고 한시적인 저장에만 사용을 권장합니다.
따라서 이 업무 성격에는 맞지 않다고 판단했습니다.

[102092]

현대에는 NoSQL 또는 ETL/Datawarehouse 도입으로 접근하고 있습니다

그렇군요.

알려주신 부분에 대해 읽다보니 정산등의 서비스에 해당 데이터베이스를 사용하면 좋겠다는 생각이 드네요.
좋은 인사이트 감사합니다.

[Hyune-c]

ETL/Data warehouse를 혼용해서 사용하고 있었어서 좀 더 명시적으로 바꾸었습니다.