Database Internals

  • 전문 검색 인덱스의 트랜잭션 핸들링과 MVCC의 관계

    아래 테스트 결과를 보면 InnoDB의 전문 검색(full-text search)은 격리 수준(=REPEATABLE-READ)이 적용되지 않는 것처럼 보인다. 오히려 커밋된 데이터를 읽는 READ-COMMITTED 격리 수준이 적용된 것처럼 보인다 ▼ CASE 1 세션 1 세션 2 BEGIN; SELECT * FROM t1 WHERE MATCH(title) AGAINST (‘postgresql’ IN NATURAL LANGUAGE MODE);===== 1. row =====id: 3title: Aurora PostgreSQL Databasecontent: NULL UPDATE t1 SET…

  • InnoDB 행 잠금의 2원 2규칙

    InnoDB 행 잠금의 2원 2규칙에 대해 설명하기에 앞서 개요가 조금 필요할 것 같아 살짝 지루한 이야기를 먼저 해보겠다. MySQL 서버의 InnoDB 스토리지 엔진에는 아래와 같이 3가지의 행 잠금 알고리즘이 존재한다. 그리고 당연한 이야기처럼 들리겠지만 이 중 넥스트 키 락은 갭 락과 레코드 락이 결합된 형태의 잠금 알고리즘이다. (역사적으로) 데이터베이스 시스템에서는 팬텀 리드(Phantom Read) 문제를 해결하기…

  • Real time – aws aurora status monitoring

    오늘은 Aurora DB 서버의 메타 정보를 실시간으로 모니터링 할 수 있는 작은 프로그램을 하나 공유해보고자 한다. 예전에 만들어둔 베타 버전이 있었는데, 코드를 조금 다듬어서 새롭게 만들었다. 사실 Aurora의 메타 정보를 실시간으로 볼 일이 그렇게 많지는 않지만, Aurora 버전 업그레이드를 한다던가, 스펙을 변경한다던가, 파라미터를 변경한다던가 할 때 Real time으로 확인이 필요한 경우도 있다. 그래서 가끔씩 찾아오는…

  • 옵티마이저의 sort_cost 비용 최적화

    우선 아래와 같이 MySQL 서버에 간단한 테이블 및 데이터를 생성하고 쿼리를 수행해보겠다. 왼쪽 세션에서는 ORDER BY절을 명시하지 않고 테이블을 조회하고, 오른쪽 세션에서는 ORDER BY절을 명시하고 테이블을 조회한다. 쿼리를 수행하면 아래 결과와 같이 두 쿼리의 레코드 정렬 순서가 동일한 것을 확인할 수 있다. 이어서 실행 계획도 확인해보자. 실행 계획 상에서도 여전히 두 쿼리의 차이점은 없다. 두…

  • Aurora custom endpoint와 autoscaling 활용 사례

    오늘은 2024년 6월 18일(화요일)에 AWS DATA & AI ROADSHOW 2024에서 Aurora custom endpoint와 AutoScaling 활용 사례에 대해서 발표한 내용을 공유해보려고 한다. 30분 정도의 발표 시간동안 분명 내용을 놓치신 분들도 계셨을 것이고, 이해가 되지 않는 분들도 계셨을 것이고, 피치 못할 사정으로 참석하지 못한 분들도 계실 것이다. 그래서 좀 더 깔끔히 정리된 내용으로 공유를 드리고자 한다. 목차는 다음과 같다.…

  • Multi IN 조건 실행 계획 오류(warning) 분석

    MySQL 서버에서 쿼리의 WHERE절에 IN 조건을 작성할 때는 일반적인 방식이 아닌 Row constructor 방식을 사용할 수 있다. 쿼리로 표현하면 다음과 같다.(이 글에서는 Multi IN 조건이라고 부르겠다.) 그리고 이를 다시 동일한 결과셋을 반환하는 쿼리로 작성하면 다음과 같다.(이 글에서는 General IN 조건이라고 부르겠다.) 그런데 특정 조건(쿼리의 조건을 의미하지 않음)에서는 Multi IN clause 실행 계획에서 불명확한 경고 문구가…