Selectivity vs Cardinality 이해하기 - Cardinality 낮아도 인덱스를 걸면 좋은 경우
·
카테고리 없음
status 인덱스가 카디널리티가 낮아도 잘 먹히는 이유부터 복합 인덱스, LIMIT과 ORDER BY, covering index, 그리고 (created_at, status)가 더 좋은 케이스까지 Batch Job Queue를 운영하다 보면 결국 자주 만나게 되는 쿼리가 있습니다.SELECT idFROM job_queueWHERE status = 'PENDING'ORDER BY created_atLIMIT 50;대기 중인 작업(PENDING) 중에서 오래된 것부터 몇 개 가져오는 패턴이죠. 이건 거의 모든 배치/큐 시스템의 기본 동작입니다.그런데 status 컬럼은 보통 값 종류가 몇 개 없습니다. (PENDING, RUNNING, COMPLETED…)그래서 이런 질문이 자연스럽게 나옵니다.statu..
External Secrets Operator 소개: 안전하고 효율적인 쿠버네티스 시크릿 관리
·
DevOps/Kubernetes
쿠버네티스를 운영하다 보면 환경 변수, API 키, 인증 토큰처럼 절대 코드에 포함되면 안 되는 시크릿(secret) 들을 관리해야 합니다.기본적으로 Kubernetes Secret 객체를 사용할 수 있지만, 시간이 지나면 다음과 같은 문제들이 생기기 쉽습니다:여러 서비스에서 동일한 비밀 정보를 반복해서 관리해야 함운영자가 수작업으로 Secret 값을 수정해야 함GitOps 파이프라인에 시크릿을 넣지 못해서 구성 관리가 꼬임외부 Vault(AWS, GCP, HashiCorp)와 연동이 어렵거나 불편함이 문제를 깔끔하게 해결해주는 오픈소스 프로젝트가 바로 External Secrets Operator(ESO) 입니다.External Secrets Operator란?External Secrets Operat..
Bazel 을 처음 접하는 사람들을 위한 기초 개념 가이드
·
DevOps/Bazel
사내에서 Bazel을 도입하게 되어 학습 및 팀원 교육 자료로 만든 자료를 블로그에도 공유합니다 공식문서에 Bazel 개념관련 문서가 있지만 한국 자료뿐만 아니라 영어자료 조차도 부족한 상황이라본인처럼 Bazel을 처음 접한사람이 이해하기 어려운 면이 별도로 문서로 해서 정리한다.ConceptsWorkspace우리가 보통 서비스 리포지토리 단위로 생각하는 개념을 Bazel 에서 WORKSPACE 라고 한다 Bazel 은 monorepo 를 위해 만들Bazel 로 구성된 프로젝트의 루트에는 WORKSPACE 라는 파일이 존재하는데 여기서 프로젝트 공용으로 빌드에 필요한 의존성들을 추가한다. (e.g go, python, java 빌드에 필요한 의존성들)PackageBazel 에서 소스코드를 소프트웨어 모듈..
[DB] MySQL 파티션 테이블 가이드
·
Database/My SQL
MySQL 파티션 테이블 가이드들어가며: 파티션의 필요성대규모 데이터베이스를 운영하다 보면 마치 거대한 도서관을 관리하는 것과 같은 어려움을 겪게 됩니다. 수백만 건의 데이터를 하나의 테이블에서 관리한다면, 책장 전체를 뒤져야 하는 것처럼 검색 시간이 오래 걸리고 관리도 어려워집니다. 이러한 문제를 해결하기 위해 MySQL은 파티셔닝이라는 강력한 기능을 제공합니다.파티션 테이블의 이해파티션 테이블은 마치 도서관의 책을 주제별로 나누어 관리하는 것과 같습니다. 하나의 큰 테이블을 여러 개의 작은 물리적 조각(파티션)으로 나누어 저장하지만, 사용자 입장에서는 여전히 하나의 테이블처럼 사용할 수 있습니다.예를 들어, 온라인 쇼핑몰의 주문 내역을 연도별로 파티셔닝한다고 생각해봅시다:-- 주문 내역 테이블을 연도..
[DB] 파티션 테이블(Partition Table)이란?
·
Database/My SQL
파티션 테이블이란?파티션 테이블은 대용량 데이터를 효과적으로 관리하기 위해 하나의 테이블을 여러 물리적 단위(파티션)로 나누어 저장하는 방식입니다. 논리적으로는 하나의 테이블로 동작하지만, 물리적으로는 데이터가 각 파티션에 분산 저장됩니다. 이를 통해 데이터를 조회하거나 관리할 때 성능과 효율성을 크게 향상시킬 수 있습니다.파티션 테이블은 특히 Pruning이라는 최적화 기법을 지원합니다. 특정 데이터를 조회할 때 필요한 데이터가 위치한 파티션만 읽어들이는 방식으로, 쿼리 속도를 대폭 개선합니다. 또한, 파티션 테이블은 개발자 입장에서 기존 쿼리를 특별히 수정할 필요가 없으면서도 데이터 관리와 유지보수를 간소화할 수 있는 장점이 있습니다.1. 파티션 테이블의 장단점장점쿼리 성능 향상: 특정 조건에 맞는 ..
커버링 인덱스 (Covering Index) 를 사용해서 쿼리 최적화하기
·
Database/My SQL
커버링 인덱스(Covering Index)란 무엇인가?커버링 인덱스는 쿼리가 필요로 하는 모든 컬럼을 포함하는 인덱스를 말합니다. 이 인덱스를 사용하면 테이블의 실제 데이터 페이지에 접근하지 않고도 인덱스만으로 원하는 데이터를 조회할 수 있어 디스크 I/O를 절약할 수 있습니다.MySQL 공식 문서 정의:*"쿼리에서 검색되는 모든 컬럼을 포함하는 인덱스입니다. 인덱스 값을 전체 테이블 행을 찾는 포인터로 사용하는 대신, 쿼리는 인덱스 구조에서 값을 반환하여 디스크 I/O를 절약합니다. InnoDB는 MyISAM보다 더 많은 인덱스에 이 최적화 기술을 적용할 수 있습니다. 왜냐하면 InnoDB의 보조 인덱스에는 기본 키 컬럼도 포함되어 있기 때문입니다. InnoDB는 해당 트랜잭션이 끝날 때까지 트랜잭션에..
Java 환경에서 AES를 사용한 암호화 사용 정리
·
Java
DB 칼럼 암호화를 위한 AES 대칭키 암호화 방법최근 개인정보 보호 및 데이터 보안의 중요성이 커지면서, 데이터베이스 내 민감한 정보를 암호화하는 요구사항이 증가하고 있습니다. 본 포스트에서는 AES (Advanced Encryption Standard) 를 활용하여 DB 칼럼을 암호화하는 방법과 그 구현 예제를 소개합니다.1. AES란?AES는 미국 정부에서 채택한 표준 대칭키 암호화 알고리즘입니다.대칭키 암호화: 암호화와 복호화에 동일한 키를 사용합니다.키 사이즈: AES는 128, 192, 256비트 키를 지원하며, 키 길이가 길수록 brute force 공격에 대한 방어력이 향상됩니다.자세한 내용은 Wikipedia의 AES 문서 를 참고하세요.2. AES의 구성 요소AES 암호화를 구현하기 위..
MySQL 데이터 복구하기
·
카테고리 없음
데이터 복구 과정에서 학습한 내용 기록이번에 회사에서 AWS RDS로 DB 서버를 단계적으로 이전하는 과정에서 프로덕션 데이터가 소실되는 상황이 발생하였습니다. 다행히 바이너리 로그(binlog)를 보관하는 기간 내에 있어서 MySQL binlog를 활용하여 데이터를 복구할 수 있었습니다. 이때 학습한 내용을 기록 차원에서 남깁니다.데이터 복구 과정프로덕션 서버에서 binlog 확인SHOW BINARY LOGS;결과는 다음과 같았습니다:+---------------+-----------+ | Log_name | File_size | +---------------+-----------+ | binlog.000015 | 724935 | | binlog.000016 | 733481 | +------------..
MySQL Index 정리 및 팁
·
Database/My SQL
MySQL Index 정리 및 팁MySQL의 인덱스란 무엇인가?인덱스는 MySQL에서 데이터베이스 테이블의 데이터 검색 속도를 향상시키는 자료구조입니다. 책의 색인과 유사하게, 데이터베이스 인덱스는 전체 테이블을 스캔하지 않고도 데이터베이스 엔진이 특정 행을 빠르게 찾을 수 있게 해줍니다.MySQL은 주로 정렬된 구조로 데이터를 저장하여 효율적인 검색, 삽입, 삭제 작업을 가능하게 하는 B-Tree 인덱스를 사용합니다.B-Tree 인덱스 구조B-Tree(Balanced Tree) 인덱스는 다음과 같은 주요 특징을 가집니다:루트 노드: 브랜치 노드를 가리키는 트리의 최상위 레벨브랜치 노드: 키와 자식 노드에 대한 포인터를 포함하는 중간 레벨리프 노드: 인덱스된 값과 행 포인터를 포함하는 최하위 레벨균형 구..
카프카 Exactly Once Delivery 구현
·
Messaging Queue/Kafka
Kafka에서의 Exactly Once Delivery 구현메시지 시스템을 사용하다 보면 메시지의 전달 보장 방식에 대해 고려해야 합니다. 일반적으로 다음 세 가지 전달 방식이 있습니다.At Least Once Delivery: 메시지가 최소 한 번 전달됩니다. 중복 메시지가 발생할 수 있습니다.At Most Once Delivery: 메시지가 최대 한 번 전달됩니다. 메시지가 손실될 수 있습니다.Exactly Once Delivery: 메시지가 정확히 한 번 전달됩니다. 중복이나 손실이 없습니다.Kafka를 사용할 때, 메시지의 정확한 전달을 보장하는 것은 중요한 이슈입니다. 특히 Consumer 측에서 메시지를 처리하는 과정에서 중복이나 손실 없이 메시지를 정확히 한 번씩 처리하도록 구현하는 방법을 ..