본문 바로가기

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

(PostgreSQL) 슬로우쿼리를 잡아내는 3가지 방법 해당 글은 Weekly Postgres에서 보내준 3 WAYS TO DETECT SLOW QUERIES IN POSTGRESQL을 보고 정리한 글입니다 😀 슬로우쿼리를 잡아내는 3가지 방법PostgreSQL에서 슬로우쿼리를 잡아내는 방법은 크게 3가지가 있다.1. 슬로우 쿼리가 발생하면 로그 남기기2. 쿼리 실행계획 로그에 남기기3. 쿼리 실행 통계 보기 1. 슬로우 쿼리가 발생하면 로그 남기기어느정도 느려지면, 쿼리 실행문을 로그에 남길건지 postgresql.conf에 설정값을 추가해줘야한다.1log_min_duration_statement = 5000 그리고 config를 reload 해주면 된다.12345postgres=# SELECT pg_reload_conf(); pg_reload_conf -..
(ElasticSearch) 엘라스틱서치에 데이터 싱크하기 ( 4 ) - 안티패턴과 멱등성 관리 이 글은 [elastic] Keeping Elasticsearch in Sync 문서를 정리한 글 입니다 ㅎㅅㅎ 엘라스틱서치에 원본 데이터를 싱크할 때, 주의해야하는 점이 있다. Why Marking Source Records is an Anti-Pattern엘라스틱서치 인덱싱 필요 여부를 체크하는 방법 중, 원본 테이블에 필드를 하나 추가하는 방법이 있다. 그런데 이건 안티패턴이다. 하면 안된다. 안티패턴인 이유 1. 엘라스틱서치 데이터 복제와 원본 데이터 간의 커플링이 높아진다. 그러면 유지보수가 어렵다. - 장애로 실제 인덱싱 여부와 원본 데이터에 저장된 인덱싱 여부가 달라질 수도 있다. 2. 전체 테이블을 재인덱싱해야하는 경우, 전체 테이블을 업데이트해줘야한다. UPDATE SET reindex=..
(ElasticSearch) 엘라스틱서치에 데이터 싱크하기 ( 3 ) - Batching Based on Ranges 이 글은 [elastic] Keeping Elasticsearch in Sync 문서를 정리한 글 입니다 ㅎㅅㅎ 이전글 ((ElasticSearch) 엘라스틱서치에 데이터 싱크하기 ( 2 ))에서는 계속 변경되는 데이터를 엘라스틱서치에 싱크하는 방법에 대해서 설명했다.이번에는 Immutable한 데이터를 엘라스틱서치에 추가하는 방법에 대해서 설명하고자 한다. Batching Based on RangesImmutable한 데이터의 예시로는 로그가 있다. 로그는 한번 추가되어도, 변경되지 않는 데이터다. 그래서 이 경우에는 ElasticSearch에 Insert만한다. Update는 필요하지 않다. 이 경우, 큐를 이용해서 배치에 사용될 데이터를 가져오는건 오버스펙이다. 단순하게, 데이터를 가져와야하는 범위..
(ElasticSearch) 엘라스틱서치에 데이터 싱크하기 ( 2 ) - Using Queues to Manage Batches 이 글은 [elastic] Keeping Elasticsearch in Sync 문서를 정리한 글 입니다 ㅎㅅㅎ 이전 글에서는 엘라스틱서치에 저장된 문서를 업데이트할 때, Batch로 한번에 업데이트하는게 효과적이라는 내용을 살펴봤었다. - (ElasticSearch) 엘라스틱서치에 데이터 싱크하기 ( 1 ) 이번 글에서는 Batch로 한번에 업데이트할 문서 정보들을 원본 데이터에서 가져오는 방법에 대해서 정리해보려고 한다. Using Queues to Manage Batches배치로 데이터들을 일괄 업데이트하려면, 수정해야하는 데이터들만 골라서 가져와야한다. 이 때 큐를 사용하면 효율적으로 관리할 수 있다. 큐 대기열을 관리할 저장소로는 SQL 테이블, Redis Sorted Set 등을 사용할 수 있..
(ElasticSearch) 엘라스틱서치에 데이터 싱크하기 ( 1 ) - The Problems of Too-Frequent Updates and Non-Batch Updates 이 글은 [elastic] Keeping Elasticsearch in Sync 문서를 정리한 글 입니다 ㅎㅅㅎ ElasticSearch은 검색엔진 목적으로 많이 사용된다. 그래서 원천 데이터들은 RDB / NoSQL DB에 저장하고, 제2의 데이터 저장소로 ElasticSearch를 사용하는 경우가 많다. 그래서 원천 데이터를 ElasticSearch으로 옮기는 작업이 필요하다. 이 글에서는 DB와 엘라스틱서치를 효율적으로 싱크시키는 방법에 대해서 정리하고자 한다. 데이터를 복제뜨는 방법은 크게 2가지가 있다. A. 실시간으로 데이터 싱크하기 ( sync )B. 배치로 데이터 싱크하기 ( async ) A. 실시간으로 데이터 싱크하기 문제 1 - 엘라스틱서치 트래픽 증가건바이건으로 엘라스틱서치 데이터를..
(PostgreSQL) Default 값이 있는 새로운 필드 추가하기 Default 값이 있는 새로운 필드 추가하기ALTER TABLE orders ADD COLUMN price bigint NOT NULL DEFAULT 0; PostgreSQL 10 이하 버전에서는 테이블에 Default 값이 있는 필드를 추가할 땐 주의해야한다. Default값이 있는 필드를 추가할 때, 테이블을 다시 만들어내기 때문이다!그러면 시간도 오래걸리고, ACCESS EXCLUSIVE LOCK도 잡게 된다. ( 참고 - Fast Column Creation with Defaults )ACCESS EXCLUSIVE LOCK이 걸려있는 동안, 이 테이블에 대한 모든 트랜잭션은 BLOCK된다! SELECT 쿼리까지 막힌다! ( ACCESS EXCLUSIVE LOCK LEVEL은 LOCK LEVEL ..
NoSQL 도입 시 고려사항 컬럼패밀리 기반 - Cassandra - 노드가 추가될 때, Mongo DB보다 더 선형적으로 성능이 좋아진다. ( 참고 - NoSQL 비교(카산드라, HBASE, MongoDB )- 타임시퀀스한 데이터를 저장할 때 좋다. - 데이터를 삭제해도, 내부적으로는 삭제한 데이터도 읽어들여서 데이터가 많아지면 성능이 좋진 않다. 그리고 클러스터링 이슈로 지워졌던 데이터가 다시 살아날 수도 있다. ( 참고 - Apache Cassandra 톺아보기 3편 - Delete Data )- 페이지네이션 카산드라에서 페이징을 구현하는건 쉬운 일은 아니다. 하나의 Row에 속한 컬럼은 이미 정렬되어있어서, 한 Row에 대한 페이징은 가능하다. 그런데 Row Key는 해시키로 관리되기 때문에, Row Key 단위의 페이징을 ..
(PostgreSQL)Idle in transaction 프로세스 자동으로 죽이기 문제 상황postgresql에서 transaction이 잡혀있지만, 아무것도 하지 않으면, 세션의 상태는 idle in transaction이 된다. 그런데 얘가 connection은 쥐고 있지만, 아무것도 안한다면 서버 자원을 잘 활용하지 못하게 된다. ( 참고 - (Django)PostgreSQL의 Idle In Transaction Connection )그러면 connection이 무한대로 늘어난다거나, connection이 필요한애가 DB를 제대로 활용하지 못하게 될 수 있다. 해결 방법postgresql에는 Idle in transaction이 일정 기간동안 유지되면 자동으로 이 transaction을 죽여주는 기능이 있다. idle_in_transaction_session_timeout 옵션을..