Database 12

MYSQL - 단일 RDB 환경 에서 계층형 엔티티 저장 최적화, 벌크 인서트

계층형 엔티티 저장 시 발생하는 문제: 부모-자식 관계와 쿼리의 비효율성보통 Java, Spring, JPA를 사용하는 경우, 계층형 엔티티를 저장할 때, 부모 엔티티를 JpaRepository로 저장하고 반환된 ID 값을 자식 엔티티에 할당하여 저장하거나, **@ManyToOne**이나 @OneToMany 관계를 이용해 자동 저장하는 방식이 일반적이다.그런데, 나는 이 방식이 정말 맘에 안 들었다. 왜냐면 부모 엔티티의 수만큼 쿼리가 나가기 때문이다. 이게 문제다.문제의 핵심: 부모-자식 관계 저장 시 발생하는 비효율성**JpaRepository**를 이용하면, 부모 엔티티를 저장하고 ID 값을 반환받아 자식 엔티티에 ID를 할당해서 저장하는 방식인데, 이 과정에서 매번 부모 ID를 가져오는 쿼리가 나..

Database/RDS 2025.05.24

InnoDB - Undo Log, Redo Log

이 두 가지 로그는 데이터 일관성과 무결성을 유지하는 데 중요한 역할. 언두 로그(Undo Log)언두 로그는 트랜잭션이 수행되기 전의 데이터 상태를 저장하는 역할.트랜잭션 롤백: 트랜잭션이 롤백될 때, 언두 로그에 기록된 이전 데이터를 이용해 데이터베이스를 원래 상태로 복구할 수 있다.MVCC(Multi-Version Concurrency Control): 여러 트랜잭션이 동시에 접근할 때, 트랜잭션의 일관성을 유지하기 위해 언두 로그를 사용. 예를 들어, 하나의 트랜잭션이 어떤 행을 업데이트하고 있지만 아직 커밋하지 않은 상태라면, 다른 트랜잭션이 이 행을 읽으려고 할 때 언두 로그를 참조하여 업데이트되기 전의 데이터를 제공. 이는 트랜잭션 격리 수준을 유지하고, "Read Committed"나 "R..

Database/RDS 2024.08.14

InnoDB - GTID

Global Transaction Identifiers (GTIDs) MYSQL 5.6 버전까지 레플리카는 소스에 연결할 때 읽고 있던 바이너리 로그 파일과 로그 위치를 추적해야했다. EX) 1. 레플리카가 업스트림 소스에 연결되어 위치 2749의 binlog.000002에서 데이터를 읽는다. 2. 레플리카는 바이너리 로그를 읽을때 마다 위치 이동. 3. 그러던 중 재해 발생하여 소스가 손상하여 백업에서 데이터를 다시 작성해야함 4. 바이너리 로그가 다시 시작 된다면 레플리카를 어떻게 다시 연결해야 하는가? 너무 복잡하다. 그래서 전역 트랜잭션 식별자가 추가 됨. 소스 서버가 커밋하는 모든 트랜잭션에 고유 식별자(server_uuid + 트랜잭션 번호)가 할당.트랜잭션이 바이너리 로그에 기록되면 GTID..

Database/RDS 2024.08.13

InnoDB - Replication

MYSQL 에 대한 Replication의 일반적인 사용 예시1. 데이터 분산 2. 읽기 트래픽 확장3. 분석 및 보고 - 보고/분석(온라인 분석 처리 , OLAP) 쿼리를 위해 전용 레플리카를 사용4. 고가용성 및 장애 조치 - 복제는 MYSQL이 애플리케이션에서 단일 장애 지점이 되는 것을 방지할 수 있다.5. MYSQL 버전 업그레이드 테스트 -참고 https://dev.mysql.com/doc/refman/8.4/en/replication-solutions.html MySQL :: MySQL 8.4 Reference Manual :: 19.4 Replication SolutionsMySQL 8.4 Reference Manual / Replication / Replication Soluti..

Database/RDS 2024.08.13

InnoDB - Transaction Isolation Levels

