리타의 저장소

Table Random Access 최소화 튜닝인덱스 컬럼 추가기존 인덱스에 컬럼 추가PK 인덱스에 컬럼 추가⇒ 인덱스에 컬럼 추가했을 때, 클러스터링 팩터가 나빠질 수 있다.→ 인덱스 내에서 키 값이 같은 레코드는 rowid 순으로 정렬됨. 근데, 여기서 변별력이 좋은 컬럼이 추가되면, 해당 컬럼 순으로 정렬되어 클러스터링 팩터를 나쁘게 만들 수 있음.변별력이 좋지 않은 컬럼 뒤에, 변별력이 좋은 컬럼을 추가 할때는 유의해야할 필요가 있음.IOT (Index Organized Table)테이블을 인덱스 구조로 생성. 테이블 인덱스 구조로 만드는 구문create table index_org_t (a number primary key, b varchar(10)) organization index; 힙 구조..

인덱스의 활용 인덱스Key + ValueB*tree 인덱스 구조 RowId (제한된 포맷)데이터파일 (4자리)블록 번호 (8자리)로우번호 (4자리)RowID (확장 포맷)데이터 오브젝트 번호 (6자리)데이터 파일 번호 (3자리)블록 번호 (6자리)로우 번호 (3자리) 인덱스의 탐색 수직적 탐색Root > Branch > Leaf시작점 검색Random Access ROOT : 최상위 노드 BRANCH : ROOT & LEAF 의 연결고리 LEAF : KEY + Rowid (블록주소) > leaf node는 정렬되어 있음수평적 스캔Leaf Block의 시작점 ~ 종료점 까지Sequential Access 테이블 Random Access데이터 블록을 읽는 케이스 인덱스의 손익 분..

스프링 프로젝트 생성하고 ES랑 연동하기spring starter io에서 우선 프로젝트를 생성한다. 생성할때, Spring Data Elasticsearch를 추가. 그외 Lombok, JPA, PostgreSQL 등 기타 프로젝트에 필요한 설정도 추가해줬다. 자 그럼 users Document를 셋팅 해줘보자. (Spring -- Elasticsearch 연동)* 주의 : 처음에는 그냥 실험하는 거니까 라는 마인드로 편의상 @Data 어노테이션을 사용한 코드를 업로드 했었으나, 다들 알다시피 실무에선 지양하는게 좋다. 그래서 그냥 바꿨다... UserDocument package com.salary.backend;import lombok.AllArgsConstructor;import lombok.D..

인덱스 만들기 #이런식으로 만든다.PUT /users # 확인 GET /users# DELETEDELETE /boards 만약 DELETE 문으로 인덱스를 삭제하게 된다면, not found exception이 뜬다. "index_not_found_exception", 인덱스에 매핑 정의하기 쉽게 얘기하면 users 라는 인덱스(테이블)에, name, age, is_active라는 컬럼을 정의해준거라고 생각하면 된다.PUT /users/_mappings{ "properties" : { "name" : {"type": "keyword"}, "age" : {"type": "integer"}, "is_active": {"type": "boolean"} }} 확..

인덱스 설계는 데이터베이스 성능 최적화의 핵심인덱스 종류B-Tree 인덱스 Unbalanced Index B-Tree의 "B"는 Balanced를 의미함. Index Skew 현상 대량 삭제 후 발생하는 현상 인덱스 스캔 효율 저하 (다시 채워지기 전까지 성능 문제 발생) 비트맵 인덱스Distinct 개수가 적을 때 유용대용량 테이블에서 여러 개의 인덱스가 필요할 때 적합DW (Data Warehouse) 테이블에서 주로 사용단독 사용보다는 여러 개를 묶어서 활용함수 기반 인덱스 활용 사례 암호화 솔루션 리버스 키 인덱스부하 분산에 유리Equal = 조회만 가능범위 검색(Between, Like 등)에는 사용 불가클러스터 인덱스클러스터형 인..

Index Range ScanIndex Range Scan Descending hint : Index_desc B*Tree인덱스의 가장 일반적이고 정상적인 형태필요한 범위만 스캔인덱스를 구성하는 선두 컬럼을 조건절에 사용해야한다.성능은 인덱스 스캔범위, 테이블 엑세스 횟수를 얼마나 줄일수있느냐로 결정(인덱스탄다고끝이아님)인덱스 사용이 불가능 하거나 범위 스캔(Range Scan)이 불가능 한 경우 ?인덱스 컬럼의 가공 (좌변 가공)Null 검색Null 검색의 경우, not null인 행이 있어 ” null + 값” 인경우 인덱스 range scan 가능묵시적 형변환컬럼과 상수의 Data Type이 상이한 경우변환 불가능하면 에러 발생문자 = 숫자 (문자 > 숫자)날짜 = 숫자 (에러)문자 = 날짜 (문자..

덱스는 알아도 인덱스는 잘 몰르는디,,처음 운영 데이터를 만지면서 가장 중요한 것 중 하나는 바로 '인덱스' 였다. 종종 정산데이터를 업로드 한다거나,대량데이터를 업데이트 해줘야 하는 일들이 발생하곤 했는데,그럴 때마다 내가 짠 쿼리는 참 오래 걸렸다.차장님한테 여쭤보니, 인덱스는 만들었냐고 물으셨다.그렇구나 인덱스가 필요하구나 !인덱스KEY + VALUE인덱스의 탐색수직적 탐색 시작점 검색 Random AccessROOT : 최상위 노드 BRANCH : ROOT & LEAF 의 연결고리 LEAF : KEY + Rowid (블록주소) > leaf node는 정렬되어 있음Root > Branch > Leaf수평적 스캔Sequential AccessLeaf Block의 시작점 ~ 종료점 까지테이블 Rand..

오픈소스DB 얼마전 회사에서 운영하선 시스템이 오픈소스DB로 DB를 전환했다. 기존에 사용하던 Oracle에서 PostgreSql로 일부 DB가 변경되었다. 이에 따라 짜여져있던 쿼리들을 기존 Oracle 문법에서 PostgreSql 문법으로 전환해야 하는 부분이 많이 발생하여 문법적차이를 정리해둘 필요성을 느껴 정리를 한다. 개인적으로 DB에 로직이 많이 있는 경우엔, PostgreSql이 알맞은 DB인지에 대해 조금 의문이 들었다.포스트그레에선 한 트랜잭션이 실행된 후, 해당 트랜잭션이 종료되기 전까지는 락이 걸려 다른 쿼리가 실행되지 않는다. 이로 인해, 운영을 하는 데에는 다소 불편함이 존재하고있다. 물론 이렇게 느끼는 데에는, DB만 도입했을 뿐, DB의 특성을 고려하지 못하고 전환을 했다는 ..

PostgreSQLThe PostgreSQL Global Development Group에서 개발하는 오픈 소스 ORDBMS. 1996년에 첫 출시되었다. 처음에는 BSD 라이선스였으나 현재는 MIT 라이선스 비슷한 독자적 라이선스를 따르고 있다. 공식 발음법은 '포스트그레스큐엘'이라고 한다. PostgreSQL에는 Vacuum이라는 개념이 존재한다. PostgreSQL에선 Vacuum을 잘 이해하고 적절히 관리하는 게 중요하고 회사에서도 주기적으로 버큠작업을 해주고 있다.버큠 관련 내용은 우형블로그 참고 (https://techblog.woowahan.com/9478/)튜플 정보 확인 (live tuple / dead tuple 확인)SELECT n.nspname AS schenma_name , c...