본문 바로가기

소프트웨어-이야기/데이터 저장소 + 시각화

UUID와 increment PK는 언제 사용해야할까? 1. 기본키로 UUID를 사용할 때 오는 이점 테이블의 기본키로 UUID를 사용하는 방법은 3가지 이점이 있다. (a) 데이터베이스가 여러 개인 경우, 하나의 ID가 여러 데이터베이스에서도 고유한 값이라고 볼 수 있다. 이러한 전제가 있으면, 서로 다른 테이블에서 관리되던 데이터를 하나의 데이터 소스로 합치기 쉽다. 예를 들어, 뉴스 콘텐츠 테이블이 1개가 있고, 이를 검색 엔진 (ElasticSearch)에 복제하고 있다고 가정해보자. 이후, 잡지 콘텐츠 테이블이 필요하게 되어, 이 정보를 동일한 ElasticSearch에 추가해야하는 상황이 왔다고 상상해보자. 두 테이블이 숫자 기반의 pk를 사용하고 있었다면 두 콘텐츠의 ID가 충돌나는 현상이 발생하게 된다. 이 때문에 두 테이블을 하나의 소스에 합..
(PostgreSQL) AWS PostgreSQL RDS에 Transaction ID Wraparound 알럿 설정하기 본 글에서는 Amazon RDS for PostgreSQL에서 transaction ID의 상태를 모니터링하는 방법과 주요 문제를 해결하는 일반적인 방법에 대해서 설명하고자 한다. 이 글은 AWS Database blog에 포스팅된 Implement an Early Warning System for Transaction ID Wraparound in Amazon RDS for PostgreSQL 을 번역하여 정리한 글이다. transaction ID란? PostgreSQL은 vacuum 없이 21억여 개의 트랜잭션까지 처리할 수 있다. 만약 vacuum 없이 처리된 트랜잭션의 수가 2^31 - 10,000,000에 도달하게 되면, Postgresql은 베큠이 필요하다는 로그를 남기기 시작한다. 그리고 (..
(PostgreSQL) Truncate TABLE VS delete TRUNCATE란? TRUNCATE는 대용량 테이블을 빠르게 지울 수 있는 명령문이다. Truncate VS Delete DELETE 쿼리는 테이블의 데이터를 제거할 때 사용하는 쿼리이다. 그런데 전체 데이터를 삭제할 때에는 DELETE 쿼리는 효율적이지 않다. 이때에는 TRUNCATE TABLE을 사용하는 것이 좋다. TRUNCATE TABLE는 테이블 스캐닝 없이 전체 데이터를 지우기 때문에 DELETE 쿼리보다 빠르다. 그리고 스토리지를 바로 회수하기 때문에 VACUMM 작업을 수행할 필요가 없어서, 대용량 데이터를 제거할 때 유용하다. 사용법 TRUNCATE TABLE public.recommend_products; 테이블 식별 값(Primary Key)을 리셋시키고 싶은 경우에는 아래와 같이 질..
elasticsearch와 RDB 데이터 저장하기 #시작 오늘은 엘라스틱서치 기술 블로그에서 흥미롭게 읽었던 자료를 함께 살펴보는 시간을 가져보려고 합니다. 설명드릴 블로그 포스팅은 Keeping Elasticsearch in Sync입니다. https://www.elastic.co/kr/blog/found-keeping-elasticsearch-in-sync#the-bulk-api-a-must-for-most-applications Keeping Elasticsearch in Sync One of the trickiest parts of integrating Elasticsearch into an existing app is figuring out how to manage the flow of data from an authoritative data ..
(PostgreSQL) Array Field 인덱스를 사용할 때 고려할 점 최근, PostgreSQL의 Array 데이터 타입을 사용하자는 설계 아이디어를 검증하기 위해 찾아본 자료를 정리해보고자 한다. 간단히 요약하자면, Array 데이터 타입에 인덱스를 추가하는 것은 잘못된 설계가 될 수 있다는 점이다 😳 배경 최근에 게시물에 태그를 추가하고, 태그로 게시물을 조회하는 기능을 구현해야했다. 게시물에 추가된 태그는 저장된 순서 그대로 조회가 가능해야했다. 아이디어 위의 기능을 위해 "게시물에 저장된 태그를 Array 데이터 타입"으로 저장하자는 아이디어가 제안되었다. Array 타입에 인덱스를 추가하는 것에 호의적이였던 이유 PostgreSQL의 Array 데이터 타입을 사용하자는 아이디어는 아래와 같은 편의성 때문이였다. 1. 태그 목록을 저장하고, 읽기가 용이하다. 게시물..
(PostgreSQL) PostgreSQL Client Tool 비교하기 나는 PostgreSQL Client 유목민이다 🐎🐎 그러던 중 PostgreSQL Client 비교한 글을 읽어봤는데, 꽤 유용했다! 적당한 툴을 찾지 못해서 PGAdmin, Psequel를 혼용해서 사용하고 있었는데, 이제는 TablePlus으로 정착하려고 한다. PostgreSQL Client에 정착한 기념으로, 이번 포스팅에서 PostgreSQL Client Tool 을 정리해보고자 한다. 1. TablePlus ★★★★★ 한줄평 짱이다. 일단 설치해야한다. 장점 이쁘다. 탭 전환이나 데이터가 보여지는게 빨라서 가볍게 느껴진다. 그럼에도 불구하고 기능이 많다. Query Formmating 기능이 있다. 탭을 가로로 나눌 수 있다. 쿼리 자동완성 기능도 있다. 필터 기능이 있다. 데이터 조회 Li..
(PostgreSQL) BRIN 인덱스 활용하기 BRIN 인덱스BRIN 인덱스는 Block Range Index의 약자다. BRIN 인덱스는 페이지의 메타데이터를 뽑아서 인덱스를 구성한다. 그래서 타임시퀀스한 대용량 데이터를 저장하고, 조회할 때 유용하다. 테이블은 여러개의 페이지들로 구성되어 있다. 비슷한 시기에 만들어진 로우는 같은 페이지에 위치하거나, 물리적으로 서로 근접한 위치에 있다. BRIN VS B-TREE BRIN 인덱스는 B-TREE 인덱스보다 쿼리 퍼포먼스가 좋다.그리고 BRIN 인덱스는, B-TREE에서 사용하는 용량의 1%만 사용한다. bb인덱스 생성 속도도 BRIN이 더 빠르다. 쿼리 퍼포펀스 비교해보기대용량 테이블을 만들고, BRIN / B-TREE 인덱스를 추가해서 각각의 퍼포먼스와 디스크 사용량을 비교해보겠다. 1. 샘플데..
(PostgreSQL) 쿼리 실행계획 비쥬얼라이징하기 1. PgAdmin에서 실행계획 비쥬얼라이징하기PgAdmin에서 질의 쿼리 앞에 EXPLAIN (ANALYZE, COSTS, VERBOSE, BUFFERS, FORMAT JSON) 쿼리를 추가해주면, 손쉽게 쿼리 실행계획을 비쥬얼라이징해서 볼 수 있다. PgAdmin QueryTool > Explain Tab에서 결과를 확인할 수 있다. Index, Join 방식 등도 비쥬얼라이징해주기 때문에, 복잡한 실행결과를 한눈에 파악하는 데에 도움이 된다. 이런식으로! (참고 - READING PGADMIN GRAPHICAL EXPLAIN PLANS) 2. tatiyants > Pev에서 실행계획 비쥬얼라이징하기tatiyants의 PEV를 사용하면, 온라인에서 실행결과를 비쥬얼라이징할 수 있다.PEV 링크 EXP..