minkukjo
commented
2 years ago 공간 데이터 타입
- MySQL의 공간 데이터는 성능이 좋지 않고 지원도 마땅하지 않다.
- 예약팀에선 공간 데이터 관리에 POST GIS를 사용하고 있음.
JSON 타입
- JSON 역시 MySQL의 지원은 여전히 빈약하다.
- PostgreSQL JSON postgreSQL에선 JSON에 인덱스(!)와 쿼리(!) 기능을 지원한다. ( JSON 필드를 쿼리 조건으로 사용할 수 있음 )
- 예약팀에서는
JSON컬럼을 MySQL의 그것이 아닌, 문자열로 저장하고 관리하고 있다. - JSON 타입으로 관리하면 더 좋을 것 같은데, 굳이 이런 방식을 취하는 이유가 무엇인지 문득 궁금해서 내일 한 번 팀에 물어봐야겠음.
- 매우 큰 JSON 도큐먼트가 저장되면 16KB 단위로 데이터 페이지를 나눠서 MySQL 서버가 저장한다고 한다.
- 이 때 대용량 BLOB 데이터는 여러개의 BLOB 페이지로 나뉘게 된다. (5.7에서는 링크드 리스트였다고 함)
JSON 부분 업데이트 성능
- 8.0부터는 부분 업데이트도 지원하는데, 특정 조건을 만족하면 성능이 매우 빠르다고 한다.
- 참고로 JSON 필드는 MySQL에서 내부적으로 BLOB(Long BLOB)으로 저장되게 된다.
- JSON 부분 업데이트를 사용하게 되면, 여러 개의 데이터 페이지 중 변경된 데이터 페이지만 교체하면 되서 전체 업데이트보다 성능상 이점이 있다.
JSON 콜레이션과 비교
- JSON 타입도 콜레이션이 존재한다.
- utf8mb4_bin과 utf8mb4 두 개다.
- utf8mb4_bin은 바이너리 콜렉션이라서 대소문자 구분은 물론 액센트 문자도 비교한다.
JSON 컬럼 선택
- JSON을 사용한다면, BLOB이나 TEXT 타입 보다 JSON 타입을 사용하는게 성능상 이점이 크다.
- 다만 모든 데이터를 JSON에 때려박기 보다는, 최대한 정규화된 테이블 구조를 갖고 중요도가 낮고 타입이 다 다르며 빈번하게 변경되는 데이터라면 JSON 컬럼에 비정규화된 형태로 저장하는 것을 고려해보자.
가상 컬럼과 스토어드 컬럼
데이터 조회 시점에 매 번 계산되지만 결과가 많은 공간을 차지하면 가상 컬럼이 좋음 컬럼 계산 과정이 복잡하고 시간이 오래걸린다면 스토어드 컬럼이 좋음
가상 컬럼
- 칼럼의 값이 디스크에 저장 안됨
- 컬럼의 구조 변경은 테이블 리빌드가 필요핮 ㅣ않음
- 컬럼의 값은 레코드가 읽히기 전 또는 트리거가 실행된 직후 계산되어 만들어짐
스토어드 컬럼
- 컬럼의 값이 물리적으로 디스크에 저장 됨
- 컬럼의 구조 변경은 다른 일반 테이블과 같이 필요 시 테이블 리빌드 방식으로 처리됨
- Insert와 Update 시점에만 컬럼의 값이 계산됨
복제
- Avaliability와 Scalability를 보장하기 위해 Replication은 필수적이다.
복제 아키텍처
- MySQL은 서버에서 발생하는 모든 변경 사항을 별도의 로그 파일에 순서대로 기록하는데, 이를 바이너리 로그라고 부른다.
- 바이너리 로그엔 데이터 변경 뿐 아니라 테이블 구조 변경, 계정 권한 변경도 저장이 된다.
- 이러한 바이너리 로그에 기록된 변경을 Event라고 부른다.
- 참고로 Kafka Debezium 공식 도큐먼트 공식 가이드에서도 CDC를 구현하기 위해 MySQL의 바이너리 로그를 이용하는 것을 알 수 있다.
- 어쨌든 MySQL에서도 이 바이너리 로그를 사용해 복제를 하는데, 소스 MySQL 서버의 바이너리 로그 덤프 스레드가 레플리카 서버의 레플리케이션 I/O 쓰레드에게 변경사항을 넘긴다.
- 그러면 레플리카 서버의 릴레이 로그에 변경사항이 써지게 되고 레플리케이션 SQL 스레드가 이 로그를 읽어서 DB에 저장하는 방식이다.
- 복제가 시작되면 레플리카 서버는 총 세개의 복제 관련 데이터를 생성한다.
- 릴레이 로그 : 레플리케이션 I/O 쓰레드에 의해 작성되는 파일이며, 소스 서버의 바이너리 로그에서 읽어온 변경 사항을 저장하는 로그 파일.
- 커넥션 메타데이터 : 레플리케이션 I/O 쓰레드에서 소스 서버에 연결할 때 사용하는 DB 게정 정보, 현재 읽고 있는 서버의 바이너리 파일 명과 파일 내 위치 등의 값이 담겨있다.
- 어플라이어 메타데이터 : 레플리케이션 SQL 스레드에서 릴레이 로그에 저장된 이벤트들을 레플리카서버에 적용하는 컴포넌트를 어플라이어라 부른다. 최근 적용된 이벤트에 대해 해당 이벤트가 저장된 릴레이 로그 파일명과 파일 내 위치 정보를 저장하고 있고, 레플리케이션 SQL 쓰레드는 이 정보를 바탕으로 레플리카 서버의 나머지 이벤트를 적용한다.
복제 타입
- 바이너리 로그에 기록된 변경 내역을 식별하는 방식에 따라, 로그 파일 위치 기반 복제와 글로벌 트랜잭션 ID 기반 복제로 나뉜다.
바이너리 로그 파일 위치 기반 복제
- MySQL 서버는 고유한 server_id를 갖는데, 레플리카 서버 입장에서 이 값이 자신과 같은 경우 해당 이벤트를 적용하지 않는다. (자기가 만든거라 생각해서)
- 그래서 각각의 MySQL 서버는 고유한 server_id를 가져야 제대로 바이너리 로그 파일 기반의 복제를 수행할 수 있다.
글로벌 트랜잭션 아이디 기반 복제
- 복제 토폴로지 복제 토폴로지, 복제 토폴로지가 대체 무슨말인고?
- 복제 토폴로지는 그냥 한 노드에서 다른 노드로 데이터를 전달하는 통신 경로를 의미한다고 한다.
- 찾아보니 이 복제 토폴로지는 종류가 여러 가지라고 한다.
복제 토폴로지
- 출처는 데이터 중심 애플리케이션 설계라는 책. (읽어보진 못했으나, 읽어봐야할 듯... ㅋㅋ)
- 리더가 둘인 경우 가능한 복제 토폴로지는 하나.
- 리더 1이 리더 2에게 모든 쓰기를 전송함.
- 그나 리더가 둘 초과인 경우 여러 토폴로지가 가능함.
- 여기서 원형 토폴로지는 MySQL에서 사용하는 방식이라고 함.
글로벌 트랜잭션 아이디 기반 복제로 다시 돌아와서
- 소스 서버에서 발생한 이벤트가 복제에 참여한 모든 MySQL 서버에 동일한 고유 식별자 값을 가지는 가정을 해보자.
- 그럼 장애가 발생하더라도 손쉽게 복제 토폴로지를 변경할 수 있다.
- 이처럼 바이너리 로그 파일 위치 기반 복제처럼 소스 MySQL 서버에서만 고유한 ID가 아닌 복제에 참여한 모든 MySQL 서버들에서도 고유하도록 각 이벤트에 부여된 식별 값을 글로벌 트랜잭션 아이디라고 부르며 줄여서 GTID라 부른다.
GTID의 필요성
- 바이너리 로그 파일 위치 기반 복제의 경우 레플리카 서버에 지연이 발생해서 동기화가 늦게 된 경우, 클라이언트 입장에선 그 레플리카 서버로 쿼리를 보낼 수 없게 된다. ( 동기화가 안되어있어서 요청 처리가 곤란함 )
- 왜냐하면 새로 선출된 리더(이전에는 레플리카)는 소스 서버와 동기화가 되어있지만, 레플리카의 경우 소스 서버와 동기화가 안되어있고, 리더 입장에서는 모든 요청을 클라이언트로 받아야하고, 남아있는 레플리카를 클라이언트에게 참여시킬 수 없는 문제가 발생한다.
- GTID를 사용하는 경우 복제에 참여한 모든 트랜잭션 ID값이 동일하기 때문에, 레플리카 서버에 지연이 발생해서 동기화가 늦게 되고, 다른 리더가 선출되더라도 선출된 리더(원래는 레플리카였던)의 ID 값 이후 데이터를 받아오면 동기화가 가능해진다.
Edwin222
DaehunGwak
진도
일시
2022.08.28.(일) 21:00