인프런 커뮤니티 질문&답변
작성한 질문수
인덱스 및 DB 질문
해결된 질문
작성
·
24
·
수정됨
0
안녕하세요. 항상 영상 잘 시청하고 있습니다.
이번에 강의를 시청과 실무에서 업무를 하면서 궁금한 사항이 있어서 질문을 작성합니다.
실무에서 인덱스 및 DB에 대해서 최근에 고민이 있습니다. 하나의 테이블에 어쩔 수 없이 컬럼이 많아지는 경우 인덱스가 많아지는 경우가 있어 고민이 됩니다.
물론 상황마다 다르겠지만 강사님의 의견이 궁금하여 질문을 드립니다.
질문
인덱스 : 조회의 다양한 경우가 있어서 인덱스가 과도하게 많아지는 경우가 있습니다.
ex) 복합 인덱스 (A,B,C)가 있다고 가정하면 선행 인덱스가 포함되지 않는 경우에 그냥 인덱스를 추가를 하시는지 궁금합니다. 간단하게 강의에서 post를 기준으로 (title, content)의 인덱스에서 나중에 content만 필터를 해야 되는 경우 ( 실제로 content에 인덱스는 적절하지 않다고 생각하지만 예시 )
1-1. 만약에 추가를 하게 된다면 하나의 Table에 최대 인덱스 개수는 몇개로 지정을 하시는지 궁금합니다. 너무 많아지게 되면 Write작업에 대해서 부화를 가지기 때문에 측정을 하시는 기준점이 있는지 궁금합니다. ( 상황마다 다르겠지만 일반적으로 생각하시는 기준 )
MySQL에서 집계에 대한 아키텍처
하나의 재고를 row로 표현하는 테이블이 있다고 가정하면 특정 상품의 재고를 구하기 위해서 count를 사용을 해야됩니다. (하나의 row는 상품 1개)
캐싱을 처리하면 데이터의 정합성에 문제가 생기고 매번 쿼리를 실행하면 성능 및 DB에 부화가 발생합니다.
이것을 개선하기 위해서 만약에 집계 테이블을 만들어 Redis, Kafka에서 이벤트가 발생하면 집계 테이블에 개수를 수정하는 방식으로 실무에서 많이 사용되는지 궁금합니다.
만약에 많이 사용이 된다면 주의사항이 어떤게 있을까요??
답변 2
0
0
안녕하세요, 인프런 AI 인턴입니다. 퓨퓨님.
인덱스와 데이터베이스 설계에 관한 질문을 주셨네요. 이 주제는 데이터베이스 성능 최적화에서 매우 중요한 부분을 차지합니다. 아래에 각각의 질문에 대한 답변을 드리겠습니다.
인덱스 생성 기준:
복합 인덱스를 사용하는 경우, 선행되는 컬럼이 중요합니다. 예를 들어, 인덱스가
(A, B, C)라면,(A),(A, B),(A, B, C)의 경우에만 옵티마이제이션에서 효과적입니다. 사용하는 쿼리가 인덱스의 선행 컬럼을 포함하지 않는다면 별도의 인덱스를 고려할 수 있습니다. 예로,content만을 자주 조회해야 한다면 별도 인덱스를 추가하는 것이 좋습니다.인덱스 개수: 보편적으로는 테이블 당 인덱스가 5개를 넘지 않도록 설계하는 것이 좋습니다. 이는 쓰기 성능에 부담을 줄 수 있기 때문입니다. 그러나 이것은 단지 가이드라인일 뿐, 실제 상황에 따라 성능 테스트를 통해 최적화해야 합니다.
MySQL에서의 집계 처리:
캐싱 vs. 집계 테이블: 실시간 데이터 처리를 위해 집계 테이블을 사용하는 것도 하나의 방법입니다. 특히 Redis나 Kafka 같은 메시징 시스템을 통해 변경 이벤트를 집계 테이블로 전달하여 실시간으로 업데이트할 수 있습니다.
실사용 및 주의사항: 집계 테이블을 사용하는 경우 데이터의 정합성을 확실히 보장하는 시스템이 필요합니다. 이벤트 수신의 실패나 데이터 중복 등을 처리할 로직이 있어야 하며, TTL(Time To Live) 설정이나 백업 전략 등을 고려해야 합니다. 또한, 가능한 한 최적화된 트랜잭션 크기를 유지하여 데이터 일관성과 성능을 모두 고려해야 합니다.
보다 자세한 실무 경험에 대한 내용은 다음 링크에서 확인해 보세요:
- DB 인덱스 최적화 전략
- MySQL 리얼타임 집계 처리 방법
두 링크 모두 인덱스와 집계에 대한 유용한 정보를 제공합니다. 강의를 통해 배우신 내용들과 함께 참고하시면 실무 적용에 더욱 도움이 되실 것입니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
추가로 답변 드리도록 하겠습니다.
인덱스 : 조회의 다양한 경우가 있어서 인덱스가 과도하게 많아지는 경우가 있습니다.
추가로 인덱스가 너무 많아진다면, 기준점을 어떻게 잡는지가 궁금합니다.
보통은 추가 하지 않습니다. 일단 인덱스를 타지 않지만, 단순히 content만 조회한다고 했을 떄 크게 성능적으로 이슈가 발생하지는 않을꺼같다라는 생각이 들어서요.
그래서 인덱스를 추가 하실 떄에는, 선택도도 비교를 해봐야 하고, content 컬럼의 선택도가 낮다면, 단일 인덱스를 만들어도 성능 이점이 거의 없을 수도 있습니다.
그래서 무조건 추가하는것이 아니라 EXPLAIN을 활용하시면서 확인하시고 추가하는것이 좋습니다.
인덱스 갯수에 대한 기준치는 사실 너무 모호한 부분이 많습니다. 어디까지나 mongoDB 기준이지만, 실제로 50개 이상의 인덱스를 유지하는 경우가 있던 케이스에서도 큰 문제는 없었기 떄문이에요. 그리고 이 상황이라는 것이 사용하지는 MySQL의 성능적인 부분이나, 인스턴스의 사양에 따라 달라지기도 하는 부분이기도 해서요. 그래서 이 부분은 좀 더 명확한 기준이 주어진다면, 그런 경우에 계산을 해보는게 좋지 않을까 싶습니다.
보통적으로 10개 이하로 유지하면 좋다고는 생각하는데, 이는 현재 플랫폼 상태와 스키마 구조에 따라서 너무나도 유동적일 수 있는 부분이라서.. 이 부분에 대해서는 제가 답변이 어려울꺼 같습니다.
MySQL에서 집계에 대한 아키텍처
결과적으로 말씀드리면 매우 좋은 형태라고 생각합니다. 하지만 지금 경험하시는 환경에서 이런 아키텍처를 도입하기에 어떤 기술 부채가 있는지를 보시고 결정하시는것이 좋을겁니다.
음... 이 방식이 저는 개인적으로 굉장히 좋다고 생각을 하는데, 아무래도 추가적인 툴 즉 Kafka, Redis가 추가됨에 따라서 데이터의 일관성이나 유실 문제를 배제할수가 없습니다.
그래서 exactly-once 전략이라던지를 유지하면서, 데이터와 유실 및 중복 문제도 해결해야하고, 멱등성이라는 개념도 공부하시면 좋을 꺼 같습니다.
또한 동시성 이슈도 있을 수가 있겠죠, 여러 트랜잭션에서 동시 수정으로 인한 Race Condition이라던지 아무래도 일반적인 EDA 기반의 아키텍처를 도입하였을 떄, 마주 할 수 잇는 부분들을 주의깊게 보시면 좋을꺼 같습니다.
마지막으로 컨슈머 랙이라는 이슈도 존재 할 수가 있는데, 이는 실제 저장된 메시지와 처리해야 하는 메시지 사이의 갭을 의미하고 쉽게 말해 이벤트 전송량에 비해 처리량이 못따라가는 이슈 입니다. 이런 부분도 고민해 보시면 좋지 않을까 싶습니다.
질문 주셔서 감사합니다 :)