ShootForTheMoon

[CS 스터디] 5주간의 데이터베이스 스터디 회고

Lea Hwang — Mon, 3 Feb 2025 20:00:49 +0900

JSCODE 모의면접 신청 계기

1월은 나태해지기 쉬운 시기라 생각한다. 혼자 CS 공부를 한다고 했지만, 흐지부지될 가능성이 있어 모의면접 스터디를 신청하게 되었다. 특히 데이터베이스 관련 공부를 하고 프로젝트에 적용하고 있는 중이었어서 더 심화된 부분을 학습하고 싶었다.

또한, 글로 된 지식에서 벗어나 상대방에게 말로 전달하는 능력도 기르고 싶었다.

스터디 진행 방식

매주 1번 비대면으로 만나서 4명이서 진행하였다. 1명은 면접자 2명은 면접관 1명은 타임키퍼였다. 15분 동안 질문과 답변을 진행하고 5분 동안은 피드백을 하면서 잘한 점과 개선할 점을 정리해서 공유하였다.

기본 개념과 꼬리질문을 정리한 후 발표하는 시간을 가졌다

잘한 점

스터디에 한 번도 빠지지 않고 참여했다. 스터디 시간이 늦은 저녁이라 피곤도 하고 내용 자체가 적지 않았기에 하루 정도는 쉴까라는 생각도 하고 대충할까라는 생각도 했지만 그래도 하는 김에 완벽히 하고 싶었던 것 같다. 처음 스터디를 신청할 때의 마음가짐을 잊지 않고 5주간 임한 점을 스스로 칭찬하고 싶다.

아쉬운 점

질문을 더 많이할걸 후회가 남는다. 물론 내가 가장 많이 질문했지만 그럼에도 더 많이 연구하고 실험하고 궁금한 부분을 질문드릴 걸 하는 아쉬움이 있다.

앞으로는 이렇게

어느정도 이론적인 깊이는 쌓였다고 생각한다. 하지만 요즘 혼자 있고 작업하는 시간이 많아서 그런지 한국말을 하는 데 어려움이 있다. 말로 상대방을 설득시키는 역량도 향상하고 싶다고 느낀다. 그래서 바로 이어서 통화로 매일 모의 면접을 진행하는 스터디에 신청했는데, ... 아직 결과는 나오지 않았다. 예전에 전화영어를 몇 달한 적이 있는데 매일 말을 하니까 술술 나왔던 좋은 경험이 있어 기대를 하고 있다.

잘한 점, 아쉬운 점, 개선점이 보이는 스터디였다. 이 또한 내가 노력한 결과라고 생각한다. 앞으로도 부족한 점을 보완하면서 성장하는 개발자가 되고 싶다!

1:1 채팅 기능 개선 (feat. NoSQL 및 비동기 로직 적용)

Lea Hwang — Fri, 6 Dec 2024 16:06:11 +0900

프론트엔드와 함께하는 프로젝트에서 1:1 채팅 기능 개발을 맡았다. 기본 기능을 구현한 후, 남은 3일 동안 가능한 리팩토링 방안을 고민했고, 최종적으로 데이터베이스를 RDBMS에서 NoSQL로 변경하고(채팅 저장, 조회) 추가적으로 채팅 저장 로직을 비동기로 전환하기로 결정했다. 아래는 개선 과정에서 고려했던 주요 사항들을 기록으로 남겨보려 한다. 부족한 부분이 있겠지만 기한안에 완성을 목표로 했다.

채팅 설계

조건

• 응답 시간이 낮은 1:1 채팅

• 텍스트만 주고 받을 수 있음

• 채팅 이력은 영원히 보관 → 아카이빙

웹소켓 연결(양방향)

• 처음에는 HTTP 연결이지만 특정 핸드셰이크 절차를 거쳐 웹 소켓 연결로 업그레이드된다

• 연결 후에는 서버는 클라이언트에게 비동기적으로 메시지를 전송할 수 있다

• 상태 유지가 필요하다

- 각 클라이언트가 채팅 서버와 독립적인 네트워크 연결을 유지해야 한다

- 클라이언트는 보통 서버가 살아있는 한 다른 서버로 연결을 변경하지 않는다

추가로 확인 할 부분

트래픽 규모가 얼마 되지 않을 때는 모든 기능을 서버 한 대로 구현할 수 있다. 그렇다면 서버 한 대로 얼마나 많은 접속을 동시에 허용할 수 있는지는 모니터링이 필요하다

저장소 (MySQL → MongoDB → 아카이빙)

어떤 데이터베이스를 쓸 것인가?

데이터의 유형과 읽기/쓰기 연산의 패턴을 고려하여 결정한다

채팅 시스템에서 다루는 데이터는 크게 두 가지이다

(1) 사용자 프로파일, 설정, 친구 목록과 같은 일반적인 데이터는 → 안정성을 보장하는 관계형 데이터베이스에 보관한다.

(2) 채팅 이력(읽기/쓰기 연산 패턴)

• 페이스북이나 왓츠앱은 매일 600억 개의 메시지를 처리

• 주로 최근에 주고받은 메시지를 사용

• 하지만 검색이나 특정 메시지로 점프하는 경우도 데이터 계층에서 지원해야 한다

• 1:1 채팅 앱의 경우 읽기:쓰기 비율은 대략 1:1

⇒ 이러한 이유로 키-값 저장소로 변경하였다.

AS-IS : MySQL

TO-BE : 키-값 저장소로 변경(MongoDB)

• 수평적 규모 확장이 쉽다

• 데이터 접근 지연시간이 낮다

• 관계형 데이터베이스는 인덱스가 커지면 데이터에 대한 무작위 접근을 처리하는 비용이 늘어난다
• 많은 안정적인 채팅 서비스가 키-값 저장소를 쓰고 있다

메시지 데이터를 어떻게 보관할 것인가?

메시지 ID는 고유하고 시간 순서와 일치해야 한다

• RDBMS는 auto_increment가 대안

• 하지만, NoSQL은 보통 해당 기능을 제공하지 않음

- 지역적 순서 번호 생성기

- 지역적이라 함은 ID의 유일성은 같은 그룹 안에서만 보증하면 충분

- 왜 나면, 1:1 채팅 세션 안에서만 유지하면 되니까

➡️ 채팅 세션 내 유일성을 보장하기 위해 chatRoomId_sendTime 복합 인덱스 적용

db.chat_messages.getIndexes()

[
  {
    "key": {
      "_id": 1
    },
    "name": "_id_",
    "v": 2
  },
  {
    "key": {
      "chatRoomId": 1,
      "sendTime": -1
    },
    "name": "chatRoomId_sendTime_idx",
    "v": 2
  }
]

마지막은, 아카이빙

모든 데이터를 메모리에 해시 테이블 O(1)로 저장한다고 해도 메모리 최적화가 여전히 필요하다. 다음과 같은 개선 방법이 있다.

• 데이터 압축(compression)

• 특정 시점이 지난 데이터는 디스크나 AWS 별도의 스토리지로 아카이빙

동기 → 비동기

AS-IS : 동기

웹소켓을 통해 채팅 메시지를 받을 때마다 동기적으로 데이터베이스에 저장

성능 테스트는 H2 대신 MySQL을 사용해 진행했습니다.
(H2는 메모리 기반이라 정확성이 떨어질 수 있어, 로컬 환경에서 MySQL을 적용해 테스트를 진행함)

