대량의 데이터를 처리할 때 고려할 사항 - 기술 면접 준비

 

면접관 : 대량의 데이터가 쌓이게 되면, 조회가 느려지는데 이때 어떤 조치들을 취할 수 있을까요?

 

 

 

🍼 왕초보

데이터를 너무 많이 넣으면 느려질 수 있으니까, 오래된 데이터는 지우거나, 최근 데이터만 보이도록 하면 됩니다.

 

가능한 추가 질문
1. 오래된 데이터를 지우면 안 되는 경우에는 어떻게 하나요?
2. 최근 데이터만 보이게 하려면 어떤 방법을 써야 하나요?

---

🐣 초보

대형 테이블의 모든 데이터를 조회하면 속도가 느리니까, 필요한 데이터만 조회하는 쿼리를 써야 하고, 인덱스를 사용해서 빠르게 찾을 수 있게 해야 합니다.

 

가능한 추가 질문
1. 인덱스는 언제 어떻게 만들어야 하나요?
2. 모든 컬럼에 인덱스를 걸면 좋은가요?

---

🥉 하수

조회에 자주 쓰는 컬럼 위주로 인덱스를 걸고, 필요한 컬럼만 조회해서 부하를 줄일 수 있습니다. 또한, 파티셔닝(partitioning)이나 아카이빙을 통해 오래된 데이터를 따로 분리할 수도 있습니다.

 

가능한 추가 질문
1. 파티셔닝과 샤딩은 어떻게 다른가요?
2. 캐싱은 어떤 상황에서 유리한가요?

---

🥈 중수

데이터가 많아질 경우, 몇 가지 조치를 취할 수 있습니다.

먼저, 조회에 자주 사용되는 컬럼에 인덱스를 설정해서 검색 속도를 개선할 수 있습니다. 다만, 모든 컬럼에 인덱스를 거는 건 오히려 성능에 악영향을 줄 수 있어 쿼리 패턴에 맞게 선별적으로 걸어야 합니다.

그리고 데이터 양이 많다면 파티셔닝을 통해 테이블을 분할해서 조회 범위를 줄이는 것도 좋은 방법입니다. 예를 들어 날짜 기준으로 나누면 최근 데이터만 빠르게 조회할 수 있습니다.

마지막으로, 자주 조회되는 데이터는 Redis 같은 캐시에 저장해서 DB 부하를 줄일 수 있습니다.

 

가능한 추가 질문
1. 파티셔닝 키는 어떻게 선택하나요? 
2. 캐시의 일관성은 어떻게 유지하나요?

---

🥇 고수

데이터가 대량으로 쌓여 조회가 느려지는 상황에서는 다양한 접근이 필요합니다.

먼저, 인덱스를 쿼리 패턴에 맞게 리디자인하는 것이 중요합니다. 예를 들어, 자주 조회되는 컬럼에 대해서는 커버링 인덱스를 구성하거나, 복합 인덱스(Composite Index)를 활용하여 쿼리를 최적화할 수 있습니다.

그리고 물리적 구조 개선도 고려해야 합니다. 테이블 파티셔닝을 통해 데이터를 시간이나 범위 기준으로 나누거나, 샤딩을 통해 데이터 분산 저장을 할 수 있습니다. 필요한 경우 물리적 뷰(Materialized View)를 사용해 복잡한 쿼리 결과를 미리 저장해둘 수도 있습니다.

또한, 조회 부하를 줄이기 위해 Redis나 Memcached 같은 인메모리 캐시를 적극적으로 활용합니다. 자주 조회되는 데이터는 캐시를 통해 빠르게 제공하고, TTL 등을 이용해 유효성을 관리합니다.

마지막으로, 쿼리 최적화도 중요합니다. EXPLAIN 명령으로 쿼리 실행 계획을 분석하거나, JPA를 사용하는 경우에는 N+1 문제를 방지하고 Lazy vs Eager Loading 전략을 잘 구분해 적용해야 합니다.

 

가능한 추가 질문
1. 샤딩 키를 잘못 잡았을 때 발생할 수 있는 문제는 무엇인가요? 
2. Redis 캐시 무효화 전략에는 어떤 것들이 있나요?

---

🧙 고인물

데이터가 대량으로 쌓이면서 조회 성능이 저하될 경우 단순한 인덱싱이나 파티셔닝 이상의 아키텍처적 접근이 필요합니다.

먼저, 비즈니스 특성에 맞는 시스템 분리가 핵심인데요. 예를 들어, 조회가 많은 서비스라면 OLTP와 OLAP을 분리하거나, 더 나아가 CQRS 패턴을 도입해 조회와 쓰기 모델을 독립적으로 운영할 수 있습니다.

또한 데이터 수명주기를 기준으로 한 저장 전략도 중요합니다. 자주 조회되는 데이터는 핫 데이터, 그렇지 않은 데이터는 콜드 데이터로 구분하고, 이를 기반으로 TTL 설정이나 Time Series DB를 활용할 수 있습니다.

인프라 단에서의 최적화도 고려합니다. 예를 들어, 디스크 IOPS 병목이 발생하는 경우에는 디스크 블록 크기, MySQL InnoDB 인덱스 페이지 구조 등까지 내려가서 설계합니다. 분산 트레이싱 도구를 사용해 병목 구간을 추적하고 리소스 재분배를 통해 최적화합니다.

마지막으로, 조회 자체를 줄이는 UX 레벨 전략도 병행합니다. 예를 들어, 사용자가 모든 데이터를 한 번에 보지 않아도 된다면, progressive rendering이나 background loading으로 체감 성능을 개선할 수 있습니다.

 

가능한 추가 질문
1. 조회 부하를 줄이기 위한 UX 전략에는 어떤 것들이 있나요?
2. CQRS를 도입했을 때 데이터 정합성은 어떻게 보장하나요?

 

 

 

✍️ 키워드 정리

• 인덱스, 커버링 인덱스, 복합 인덱스
• 파티셔닝, 아카이빙, 테이블 분할
• 샤딩, 분산 저장, 캐시, Redis, Memcached, 캐시 무효화 전략
• 쿼리 최적화, Lazy vs Eager Loading
• OLTP와 OLAP 분리, CQRS 패턴
• 디스크 블록 크기, MySQL InnoDB 인덱스 페이지 구조 설계
• 데이터 수명주기를 기준으로 한 저장 전략, 조회 자체를 줄이는 UX 레벨 전략, progressive rendering, background loading
• 물리적 뷰, 병목 구간 추적

 

 

👏

자, 이렇게 대량의 데이터베이스 최적화 관련 면접 질문과 답변 그리고 추가 질문에 대해 다뤄봤습니다!

여러분들은 왕초보 ~ 고인물 중에서 어떤 위치에 속하시나요?

저는 중수 정도 되려나 싶네요... 고인물은 아니에요! 😂

 

평비의 이 평범한 글이 여러분에게 비범한 도움이 되셨으면 좋겠습니다 👍