Maria DB를 사용하는 서비스 준비 중 대량의 IO가 발생할 가능성이 있고 테스트 중 IO 속도가 느려지는 경우가 발생했습니다. 뭐 근본적으로는 로직 설계의 문제였고 해당 부분을 고쳐서 해결했지만 해당 문제 원인 파악중 공부한 내용을 간단하게 기록합니다. (Fragmentation 은 모든 DB에서 일어날 수 있는 문제이지만 제가 자주 사용하는 MariaDB를 기준으로 설명합니다)
검색하다보니 partioning 과 동일한 의미로 fragmentation 을 뜻하는 문서도 꽤나 보이는 데 해당 포스트에서는 partioning 과 동일한 의미가 아닌 메모리에서 일어나는 문제에 대해 말합니다.
선수 지식
1. MariaDB Delete 명령어는 삭제된 공간을 바로 반환하지 않는다.
2. MariaDB의 기본 스토리지엔진은 InnoDB이다. (MariaDB 10.2 부터)
MariaDB의 InnoDB는 일반적으로 B+Tree를 사용하여 인덱스를 관리합니다.
|
index
|
data
|
|
1
|
MariaDB
|
|
2
|
Oracle
|
|
•
•
•
|
|
|
8
|
MS-SQL
|
|
9
|
MongoDB
|
이러한 데이터가 있을 때 이상적인 인덱스 구조는 이렇습니다.
다행히 그러한 시스템은 대체로 존재하지 않기 때문에 아래와 같은 문제가 발생합니다.
그림1 에서는 사용하지 않던 page 2가 그림 2에서는 사용되고 있습니다.
이를 좀 더 쉽게 보기 위해 정리하면 아래와 같습니다.
비어있는 공간은 모두 사라지고 이전에 사용한 공간만 및 사용 중인 공간만 남아있습니다.
해당 페이지에는 필요 없는 공간이 차지하고 있어 메모리 낭비가 됩니다.
이러한 경우를 Internal Fragmentation 라고 합니다. 동일한 데이터로 INSERT, DELETE를 반복하면 테이블 스페이스 용량이 커지는 것을 확인 할 수 있는데 이러한 경우라고 보시면 됩니다.
기존에는 하나의 페이지에서 순서대로 찾아가면 되었던 반면에 내부 파편화로 인해 페이지가 꽉 차면서 새로운 페이지를 사용하게 되면서 두개의 페이지를 왕복하고 있습니다. 이러한 과정은 성능에 부정적 영향을 줍니다.
이러한 경우를 External Fragmentation 라고합니다.
이러한 Fragmentation들은 당연히도 DB 회사 및 개발자들도 인지를 하고 있기 때문에 대부분 자동으로 처리하는 기능들이 들어가 있습니다. 예를 들어 InnoDB는 일정 수준의 변경이 있었다면 Index를 최적화를 실행합니다.
제가 해당 문제에 대해 직접 해결한 경험도 없기 때문에 추후 공부 및 자료 구성 때까지는 따로 해결법을 작성하지 않습니다. 다른 블로그 등에도 많은 자료가 나와 있으니 참고해주세요.
참조
MySQL fragmentation 원인과 해결방법 - https://kimdubi.github.io/mysql/optimize/
Defragmenting InnoDB Tablespaces - https://mariadb.com/kb/en/defragmenting-innodb-tablespaces/
'공부 > 기록' 카테고리의 다른 글
| Elasticsearch reindex 시 timestamp에 시간 더하는 쿼리 (0) | 2023.05.03 |
|---|---|
| DataGrip에서 SSH tunnel 사용하기 (0) | 2021.09.14 |
| oracle database 11g Release 2 다운로드 방법 (1) | 2021.08.25 |
| 코딩 테스트 대비 연습 사이트 목록 (0) | 2021.06.10 |
| vscode python 확장프로그램 추천 (2) | 2020.12.29 |
댓글