TO-BE : 비동기

• 스프링 이벤트

• 외부 브로커

- Kafka

- RabbitMQ

스프링 이벤트

스프링 애플리케이션에서 이벤트를 발행/구독할 수 있는 기능, 메시지 무손실을 보장하지 않고, 확장성에 제한적이나 특별한 설정이 없는 간편함

• ApplicationEventPublisher

• EventListener

외부 브로커(메시지 큐)

생산자 또는 발행자(producer / publisher)라고 불리는 입력 서비스가 메시지를 만들어 메시지 큐에 발행(publish)한다. 큐에는 보통 소비자 혹은 구독자(consumer / subscriber)라 불리는 서비스 혹은 서버가 연결되어 있는데, 메시지를 받아 동작을 수행한다.

특징

• 메시지의 무손실(durability)

- 메시지 큐에 일단 보관된 메시지는 소비자가 꺼낼 때까지 안전히 보관된다는 특성

• 비동기 통신 지원

- 메시지의 버퍼 역할을 하면서 비동기적으로 전송

장점

• 서비스 또는 서버 간 결합이 느슨해져 규모 확장성이 보장되어야 하는 애플리케이션 구성에 좋다

• 생산자는 소비자 프로세스가 다운되어 있어도 메시지를 발행할 수 있고

• 소비자는 생산자 서비스가 가용한 상태가 아니더라도 메시지를 수신할 수 있다

스프링 이벤트를 선택한 이유

현재는 모놀리식 구조이기 때문이다. 외부 브로커(예: Kafka, RabbitMQ)를 도입하는 것은 멀티 모듈 환경에서 더 적합하다고 생각하고, 현재 구조에서는 오버 엔지니어링이라고 판단했다.

성능 테스트

확인할 포인트

RDBMS로 메시지 저장(동기), 메세지 조회

NoSQL로 메세지 저장, 조회

이벤트 메세지 저장(비동기)

아틀러리 툴을 사용해 성능 테스트 진행

artillery-load-test-event.yaml

config:
  target: 'http://localhost:8090'  # 테스트 대상 서버 URL
  phases:
    - duration: 10  # 해당 단계의 지속 시간 (초)
      arrivalRate: 5  # 초당 도달하는 가상 사용자 수
      name: Warm up  # 첫 번째 단계 이름 (서버 준비 단계)

    - duration: 10  # 해당 단계의 지속 시간 (초)
      arrivalRate: 20  # 초당 도달하는 가상 사용자 수
      name: Ramp up load  # 두 번째 단계 이름 (부하 증가 단계)

    - duration: 30  # 해당 단계의 지속 시간 (초)
      arrivalRate: 100  # 초당 도달하는 가상 사용자 수
      name: Sustained load  # 세 번째 단계 이름 (지속적인 부하 단계)

    - duration: 10  # 해당 단계의 지속 시간 (초)
      arrivalRate: 20  # 초당 도달하는 가상 사용자 수
      name: End of load  # 네 번째 단계 이름 (부하 종료 단계)

scenarios:
  - name: 'event chatting message load test'  # 시나리오 이름 (채팅 메시지 부하 테스트)
    flow:
      - post:
          url: '/api/v1/chat/1/logs'  # API 호출 URL (채팅 메시지 로그 전송)
          json:
            message: 'event message test'  # 전송할 메시지 내용

사용한 명령어

artillery run --output report.json artillery-test.yaml
• 성능 테스트를 실행하고, 결과를 report.json 파일에 저장

artillery report report.json --output report.html
• report.json 파일을 기반으로 HTML 형식의 보고서를 생성하여 report.html로 저장

Case 1. RDBMS vs 스프링 이벤트

H2는 메모리 기반이라 정확성이 떨어질 수 있어, 로컬 환경에서 MySQL을 적용해 테스트를 진행

MySQL 메시지 저장(동기)

• 95p: 124ms

• 99p: 211ms

요청의 99%는 211ms이하의 응답 시간을 기록함

⬇️ MySQL적용한 코드

application.yml

spring:
  datasource:
    url: jdbc:mysql://localhost:3306/flowday_dev
    username: [username] 
    password: [password]

ChatApiController

/**
 * 채팅 메세지 저장
 */
@PostMapping("/{roomId}/logs")
public ResponseEntity<ApiResponse> saveMessage(
        @PathVariable Long roomId,
        @AuthenticationPrincipal SecurityUser user,
        @RequestBody ChatMessage chatMessage
) {
    Long senderId = user.getId();
    LocalDateTime time = LocalDateTime.now();
    //String responseMessage = HtmlUtils.htmlEscape(chatMessage.message());

    chatService.saveMessage(roomId, senderId, chatMessage.message(), time);

    return ResponseEntity.ok(ApiResponse.success(chatMessage.message()));
}

이벤트 메세지 저장(비동기)

• 95p: 12ms

• 99p: 75ms

요청의 99%는 75ms이하의 응답 시간을 기록함

스프링 이벤트 (refactor/#78) → PR

https://github.com/prgrms-web-devcourse-final-project/WEB1_2_FlowDay_BE/pull/104

⬇️ 코드

Application

@EnableAsync
@EnableWebSocket
@SpringBootApplication
@EnableJpaAuditing
public class Application {
    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }

}

ChatController

/**
 * 웹 소켓 연결
 */
@MessageMapping("/chat/{roomId}")
@SendTo("/topic/rooms/{roomId}")
public ChatResponse chatting(
        @DestinationVariable Long roomId,
        @AuthenticationPrincipal SecurityUser user,
        ChatMessage chatMessage
) {
    Long senderId = user.getId();
    LocalDateTime time = LocalDateTime.now();
    String responseMessage = HtmlUtils.htmlEscape(chatMessage.message());

    chatService.saveMessage(roomId, senderId, responseMessage, time);
    // 페이지 정보는 웹소켓 연결에서는 의미 없으므로 0으로 설정
    return new ChatResponse(senderId, responseMessage, time, 0, 0);
}

ChatService

@RequiredArgsConstructor
@Transactional(readOnly = true)
@Service
public class ChatService {
    private final ChatMessageRepository chatMessageRepository;
    private final ChatRoomRepository chatRoomRepository;
    private final ApplicationEventPublisher applicationEventPublisher;

    /**
     * [비동기 - 스프링 이벤트] 채팅 메세지 저장
     */
    public void saveMessage(
            final Long roomId,
            final Long senderId,
            final String responseMessage,
            final LocalDateTime time
    ) {
        applicationEventPublisher.publishEvent(
                new ChatMessageEvent(roomId, senderId, responseMessage, time)
        );
    }
}

ChatMessageEvent

public record ChatMessageEvent(
        Long roomId,
        Long senderId,
        String responseMessage,
        LocalDateTime time
) {
}

ChatMessageEventHandler

@RequiredArgsConstructor
@Service
public class ChatMessageEventHandler {
    private final ChatMessageRepository chatMessageRepository;

    @Async
    @TransactionalEventListener
    public void handle(ChatMessageEvent event) {
        ChatMessageEntity chatMessage = ChatMessageEntity.create(
                event.roomId(),
                event.senderId(),
                event.responseMessage(),
                event.time()
        );
        chatMessageRepository.save(chatMessage);
    }
}