읽기 이상 현상 Dirty Read (더티 리드)커멋 되지 않은 다른 트랜잭션의 데이터를 읽는 경우, 만약 첫 번째 트랜잭션이 롤백되면, 두 번째 트랜잭션이 읽은 데이터는 무효. Non-Repeatable Read (반복 불가능 읽기)동일한 트랜잭션 내에서 동일한 쿼리를 두 번 이상 실행할 때, 두 번째 실행 시 이전과 다른 결과를 얻는 경우. 이는 다른 트랜잭션이 데이터를 수정했기 때문. Phantom Read (팬텀 리드)동일한 트랜잭션 내에서 동일한 쿼리를 반복할 때, 처음에는 없던 새로운 행이 나타나는 경우. 이는 다른 트랜잭션이 해당 범위에 새로운 행을 삽입했기 때문. Lost Update (손실된 업데이트)두 개의 트랜잭션이 동일한 데이터를 읽고 수정하는 과정에서, 한 트랜잭션의 수정이 다른 ..

Database/RDS 2024.08.12

InnoDB - Locking

Lock의 종류Shared Lock, S Lock shared lock은 특정 트랜잭션이 행을 읽을 수 있게 한다. 이 잠금을 획득한 트랜잭션은 행의 데이터를 읽을 수 있지만, 수정하거나 삭제할 수는 없다. 글자 그대로 Shared 공유한다. 여러 트랜잭션이 동일한 행에 대해 shared lock을 동시에 획득 할 수 있다. Exclusive Lock, X LockExclusive lock은 특정 트랜잭션이 행을 수정하거나 삭제할 수 있게 한다. 배타적 잠금을 획득한 트랜잭션은 행의 데이터를 수정하거나 삭제할 수 있으며, 이 잠금이 해제될 때까지 다른 트랜잭션이 그 행을 수정하거나 읽을 수 없다. 글자 그대로 Exclusive 배타적이다. 특정 트랜잭션이 특정 행에 대해 먼저 Exclusive Loc..

Database/RDS 2024.08.12

MySQL 성능 최적화 - 고성능 시스템 구축을 위한 전략과 최적화 기법 - 07. 고성능을 위한 인덱싱

해당 포스팅은 위의 책을 읽고 정리한 내용입니다.인덱싱 기본 인덱스는 책의 목차와 같은 역할.데이터베이스에서 인덱스는 테이블의 데이터를 빠르게 조회하기 위해 사용인덱스를 잘 설계하면 데이터 검색 속도가 크게 향상되며, 그 결과 전체 시스템의 성능이 개선 1. 클러스터형 인덱스(Clustered Index)역할: 클러스터형 인덱스는 테이블의 데이터 자체가 인덱스의 리프 노드에 포함된 인덱스. InnoDB에서는 프라이머리 키가 클러스터형 인덱스로 사용.구조: 클러스터형 인덱스는 보통 B-트리 구조를 사용. B-트리 구조 내에서 클러스터형 인덱스는 데이터가 물리적으로 정렬되어 저장되며, 이 인덱스를 사용해 데이터를 빠르게 검색할 수 있다.특징: 클러스터형 인덱스의 리프 노드는 실제 데이터 페이지를 가리키며, ..

Database/RDS 2024.08.09

Elastic Search - 텍스트 분석 (5)

이제 실질적으로 검색을 위한 사전작업을 해야한다. 우선 검색 정확도(3) 포스팅에서 언급한 역인덱스라는것을 기억하는가 엘라스틱 서치는 역 인덱스를 통해 단어들을 term 으로 분리하고 이 term이 어디에 존재하는지 기록한다.이 역인덱스를 하는 과정에서 텍스트를 분석할때Analyzer를 사용하고 그 안엔 Character Filter, Tokenizer, Token Filter 가 있다고 했었다.다시한번 간단하게 설명해보자면Character Filter 는 맨 처음 들어오는 단어들에 대해 특정 가공을 한다.Tokenizer 는 이 들어온 단어들을 term으로 나눈다.Token Filter 는 이 분리된 term들을 가공하여 역 인덱스를 한다. 아무것도 설정 안한 엘라스틱서치가 해당 단어를 어떻게 분석하..

Database/NOSQL 2024.04.16

Elastic Search - 검색 정확도(3)

이전 포스팅에서 우린 정확도에 대한 문제를 직면했다.이 정확도에 대해 자세히 알아보고 어떻게 쿼리를 작성해야할지 알아보자.엘라스틱 서치의 검색 결과 리스폰스를 보면 _score 필드를 볼 수 있다."max_score": 4.603986, "hits": [ { "_index": "set_of_search_index", "_id": "3", "_score": 4.603986, "_source": { "message": "메종키츠네 폭스헤드 우먼즈 반팔티 블랙 AW00103KJ0005-P199" } ..

Database/NOSQL 2024.04.04