성능 개선

스프링 이벤트 메시지 저장(비동기)은 MySQL 메시지 저장(동기) 대비 99%의 요청에서 응답 시간이 136ms (약 64%) 개선되었다.

Case 2. RDBMS → NoSQL

채팅 메시지 저장/조회 RDBMS → NoSQL(MongoDB) 전환

MongoDB 연결 (refactor/#84) - PR 완료

https://github.com/prgrms-web-devcourse-final-project/WEB1_2_FlowDay_BE/pull/103

⬇️ 코드

application.yml

spring:
  data:
    mongodb:
      uri: mongodb://localhost:27017/flowday_chat_db
      auto-index-creation: true

build.gradle

// mongodb
implementation 'org.springframework.boot:spring-boot-starter-data-mongodb'

ChatApiController

 /**
 * [NoSQL] 채팅 메세지 저장
 */
@PostMapping("{roomId}/logs")
public ResponseEntity<ApiResponse> chatting(
        @PathVariable Long roomId,
        @AuthenticationPrincipal SecurityUser user,
        @RequestBody ChatMessage chatMessage
) {
    Long senderId = user.getId();
    LocalDateTime time = LocalDateTime.now();
    String responseMessage = HtmlUtils.htmlEscape(chatMessage.message());

    ChatMessageDocument chatMessageDocument =
            chatService.saveMessage(roomId, senderId, responseMessage, time);
    return ResponseEntity.ok(ApiResponse.success(chatMessageDocument));
}

 /**
 * [NoSQL] 채팅 조회 (최신 10개, page)
 */
@GetMapping("/{roomId}")
public ResponseEntity<ApiResponse> getPagedChatMessages(
        @PathVariable Long roomId,
        @RequestParam(value = "page", defaultValue = "1") int page,
        @RequestParam(value = "size", defaultValue = "10") int size
) {
    Pageable pageable = PageRequest.of(page - 1, size, Sort.by(Sort.Direction.DESC, "sendTime"));
    Page<ChatMessageDocument> messages = chatService.getPagedChatMessages(roomId, pageable);

    int pageNumber = messages.getNumber() + 1;
    List<ChatResponse> chatResponses = messages.getContent().stream()
            .map(message -> ChatResponse.from(message, pageNumber, messages.getTotalPages()))
            .toList();
    return ResponseEntity.ok(ApiResponse.success(chatResponses));
}

ChatService

private final ChatMessageDocumentRepository chatMessageDocumentRepository;

/**
 * [NoSQL] 채팅 메세지 저장
 */
public ChatMessageDocument saveMessage(
        final Long roomId,
        final Long senderId,
        final String responseMessage,
        final LocalDateTime time
) {
    ChatMessageDocument chatMessageDocument = ChatMessageDocument.create(
            roomId,
            senderId,
            responseMessage,
            time
    );
    return chatMessageDocumentRepository.save(chatMessageDocument);
}

/**
 * [NoSQL] 채팅 조회
 */
public Page<ChatMessageDocument> getPagedChatMessages(
        final Long roomId,
        final Pageable pageable
) {
    return chatMessageDocumentRepository.findByChatRoomId(roomId, pageable);
}

ChatResponse

public record ChatResponse(
        Long senderId,
        String message,
        LocalDateTime time,
        Integer pageNumber,  // 현재 페이지 번호
        Integer totalPages   // 총 페이지 수
) {
    public static ChatResponse from(
            final ChatMessageDocument chatMessageDocument,
            Integer pageNumber,
            Integer totalPages
    ) {
        return new ChatResponse(
                chatMessageDocument.getFromId(),
                chatMessageDocument.getTextMessage(),
                chatMessageDocument.getSendTime(),
                pageNumber,
                totalPages
        );
    }
}

ChatMessgeDocument

@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Getter
@Document(collection = ChatMessageDocument.COLLECTION_NAME)
@CompoundIndexes({
        @CompoundIndex(name = "chatRoomId_sendTime_idx", def = "{'chatRoomId': 1, 'sendTime': -1}")
})
public class ChatMessageDocument {
    public static final String COLLECTION_NAME = "chat_messages";

    @Id
    private ObjectId id;
    private Long chatRoomId;
    private Long fromId;
    private String textMessage;
    private LocalDateTime sendTime;

    @Builder
    public ChatMessageDocument(
            final ObjectId id,
            final Long chatRoomId,
            final Long fromId,
            final String textMessage,
            final LocalDateTime sendTime
    ) {
        this.id = id;
        this.chatRoomId = chatRoomId;
        this.fromId = fromId;
        this.textMessage = textMessage;
        this.sendTime = sendTime;
    }

    public static ChatMessageDocument create(
            final Long chatRoomId,
            final Long fromId,
            final String textMessage,
            final LocalDateTime sendTime
    ) {
        return ChatMessageDocument.builder()
                .chatRoomId(chatRoomId)
                .fromId(fromId)
                .textMessage(textMessage)
                .sendTime(sendTime)
                .build();
    }
}

ChatMessageDocumentRepository

public interface ChatMessageDocumentRepository extends MongoRepository<ChatMessageDocument, ObjectId> {
    Page<ChatMessageDocument> findByChatRoomId(Long chatRoomId, Pageable pageable);
}

docker-compose.yml

version: '3.8'
services:
  mongodb:
    image: mongo:6.0.3
    container_name: mongodb_container
    volumes:
      - ./db/mongodb/data:/data/db
    ports:
      - "27017:27017"
    networks:
      - flowday
    command: mongod --noauth

networks:
  flowday:

채팅 메세지 저장

채팅 메세지 조회

최종 확인 (스프링 이벤트 + NoSQL 적용)

웹소켓 연결 + 채팅 메세지 전송

NoSQL 채팅 메세지 저장

NoSQL 채팅 메세지 조회

참고 :

[도서] 가상 면접 사례로 배우는 대규모 시스템 설계 기초

[CS 스터디] 5주간의 네트워크 스터디 회고

Lea Hwang — Mon, 2 Dec 2024 14:51:19 +0900

JSCODE 모의면접 신청 계기

10월 말쯤 생각을 했을 때 11월 초에는 프로젝트와 이력서, 포트폴리오가 마무리되는 일정이었다. 따라서 11월 한 달 동안은 부족했던 컴퓨터공학 지식을 채우는 데 전념하려 했다. 그 당시 Java, Spring, 운영체제, 네트워크, 자료구조/알고리즘, 데이터베이스 하나씩 나의 지식의 정도를 확인했을 때, 그 중에서 네트워크가 가장 모호하고 개념이 명확하게 잡히지 않는 상태였다. 그래서 한 달 동안은 네트워크에 전념해 전공생과 현직자 분들과 스터디를 함에 있어서 제일 잘하고 싶다는 목표를 세우게 되었다.

스터디 진행 방식

총 5주간 일주일에 한 번 진행했다. 평균적으로 4명이서 진행했고 1명이 면접자, 2명이 면접관, 나머지 한 분이 타임키퍼로 시간을 확인해주셨다. 15분 동안 질문과 답변이 오가고 5분은 세 명이서 면접자의 답변이나 눈동자 위치(?) 잘한 점 아쉬운 점을 솔직하게 말해주는 시간을 가졌다.

잘한 점

1. 나는야 네트워크 마스터가 될거야!

매주 스터디마다 제공된 질문들이 존재했지만, 만족하지 않고 해당 챕터에서 나올 만한 질문 전부를 꼬리질문으로 대비를 하였다. 이는 스터디 발표 때 빛을 발했고 칭찬을 아주 많이 받은 부분이 되었다. 뿌 - 듯

2. 모호한건 질문!

대부분 내가 공부한 내용에서 질문이 나오긴 했지만, 생각할 부분이 있는 질문이 나오면 바로 메모를 한 후 따로 찾아보았다. 그래도 모호하고 확실하게 짚고 넘어가고 싶은 부분이 있으면 정리해서 질문방에 질문을 하였다. 질문을 나밖에 안 해서 조금 쑥스러웠지만 그럼에도 이건 현직 멘토님과 함께하는 좋은 기회라고 생각했기에 최대한 많이 질문하고 얻어가려고 했다.

3. 피드백은 면접자에게 도움이 되는 쪽으로

나는 면접관이나 타임키퍼로 활동을 하면서 질문을 한 후 면접자의 답변 태도, 내용, 표정 전부를 관찰하면서 어떤 점에 강점이 있는지, 개선할 부분이 있는지 꼼꼼하게 확인하고 피드백 시간에 말씀드렸다. 나의 피드백을 들을 사람들은 전부 감사하다고 했고 이는 내가 어떤 식으로 답변을 해야 할지 역으로 도움이 되기도 했다.

4. 내가 제일 잘했다.

물론 에이?! 거짓말..이라고 생각할 수 있다. 하지만 나는 처음부터 네트워크에서 나올 만한 개념과 파생되는 질문과 답변을 전부 정리할 생각이었고 누구보다 열심히 누구보다 잘할 생각으로 임했고 증명했다. 나는 정말 잘했다.

ps. 면접 스터디가 다 끝나고 현직자 분께 추후에 다른 스터디 할 생각 있으면 같이 하자고 제안도 받았고 멘토님께서도 많이 배운다고 말씀하셨다... 정말 어깨가 올라가는 포인트다.

아쉬운 점

1. 5주간 네트워크만 하다니...

한 주의 네트워크 분량을 공부하는데 사실 1.5 ~ 2일 정도밖에 걸리지 않는다. 그렇다면 네트워크뿐만 아니라 다른 과목 하나 정도는 병행이 가능했을 것이다. 물론 다른 프로젝트를 하고는 있지만 그건 핑계고 조금만 더 부지런했다면 가능했을 텐데 아쉬움이 남는다.

2. 없다

나는 최고다

앞으로는 이렇게

저번주에 네트워크 스터디가 끝이 났다. 이번주에는 운영체제, 데이터베이스를 하루에 한 챕터씩 해서 이번주에 끝내는 것을 목표로 한다. 나는 할 수 있다!

[업무에 바로 쓰는 SQL 튜닝] 4.2.6 다수 쿼리를 UNION 연산자로만 합치는 나쁜 SQL문

Lea Hwang — Mon, 7 Oct 2024 21:22:27 +0900

❌ 문제의 SQL 문
실행 계획 살펴보기
⭕ UNION ALL 연산자로 변경해 보자
정리

❌ 문제의 SQL 문

요구사항 : 성이 Baba이면서 성별이 M인 사원 데이터와 성이 Baba이면서 성별이 F인 사원 데이터를 합해서 조회하는 쿼리를 작성해 주세요.

select 성별, 사원번호
    from 사원
    where 성별 = 'M'
        and 성 = 'Baba'

union

select 성별, 사원번호
    from 사원
    where 성별 = 'F'
        and 성 = 'Baba';

수행 결과

+--------+--------------+
| 성별    |    사원번호    |
+--------+--------------+
| M      |        11937 |
| M      |        12245 |
| M      |        15596 |
| M      |        15899 |
					...
| F      |       495777 |
| F      |       496003 |
| F      |       498356 |
| F      |       499779 |
+--------+--------------+
226 rows in set (0.0019 sec)

총 226건으로 소요시간은 0초대이다. 데이터가 많지 않기에 튜닝 결과의 지표로 실행 계획을 포함해서 종합적으로 판단해 보자.

실행 계획 살펴보기

1. id가 1,2인 행은 사원 테이블의 I_성별_성 인덱스를 사용한다.

2. id가 3인 행은 id가 1,2인 행의 결과를 통합한 뒤 중복을 제거하는 작업을 처리한다.

- Extra의 Using temporary를 보면 메모리에 임시테이블을 생성해서 그 내부에서 union 연산 작업을 처리할 것 같다.

- 데이터가 적으면 메모리를 사용하겠지만, 결과량이 많다면 디스크에 임시파일을 생성해 union작업을 수행한다.

여기서는 어떤 게 문제일까?

중복 제거가 필요한 상황인지 확인할 필요가 있다!

문제의 SQL문에서 두 select문은 I_성별_성 인덱스를 활용해 데이터를 조회하므로 이미 중복이 제거된 상태이다. 따라서 추가적으로 임시 테이블을 만들어서 중복을 제거할 필요가 없다.

여러 개의 select문 실행 결과를 합친 후 중복 데이터를 제거하는 작업을 하는 union을 제거하고

단순히 여러 개의 select문 실행 결과를 합치는 union all로 변경해 보자.

⭕ UNION ALL 연산자로 변경해 보자

select 성별, 사원번호
    from 사원
    where 성별 = 'M'
        and 성 = 'Baba'

union all

select 성별, 사원번호
    from 사원
    where 성별 = 'F'
        and 성 = 'Baba';

수행 결과

+--------+--------------+
| 성별    | 사원번호       |
+--------+--------------+
| M      |        11937 |
| M      |        12245 |
| M      |        15596 |
| M      |        15899 |
           ...					
| F      |       495777 |
| F      |       496003 |
| F      |       498356 |
| F      |       499779 |
+--------+--------------+
226 rows in set (0.0016 sec)

총 226건이며, 소요시간은 0초대이다. 데이터가 많지 않기 때문에 소요 시간만으로 튜닝 성공 여부를 판단하기 어려우므로 실행 계획도 함께 살펴보자.

실행 계획 확인

1. id가 1,2인 행은 사원 테이블의 I_성별_성 인덱스를 사용한다.

2. 문제의 SQL문과 달리, id가 1,2인 결과를 단순히 합치므로 세 번째 행을 추가해 중복을 제거할 필요가 없어졌다.

정리

1. 데이터가 많지 않다면 실행계획까지 확인은 필수

2. 어떤 인덱스를 사용하는지 → 효율적인지, 임시 테이블을 사용하는지 → 꼭 필요한 작업인지, 확인

3. 중복을 제거하는 연산자 또는 키워드를 사용한다면, 해당 쿼리에서 중복 제거 작업이 중복인지 확인

출처 : [도서] 업무에 바로 쓰는 SQL 튜닝

[업무에 바로 쓰는 SQL 튜닝] 4.2.5 습관적으로 중복을 제거하는 나쁜 SQL 문

Lea Hwang — Fri, 4 Oct 2024 12:52:33 +0900

❌ 문제의 SQL 문
실행 계획 살펴보기
⭕ DISTINCT 키워드를 제거해 보자
정리

❌ 문제의 SQL 문

요구사항 : 사원의 사원번호, 이름, 성, 그리고 부서 관리자의 부서번호를 중복 없이 조회하는 쿼리를 작성해 주세요.

select
    distinct 사원.사원번호,
    사원.이름,
    사원.성,
    부서관리자.부서번호
from 사원
join 부서관리자 on (사원.사원번호 = 부서관리자.사원번호);

수행 결과

총 24건이며 소요 시간은 0초에 가깝게 나왔다.

실행 계획 살펴보기

1. id 값이 둘 다 1이므로 서로 조인하고 있다.

2. 부서관리자 테이블의 type이 index로 인덱스 풀 스캔을 하고 있다.

3. 사원 테이블의 type은 eq_ref으로 사원번호(PK)를 사용해 1건의 데이터를 조회하는 효율적인 방식을 사용하고 있다.

4. DISTINCT를 수행하기 위해 별도의 임시 테이블 Using temporary을 만들고 있다.

그럼, 어떤 부분이 문제일까?

사원테이블의 기본 키는 사원번호이다. 이 의미는 문제의 SQL문에서 SELECT절에 작성된 사원.사원번호에는 중복데이터가 없다는 뜻이다. 따라서 DISTINCT를 사용해 중복을 제거하는 건 불필요했다.

왜, distinct 키워드 사용이 문제가 될까?

DISTINCT 키워드는 나열된 열들을 정렬한 뒤에 중복 데이터를 삭제한다. 이미 정렬된 데이터가 아니라면 정렬 작업이 부담이 될 수 있다.

⭕ DISTINCT 키워드를 제거해 보자

select
    사원.사원번호,
    사원.이름,
    사원.성,
    부서관리자.부서번호
from 사원
join 부서관리자 on (사원.사원번호 = 부서관리자.사원번호);

이전과 같이 총 24건이고 소요시간은 0초대로 변화가 없기에 소요시간을 기준으로 성능 개선 여부를 판단하기 어렵다. 이번에는 실행 계획을 통해 튜닝이 잘 되었는지 살펴보자.

실행 계획 확인

Extra 항목에서 Using temporary가 삭제되었다. 이는 DISTINCT 키워드를 제거한 것과 관련이 있는데, 임시 테이블을 생성해서 추가적인 정렬과 중복 제거를 하지 않아도 된다.

정리

1. 임시 테이블 Using temporary이 있다면, 어떤 이유로 생성되었는지 확인해서 필요한 작업인지 살펴보자.

2. DISTINCT키워드를 사용할 때에는 중복 제거가 필요한 게 맞는지, 처음부터 중복이 없는 건 아닐지 확인하자!

- 왜? DISTINCT는 내부적으로 임시테이블을 활용하고, 정렬작업을 수행하기 때문에, 필요하지 않다면 사용하지 않는 것이 좋다.

출처 : [도서] 업무에 바로 쓰는 SQL 튜닝

[업무에 바로 쓰는 SQL 튜닝] 4.2.4 열을 결합하여 사용하는 나쁜 SQL 문

Lea Hwang — Wed, 2 Oct 2024 14:29:37 +0900

❌ 문제의 SQL 문
실행 계획 살펴보기
⭕ 열을 결합하는 과정을 제거하고, 열을 분리해 보자
정리

❌ 문제의 SQL 문

요구사항 : 사원 테이블에서 성별의 값과 1칸의 공백, 성의 값을 모두 결합한 결과가 ‘M Radwan’인 데이터를 조회하는 쿼리를 작성해 주세요.

- CONCAT 함수는 여러 문자열을 연결하는 데 사용

SELECT *
    FROM 사원
    WHERE CONCAT(성별, ' ', 성) = 'M Radwan';

출력 :

총 102건이고 소요 시간은 약 0.13초가 나왔다.

실행 계획 살펴보기

사원 테이블에만 접근하여 데이터를 가져오고 있다. 문제의 SQL문에서는 WHERE 조건절로 데이터에 접근하는 반면, 실행계획을 확인해 보니 type 항목이 ALL 테이블 풀 스캔을 하고 있다.

어떤 문제가 있는지, 테이블 인덱스 현황을 살펴보자.

SHOW INDEX FROM 사원;

기본키는 사원번호 열이고, I_입사일자 인덱스는 입사일자 열, I_성별_성 인덱스는 성별 열 + 성 열이다.

그럼 WHERE절에서 I_성별_성 인덱스를 활용해 데이터를 빠르게 조회할 수 있었을 것이다.

불필요하게 열을 결합하는 과정에서 문제가 생긴 것을 확인했다. 열을 분리해서 sql문을 다시 작성해 보자.

⭕ 열을 결합하는 과정을 제거하고, 열을 분리해 보자

SELECT *
    FROM 사원
    WHERE 성별 = 'M'
        AND 성 = 'Radwan';

소요시간이 약 0.13초에서 약 0.01초로 줄어들었다.

실행계획까지 확인해 보자.

I_성별_성 인덱스를 사용해서 테이블에 접근하고 있고, 튜닝 전에는 약 30만 건의 데이터에 접근했다면 튜닝 후에는 102건의 데이터에만 접근한다는 것을 알 수 있다. 그리고 type유형이 ref로 인덱스를 이용해 특정 조건(주로 =)에 맞는 데이터를 찾고 있다.

정리

테이블의 인덱스를 확인하는 습관 덕분에, 이미 설정된 인덱스가 효율적으로 사용되지 않고 있다는 사실을 알게 되었다. 멀티 칼럼 인덱스가 설정되어 있는 상태에서, 해당 열들을 결합한 쿼리문을 작성 시 인덱스가 활용되지 않을 수 있다는 것을 배웠다. 이런 경우에는 열을 나눠서 작성한 후 실행 계획을 확인하여 효율적인 탐색이 이루어지고 있는지 항상 점검해야겠다.

출처 : [도서] 업무에 바로 쓰는 SQL 튜닝

[업무에 바로 쓰는 SQL 튜닝] 4.2.3 형변환으로 인덱스를 활용하지 못하는 나쁜 SQL 문

Lea Hwang — Fri, 13 Sep 2024 10:38:58 +0900

❌ 문제의 SQL 문
실행 계획 살펴보기
⭕ 형변환이 발생하지 않도록 SQL을 수정해 보자
정리

❌ 문제의 SQL 문

요구사항: 급여 테이블에서 현재 유효한 급여 정보만 조회하는 쿼리를 작성해 주세요.

사용여부 열의 값이 1인 데이터가 유효한 급여 정보입니다.

SELECT COUNT(*)
    FROM 급여
    WHERE 사용여부 = 1;

출력:

1건이 출력되었고 데이터는 총 42,842건이며 sql 소요시간은 약 0.48초로 나타났다.

실행 계획 살펴보기

key항목이 I_사용여부로 출력되고, type항목이 index이므로 인덱스 풀 스캔 방식으로 테이블의 데이터를 찾고 있다. 그리고 filtered항목이 10이므로 MySQL엔진으로 가져온 데이터 중 10%를 추출해서 최종 데이터를 출력했다는 것을 알 수 있다.

여기서는 어떤 문제가 있을까? 우선 급여 테이블의 인덱스 현황을 알아볼 필요가 있다.

SHOW INDEX FROM 급여;

사용여부 열이 인덱스로 구성되어 있지만, 인덱스를 효율적으로 활용하지 못하고 인덱스 풀 스캔으로 수행되고 있는 상황이다.

이어서 테이블의 구조를 확인해 보자.

DESC 급여;

사용여부 열은 문자형인 char(1) 데이터 유형이다. 그런데 문제의 SQL문에서는 WHERE 사원번호 = 1과 같이 숫자 유형으로 써서 데이터에 접근했었다. 그럼 DMBS 내부적으로 묵시적 형변환이 발생했을 것이다. 그 결과 I_사용여부 인덱스를 제대로 활용하지 못하고 엔덱스 풀 스캔을 한 것이다!

그럼, 형변환이 발생하지 않도록 SQL을 조정하면 해결할 수 있다.

⭕ 형변환이 발생하지 않도록 SQL을 수정해 보자

SELECT COUNT(*)
    FROM 급여
    WHERE 사용여부 = '1';

sql 소요시간이 기존 약 0.48초에서 약 0.01초로 개선됨을 확인할 수 있다.

실행계획까지 확인해 보자.

key 항목에서 I_사용여부 인덱스를 사용한다는 것을 알 수 있고, type 항목이 ref이므로 인덱스를 통해 특정 조건에 맞는 데이터를 효율적으로 가져온다. 또한, filtered 값이 100이므로 가져온 데이터가 모두 사용되는 것을 알 수 있다.

정리

1. 데이터 유형에 맞게 열을 사용하자!

그래야 내부적인 형변환이 발생되지 않는다. 형변환이 일어나면 인덱스를 제대로 활용하지 못하는 경우가 있음에 주의하자.

2. 실행 계획, 테이블의 인덱스 현황 및 테이블 구조를 함께 확인하면서 개선 가능한 포인트가 있는지 확인하는 습관을 들이자!

[실행 계획]

filtered :
예를 들어 10이라는 의미는 스토리지 엔진에서 MySQL엔진으로 가져온 데이터 중 10%를 추출해서 최종 테이터를 출력하는 것

type: 테이블의 데이터를 어떻게 찾을지
- index : 인덱스 블록을 처음부터 끝까지 훑는 방식으로 인덱스 풀 스캔을 의미함
→ 그다지 효율적이지 않음
- ref : 인덱스를 이용해 특정 조건(주로 =)에 맞는 데이터를 찾는 방식으로, 조인할 때 주로 사용된다 → 원하는 데이터를 빠르게 찾을 수 있어 효율적

[유용한 SQL문]

SHOW INDEX FROM [테이블명];
테이블의 인덱스 현황 확인

DESC [테이블명]; 
테이블의 구조 확인

출처 : [도서] 업무에 바로 쓰는 SQL 튜닝

[업무에 바로 쓰는 SQL 튜닝] 4.2.2 사용하지 않는 함수를 포함하는 나쁜 SQL문

Lea Hwang — Tue, 10 Sep 2024 09:46:32 +0900

❌ 문제의 SQL 문
실행 계획 살펴보기
⭕ 불필요한 IFNULL() 함수를 제거해 보자
정리

❌ 문제의 SQL 문

요구사항 : 사원 테이블에서 성별 기준으로 몇 명의 사원이 있는지 확인하는 쿼리문을 작성해 주세요.

SELECT IFNULL(성별, 'NO DATA') AS 성별, COUNT(*) 건수
    FROM 사원
    GROUP BY IFNULL(성별, 'NO DATA')

만약 성별의 값이 NULL이라면 NO DATA라고 출력할 수 있도록 IFNULL() 함수를 사용하여 구현했다.

2개의 행이 출력되었고, 약 0.12초가 소요되었다.

실행 계획 살펴보기

I_성별_성 인덱스로 인덱스 풀 스캔 방식을 수행하며, Extra 항목이 Using temporary로 임시 테이블을 생성한다는 것을 알 수 있다.

음.. 여기서는 어떤 게 문제일까? 생각해 볼 포인트가 몇 가지가 있다.

1. 성별 열에 M, F 이외의 값이 존재하는가?

2. 성별 열에 NULL을 허용하는가?

1번 확인 : M, F 이외의 값은 들어있지 않다.

2번 확인 : Null 열에 NO라고 명시되어 있으므로 NULL값이 될 수 없다.

DESC 사원;

+--------------+---------------+------+-----+---------+-------+
| Field        | Type          | Null | Key | Default | Extra |
+--------------+---------------+------+-----+---------+-------+
| 사원번호       | int           | NO   | PRI | NULL    |       |
| 생년월일       | date          | NO   |     | NULL    |       |
| 이름          | varchar(14)   | NO   |     | NULL    |       |
| 성           | varchar(16)   | NO   |     | NULL    |       |
| 성별          | enum('M','F') | NO   | MUL | NULL    |       |
| 입사일자       | date          | NO   | MUL | NULL    |       |
+--------------+---------------+------+-----+---------+-------+
6 rows in set (0.0036 sec)

따라서 IFNULL() 함수를 처리하려고 DB 내부에 별도 임시 테이블을 만들 필요가 없음을 확인했다! 불필요한 로직이므로 튜닝 대상이 되겠다.

⭕ 불필요한 IFNULL() 함수를 제거해 보자

소요시간이 약 0.12초에서 약 0.06초로 줄었다.

실행계획까지 확인해 보자

key항목이 I_성별_성 인덱스로 인덱스 풀 스캔 방식으로 수행되며, Extra항목이 Using index로 임시 테이블 없이 인덱스만 사용하는 것을 알 수 있다.

정리

1. 실행 계획에서 확인할 포인트

Extra 항목이 Using temporary이면 임시 테이블을 생성한다는 의미로 하나의 튜닝할 수 있는 포인트가 될 수 있음!

2. 함수를 사용할 때 사용하지 않아도 되는 함수는 아닐까 확인해 볼 것

출처 : [도서] 업무에 바로 쓰는 SQL 튜닝

[업무에 바로 쓰는 SQL 튜닝] 4.2.1 기본키를 변형하는 나쁜 SQL문

Lea Hwang — Sun, 8 Sep 2024 19:07:08 +0900

4장은 문제가 있는 SQL문과 개선된 SQL문을 소개해주고 있다. 팀원과 한 파트씩 나눠서 발표 스터디를 진행하기로 했고, 오늘은 그 첫 번째 사례이다.

나는 도커 컨테이너 하나를 생성하고 안에 실습할 데이터베이스를 미리 넣어두었다. 그랬더니 컨테이너에 접속만 하면 쉽게 실습할 수 있어서 아주 편리했다!

다음은 목차이다. 앞으로도 목차는 비슷하게 흘러갈 예정이다.

❌ 문제의 SQL 문
실행 계획 살펴보기
⭕ 사원번호(기본키)가 인덱스를 타도록 수정해 보자
정리

❌ 문제의 SQL 문

[주의] MySQL에서 문자열의 인덱스는 1부터 시작한다.

요구사항 :

사원번호가 1100으로 시작하면서 사원번호가 5자리인 사원의 정보를 모두 출력해 주세요.

SELECT *
    FROM 사원
    WHERE SUBSTRING(사원번호, 1, 4) = 1100 // 첫번째 자리부터 4번째 자리까지
        AND LENGTH(사원번호) = 5

출력 : 사원 테이블

총 10건의 결과가 출력되고 실습 환경에서 0.12초 소요되었다.

쿼리의 문제점은 없을까?, 더 개선할 포인트가 있지 않을까? 실행 계획을 확인해 보자!

실행 계획 살펴보기

Type 항목이 ALL로 나타나므로 테이블 풀 스캔 방식인 것을 알 수 있다.

인덱스를 사용하지 않고 바로 테이블에 접근하여 필요한 범위가 아닌 처음부터 끝까지 스캔하고 있어 비효율적인 쿼리라 추측할 수 있다.

그럼 사원 테이블의 기본키와 인덱스를 파악해서 세부적인 원인을 알아보도록 하자.

Key_name 열 정보에서 PRIMARY, I_입사일자, I_성별_성이라는 3개 인덱스가 있다.

- 기본키는 사원번호

- I_입사일자 인덱스는 1개의 입사일자로 구성

- I_성별_성 인덱스는 성별과 성 순서대로 구성

그럼 튜닝해야 할 SQL 문은 무엇일까?

여기서 의문이 하나 들어야 한다. ‘문제의 SQL’에서 사원번호 열을 조건문으로 작성했기 때문에 기본키를 통해 특정 범위를 스캔했어야 했는데, 실제로는 왜 풀 테이블 스캔이 발생한 것일까?

그 이유는 ‘사원번호’ 칼럼이 기본키이나 사원번호르 그대로 쓰는 대신 SUBSTRING(사원번호, 1, 4)와 LENGTH(사원번호)와 같이 가공하여 작성했으므로, 기본 키를 사용하지 않게되어 테이블 풀 스캔을 수행했기 때문이다.

그럼, 다시 사원번호가 인덱스를 타도록 수정하면 되겠다!

⭕ 사원번호(기본키)가 인덱스를 타도록 수정해 보자.

// 첫 번째 방법
SELECT *
    FROM 사원
    WHERE 사원번호 BETWEEN 11000 AND 11009

// 두 번째 방법
SELECT *
    FROM 사원
    WHERE 사원번호 >= 11000 AND 사원번호 <= 11009

BETWEEN 구문으로 범위 검색을 수행하거나 비교연산자를 활용해 사원번호가 변형되지 않도록 하였다.

해당 쿼리로는 %의 개선이 있었는지 확인해 보자.

총 10건의 결과가 출력되고 0.1232초 → 0.0012초로 성능이 약 98.99% 개선되었다.

그럼 이번에도 실행계획을 보면서 인덱스를 잘 활용했는지 살펴보자.

기본 키(key항목 : PRIMARY)의 특정 범위만 스캔(type항목: range)한다는 걸 알 수 있다.

정리

1. 기본키를 변형하면, 인덱스가 사용되지 않고 풀 테이블 스캔이 발생할 수 있다.

2. 실행계획 확인하는 습관을 가지자!

- Type 항목이 ALL이라면, 풀 스캔 방식이므로 개선 포인트가 있는지 의심

- 기본키, 인덱스 확인해서 활용이 되고 있는지 확인

- 쿼리를 튜닝했다면 실행 계획을 확인해 어느 부분에서 개선이 되었는지 확인

출처 : [도서] 업무에 바로 쓰는 SQL 튜닝

[프로그래머스] 2019 KAKAO BLIND RECRUITMENT 후보키

Lea Hwang — Wed, 31 Jul 2024 09:32:09 +0900

후보키

문제

https://school.programmers.co.kr/learn/courses/30/lessons/42890

입출력 예

제한사항

relation은 2차원 문자열 배열이다.
relation의 컬럼(column)의 길이는 1 이상 8 이하이며, 각각의 컬럼은 릴레이션의 속성을 나타낸다.
relation의 로우(row)의 길이는 1 이상 20 이하이며, 각각의 로우는 릴레이션의 튜플을 나타낸다.
relation의 모든 문자열의 길이는 1 이상 8 이하이며, 알파벳 소문자와 숫자로만 이루어져 있다.
relation의 모든 튜플은 유일하게 식별 가능하다.(즉, 중복되는 튜플은 없다.)

문제 분석

• 후보키 : 릴레이션의 튜플을 유일하게 식별할 수 있는 속성 또는 속성의 집합으로 유일성과 최소성을 만족함

• 입력 : 릴레이션

• 출력 : 후보키의 최대 개수

아이디어

어떤 속성이나 속성의 조합이 유일성을 만족하는지 알 수 없기 때문에 모든 경우를 시도해봐야 한다. 만약 어떤 조합으로 튜플 개수를 세었을 때 중복이 존재하지 않는다면, 그 조합은 유일성을 만족한다고 볼 수 있다. 또한 최소성을 확인하기 위해, 현재 속성 조합에서 특정 속성을 제거해도 유일성이 유지되는지 검토해야 한다.

접근 방법

1. 알고리즘 선택: 완전 탐색과 조합을 활용

모든 가능한 조합을 생성하고 ➡️ 그중에서 최소성과 유일성을 만족하는 조합만을 반환할 계획이다.

2. 시간 복잡도: O(2^m)

조합 생성 부분 (열이 m개인 경우): O(2^m)

최소성을 확인하고 유일성을 검사하는 부분 (각 튜플에 대해 진행): O(n)

이 문제에서 m은 최대 20이므로, 시간 복잡도는 O(2^20)이다. 2^20은 10^8보다 훨씬 작기 때문에 해당 접근 방식으로 구현하는 것이 가능하다고 판단 후 코드 구현에 들어갔다.

코드 구현

1. 실패 코드

public class CandidateKey {
    public int solution(String[][] relation) {
        List<Set<Integer>> candidateKeys = new ArrayList<>();
        int rowLen = relation.length;
        int colLen = relation[0].length;

        for(int length=1; length<=colLen; length++){
            List<Set<Integer>> combinations = new ArrayList<>();
            getCombinations(0,0, length, combinations, new HashSet<>(), colLen);

            for(Set<Integer> cols : combinations){
                boolean minimality = true;

                for(Set<Integer> key : candidateKeys){
                    // 이 부분
                    if(key.containsAll(cols)){
                        minimality = false;
                        break;
                    }
                }

                if(!minimality){
                    continue;
                }

                Set<String> rowSet = new HashSet<>();
                for(String[] row : relation){
                    StringBuilder rowStr = new StringBuilder();
                    for(int col : cols){
                        rowStr.append(row[col]);
                    }
                    rowSet.add(rowStr.toString());
                }

                if(rowSet.size() == rowLen){
                    candidateKeys.add(new HashSet<>(cols));
                }
            }
        }

        return candidateKeys.size();
    }

    public void getCombinations(int start, int depth, int maxDepth,
                                List<Set<Integer>> combinations, Set<Integer> curr,
                                int colLen){

        if(depth == maxDepth){
            combinations.add(new HashSet<>(curr));
            return;
        }

        for(int i = start; i < colLen; i++){
            curr.add(i);
            getCombinations(i + 1, depth + 1, maxDepth, combinations, curr, colLen);
            curr.remove(i);
        }
    }

}

이유 : 최소성 검사에서는 key가 cols를 포함하는 것이 아니라,
cols가 key를 포함하는지 확인해야 한다.

key.containsAll(cols) -> cols.containsAll(key)

추가적으로 메서드 분리 적용해보았다.

2. 성공 코드

import java.util.*;

public class CandidateKey {
    public int solution(String[][] relation) {
        // 최종 후보 키를 저장할 리스트: 조합 + 최소성 + 유일성 만족
        List<Set<Integer>> candidateKeys = new ArrayList<>();

        // 릴레이션의 행 수
        int rowLen = relation.length;
        // 릴레이션의 열 수
        int colLen = relation[0].length;

        for (int length = 1; length <= colLen; length++) {
            List<Set<Integer>> combinations = new ArrayList<>();

            // 1. 모든 속성 조합을 생성하는 메서드 호출
            getCombinations(0, 0, length, combinations, new HashSet<>(), colLen);

            // 2. 생성된 모든 조합에 대해 최소성과 유일성 검사 시작
            // 2-1. 최소성 검사
            isMinimality(combinations, candidateKeys, relation, rowLen);
        }
        // 후보 키의 개수를 반환
        return candidateKeys.size();
    }

    // 모든 속성 조합을 생성하는 메서드
    public void getCombinations(int start, int depth, int maxDepth,
                                List<Set<Integer>> combinations, Set<Integer> curr,
                                int colLen) {

        // 현재 조합의 길이가 최대 길이(maxDepth)에 도달하면, 해당 조합을 리스트에 추가하고 종료
        if (depth == maxDepth) {
            combinations.add(new HashSet<>(curr));
            return;
        }

        for (int i = start; i < colLen; i++) {
            curr.add(i);
            getCombinations(i + 1, depth + 1, maxDepth, combinations, curr, colLen);
            curr.remove(i);
        }
    }

    // 최소성 검사 메서드
    public void isMinimality(List<Set<Integer>> combinations, List<Set<Integer>> candidateKeys,
                             String[][] relation, int rowLen) {
        for (Set<Integer> cols : combinations) {
            boolean minimality = true;

            // 기존 후보 키들과 비교하여 현재 조합이 최소성을 만족하는지 검사
            for (Set<Integer> key : candidateKeys) {
                // 만약 현재 조합이 기존 후보 키의 부분집합이라면, 최소성 위배
                if (cols.containsAll(key)) {
                    minimality = false;
                    break; // 최소성을 만족하지 않으므로 더 이상 검사할 필요 없음
                }
            }

            // 최소성을 만족할 경우에만 유일성 검사로 넘어감
            if (minimality) {
                // 2-2. 유일성 검사
                isUniqueness(relation, cols, rowLen, candidateKeys);
            }
        }
    }

    // 유일성 검사 메서드
    public void isUniqueness(String[][] relation, Set<Integer> cols,
                             int rowLen, List<Set<Integer>> candidateKeys) {
        Set<String> rowSet = new HashSet<>();
        for (String[] row : relation) {
            StringBuilder rowStr = new StringBuilder();
            for (int col : cols) {
                rowStr.append(row[col]);
            }
            // 각 행의 속성 조합 값으로 구성된 문자열 추가
            rowSet.add(rowStr.toString());
        }

        // rowSet의 크기가 행의 수와 같다면, 모든 행이 유일함을 의미
        if (rowSet.size() == rowLen) {
            candidateKeys.add(new HashSet<>(cols));
        }
    }
}

정확성: 100.0

합계: 100.0 / 100.0

회고

간단한 완전탐색 문제를 풀다가 오늘 푼 문제는 좀 어려웠다. 해결하는 데 3시간 정도 걸렸는데, 나중에 다시 돌아와서 풀어봐야겠다는 생각이 들었다. 유일성과 최소성의 개념은 알고 있었지만 이를 코드로 구현하려면 무엇을 어떻게 확인해야 하는지 꼼꼼히 따져야 했는데, 덕분에 코드 구현 능력이 +1 향상된 것 같아 뿌듯했다. 완전탐색 문제를 좀 더 풀어보면 감이 잡힐 것 같아 앞으로도 꾸준히 문제를 풀어볼 생각이다

ShootForTheMoon

[CS 스터디] 5주간의 데이터베이스 스터디 회고

목차

JSCODE 모의면접 신청 계기

스터디 진행 방식

잘한 점

아쉬운 점

앞으로는 이렇게

1:1 채팅 기능 개선 (feat. NoSQL 및 비동기 로직 적용)

목차

채팅 설계

저장소 (MySQL → MongoDB → 아카이빙)

어떤 데이터베이스를 쓸 것인가?

AS-IS : MySQL

TO-BE : 키-값 저장소로 변경(MongoDB)

마지막은, 아카이빙

동기 → 비동기

AS-IS : 동기

TO-BE : 비동기

스프링 이벤트를 선택한 이유

성능 테스트

Case 1. RDBMS vs 스프링 이벤트

MySQL 메시지 저장(동기)

이벤트 메세지 저장(비동기)

성능 개선

Case 2. RDBMS → NoSQL

최종 확인 (스프링 이벤트 + NoSQL 적용)

[CS 스터디] 5주간의 네트워크 스터디 회고

목차

JSCODE 모의면접 신청 계기

스터디 진행 방식

잘한 점

아쉬운 점

앞으로는 이렇게

[업무에 바로 쓰는 SQL 튜닝] 4.2.6 다수 쿼리를 UNION 연산자로만 합치는 나쁜 SQL문

❌ 문제의 SQL 문

실행 계획 살펴보기

⭕ UNION ALL 연산자로 변경해 보자

정리

[업무에 바로 쓰는 SQL 튜닝] 4.2.5 습관적으로 중복을 제거하는 나쁜 SQL 문

❌ 문제의 SQL 문

실행 계획 살펴보기

⭕ DISTINCT 키워드를 제거해 보자

정리

[업무에 바로 쓰는 SQL 튜닝] 4.2.4 열을 결합하여 사용하는 나쁜 SQL 문

❌ 문제의 SQL 문

실행 계획 살펴보기

⭕ 열을 결합하는 과정을 제거하고, 열을 분리해 보자

정리

[업무에 바로 쓰는 SQL 튜닝] 4.2.3 형변환으로 인덱스를 활용하지 못하는 나쁜 SQL 문

❌ 문제의 SQL 문

실행 계획 살펴보기

⭕ 형변환이 발생하지 않도록 SQL을 수정해 보자

정리

[업무에 바로 쓰는 SQL 튜닝] 4.2.2 사용하지 않는 함수를 포함하는 나쁜 SQL문

❌ 문제의 SQL 문

실행 계획 살펴보기

⭕ 불필요한 IFNULL() 함수를 제거해 보자

정리

[업무에 바로 쓰는 SQL 튜닝] 4.2.1 기본키를 변형하는 나쁜 SQL문

❌ 문제의 SQL 문 실행 계획 살펴보기⭕ 사원번호(기본키)가 인덱스를 타도록 수정해 보자 정리

❌ 문제의 SQL 문

실행 계획 살펴보기

⭕ 사원번호(기본키)가 인덱스를 타도록 수정해 보자.

정리

[프로그래머스] 2019 KAKAO BLIND RECRUITMENT 후보키

후보키

문제

문제 분석

아이디어

접근 방법

코드 구현

회고

❌ 문제의 SQL 문
실행 계획 살펴보기
⭕ 사원번호(기본키)가 인덱스를 타도록 수정해 보자
정리