Computation suite

Binary type은 이미지, 파일, 비디오 파일과 같은 이진 데이터를 저장할 수 있는 저장 공간을 제공한다. (Blob) 일반적으로 이런 파일을 저장하는 서버는 RDBMS를 사용하지 않고 파일을 서빙하는 파일 서버를 따로 둔다. RDBMS는 데이터 집합 간의 Relation과 ACID를 보장하는 작업에 특화되어있기 때문에 파일 서빙 요청보다는 데이터베이스 쿼리와 관련된 트랜잭션을 수용하는 것이 더 이득이다. 이미지와 동영상 같은 크기의 파일을 DB에 BLOB형태로 저장할 시  - 읽기/쓰기 속도가 떨어진다.   파일 전송이 끝날 때까지 DBMS 자원을 소모하므로,   파일 데이터의 연속적인 Fetch 작업에   DB 자원을 소모하는 것은 비효율적임.   파일의 크기는 쓰는 속도에도 영향을 미친다. 그런데 이 Binary Type이 존재하는 이유가 무엇일까? 1. 1MB 미만의 작은 사이즈의 파일을 서빙할 때 2. DB의 보안이 반드시 필요한 파일 데이터. 1의 의미도, 1MB 미만의 파일은 DB에 저장해도 좋다는 뜻은 아니고  그만큼 작은 파일이라도 제한적으로 사용해야 한다는 뜻이다. blob 적용 - raw data를 표현할 때 blob을 사용하는 경우는 찾아보기 힘들었다. 대체 방법 - 낮은 해상도의 단순한 이미지라면   DB에는 단순한 이미지에 대한 메타 정보만 저장하고   메타 정보를 바탕으로 FE or Mobile에서 렌더링하는 것이 이득이다. - 이전 프로젝트에서 Social profile image를 구현할 때   위와 같이 이미지가 단순한 조합으로 이뤄지므로   이를 이용하여 프로필 이미지를 저장하는 파일 서버를 두지 않고    DB의 Profile table에 profile image를 위와 같이 메타정보만 저장했다. 결론 - RDBMS를 꼭 사용해야 할 Use case가 아니라면 파일 서버를 이용한다. - Blob으로 취급할 ...

케이스 단순화를 위해서 회원 탈퇴 시 , 회원 인스턴스를 사용불가 처리하는 것이 아닌 관련된 정보까지 삭제한다고 가정하겠습니다. 비즈니스 로직 요구사항에 따라  - 회원 정보를 일정 기관동안 보관해야 할 때, - 복귀를 대비한 휴면 처리  로 인해 즉시 지우지 않을 수 있음, 배치작업 성능 회원풀이 조금이라면 모르지만 어느 정도 서비스 규모가 성장했을 때 회원탈퇴 시 실행해야하는 개인정보삭제 작업은 서비스 지연을 초래할 수 있다. 예를 들어,  프로덕션 환경에서는 이 개인정보 삭제 작업 때문에 Lock이 설정되다보면 다른 트랜잭션의 수행이 지체될 수 있다. row level에서 lock level이 타협되거나 관리할 lock 리소스가 적당하다면 상관없겠지만 다음과 같은 lock level과 trade-off 관계를 고려해야한다. Lock level ( sql server 기준 ) 낮음 row level : 변경하려는 row(RID)에만 lock 설정 page level : 변경하려는 로우가 담긴 page(or index)에 lock 설정 extent level :  extent 전체가 잠김 table level : table과 table과 연관된 인덱스가 잠김 database level : db 전체가 잠김. (db 복구작업 및 스키마 변경시 발생) 높음 Trade-off 관계 1. locking level이 낮을수록 관리해야 할 lock 개수는 많아지고 -> 시스템 리소스를 더 많이 소비한다. 2. locking level이 높을수록 관리해야 할 lock 개수는 적다. -> 시스템 리소스를 덜 소비하지만 동시성이 낮아진다. 이를 방지하기 위해 사람들의 접속이 적은 새벽시간대나 점검시간에 애플리케이션 서버를 닫은 뒤 작업을 수행한다.

도메인 optimistic locking은 db를 사용하는 애플리케이션 <-> db 사이의 동시성 관리 전략이다. distributed locking은 분산 시스템에서 사용하는 동시성 관리 전략이다. 사용 case optimistic locking은 같은 데이터 레코드를 여러 세션 이 동시에 갱신할 때 사용한다. distributed locking은 공유 자원을 여러 노드(다른 machine) 에서 접근할 때 사용한다. 작동원리 optimistic locking은 데이터 버저닝/타임스탬프, 예외처리를 사용한다. distributed locking은 centralized, token, quorum 등 다양한 알고리즘을 사용한다. 충돌 가정 optimistic locking은 충돌이 드문 상황을 가정한다. (사용자들이 같은 Data를 동시에 수정하지 않을 것) distributed locking은 잦은 충돌을 염두에 둔다. 이상적인 분산락 조건 1. 상호 배제 - 한 번에 하나의 노드만 lock을 얻을 수 있다.  2. Fault tolerance - node가 실패한다면 lock은 사용불가능한 상태가 돼야함. 3.효율성 - lock을 acquire/release 과정이 효율적일 것. 4.공평성 - 노드들은 lock을 공평하게 획득해야함. 분산락 알고리즘 centralized locking single node가 central lock manager 역할. - 구현 쉬움 - single point of failure 문제 token-based locking node에 unique한 token이 전달되고 token을 들고있는 node만 공유 리소스에 접근 가능. - fault tolerance - complex to implement   (token expiration, token 유실을 대비해야함) quorum based locking(Redlock: redis 알고리즘) 1. T1 값 획득( = 클라이언트의 현재 시각 기록) 2. SE...

Dead lock 운영체제에서의 dead lock과 같은 맥락으로 DB 런타임에서 dead lock은  세션 a, b 중 하나가 뒤로 물러서지 않으면 리소스에 대한 lock이 풀리지 않는 상태를 말한다. lock 구현은 벤더마다 구현이 다르다. sql server에서는  - 갱신 update lock - 의도 lock - schema lock이 있다. oracle에는 - 로우 lock - table lock이 있다. 트랜잭션 격리성 수준 개인적으로 lock level이 더 잘 와닿음. 트랜잭션을 격리하기 위해  DB에서 취급하는 자료구조에 lock을 거는 범위가 계층화 되어있는데  이를 lock level이라고 함.  lock level Row level : RID에만 lock Page level : 변경하려는 page에 lock // page에 속한 row 모두 lock Extent level :  Table level : table 전체와 관련 index에 lock Lock escalation 관리할 lock 리소스가 정해진 임계치를 넘으면 row -> page -> extent -> table -> db 락으로 점점 확장한다. 상위 레벨의 lock이 걸린 경우 하나의 lock으로 수많은 레코드를가 한 꺼번에 잠긴다. - lock level이 낮을수록 동시성이 좋음. - lock level이 높을수록 동시성이 떨어짐. - 관리해야할 lock 개수 증가하면, 리소스 증가 Trade Offs 트랜잭션 격리성을 높이기 위해서는 Lock을 오래 유지하면 된다. 그러나 Lock을 오래 유지하면 동시성이 떨어진다. 낮은 단계 격리성의 문제점 1. Dirty read : 비일관성. 커밋하지 않은 데이터를 읽는다. 2. Non-repeatable read : 다른 트랜잭션의 작업에 의해 read 결과가 다르게 나타남   3. Phantom read : 1번째 쿼리에 없던 recor...

다중 트랜잭션 환경에서 Lock과 직렬화 다중 트랜잭션 환경에서는 같은 자원에 액세스하는 트랜잭션들이 동시에 발생할 수 있다. 같은 자원에 액세스하는 트랜잭션들이 동시에 발생해도 순차적 보장을 위해 직렬화 작업 이 필요하다. 이 직렬화 작업 에 필요한 요소가 Lock 이다. Read session, Write session 등이 Lock을 획득하기 위해 Lock queue에 대기한다. Share lock, Exclusive lock share lock share lock은 데이터를 읽을 때 사용된다. - 다른 share lock과 호환 가능하다.    -> 자신이 읽고있는 리소스를 다른 사용자가(타 세션) 동시에 읽을 수 있다. - exclusive lock과 호환되지 않는다.   ->자신이 읽고있는 리소스를 다른 사용자가(타 세션) 동시에 수정할 수 없다. exclusive lock exclusive lock은 데이터 변경 시 사용된다. 트랜잭션 완료 시까지 유지되며, 동시에 다른 Tx이 읽거나 쓸 수 없다. Blocking 동시에 같은 데이터에 대해 2개의 읽기 요청이 수신된다면 share lock x share lock 상태이므로 blocking이 발생하지 않습니다. 반면, 동시에 같은 데이터에 대해 wirte - read 요청이 순차적으로 수신된다면 exclusive lock x share lock이 순차적으로 발생하므로 write 작업이 끝날 때 까지 read 작업이 blocking되어 읽을 수 없습니다. write-write 요청도 마찬가지입니다. Blocking 작업이 해소되려면 선행하는 write 작업이 commit이나 rollback 돼야합니다. Lock으로 인한 성능 저하 최소화 방안 곧, Blocking 으로 인한 대기시간이 최소화가 되는 방안과 같은 말입니다. 일반적으로 Blocking이 적게 일어나면 대기 시간을 줄일 수 있습니다. 이를 위해서는 - Tx을 가능한 한 짧게 유지해야함. - 같은 데이터...

데이터베이스 설계 개념적 설계 - 논리적 설계 - 물리적 설계 이전에 중요한 단계가 하나 더 있다. 요구 명세 단계 바로 요구 명세 도출 작업인데, 데이터베이스 이용자들(클라이언트 엔드 포인트, 웹 애플리케이션 서버 등)이 필요로 하는 데이터를 규정하는 작업이다. 도메인 전문가들이 참여하여 요구사항을 도출하며 산출물은 문서가 될 수도 있고, 다이어그램의 형태가 될 수 있다. 따라서, 데이터베이스 설계 단계를 나누자면 다음과 같다. 요구명세 도출 - 개념적 설계 - 논리적 설계 - 물리적 설계 개념적 설계 단계 개체-관계 모델이 생성되며 중복, 충돌 등이 발생하는지 체크를 위해 스키마를 검토할 수 있다. 저장 방식이 아닌 관계에 집중한다. 기능적 요구사항 명세서가 생성된다. 데이터에 적용될 연산/트랜잭션의 종류가 기술된다.(CRUD 작업) 이 이후부터는 개념적 설계 단계에서의 추상 데이터 모델이 실제 데이터베이스 구현으로 이어진다. 논리 설계 단계 논리 설계 단계에서는 상위 개념적 스키마를 데이터베이스의 데이터 모델에 대응시킨다. 개념적 스키마(주로 E-R모델)을 관계형 스키마로 대응시킨다. 물리 설계 단계 물리적 설계 단계에서는 파일 구성 형식 및 인덱스 구조에 대한 선택을 수행한다. 데이터베이스의 물리적 스키마는 DB와 통신하는 응용 프로그램이 개발된 후 상대적으로 쉽게 바꿀 수 있다. 하지만 논리적 스키마를 바꾸려면 1. 질의문 2. 응용 프로그램 코드 에 영향을 크게 줄 수 있으므로 설계 단계에 주의를 기울여야한다. 설계 주안점 중복성 정보의 반복. 왜 이것이 문제가 되냐하면, 불필요한 저장 공간 낭비 및 트랜잭션 발생 뿐 아니라 일관성에도 영향을 미칠 수 있기 때문이다. "정보가 수정될 때, 중복되어 저장되어있는 모든 복사본을 수정해야한다." 이 case에 대한 예방책을 일일이 만들기는 쉽지 않다. 때문에 정보는 정확히 한 장소에 위치시키는 것이 이상적이다. 불완전성 간단히 말하면 좋지 않은 설계. 분반 단일 릴레이션과 수업-분반 관계...

Subquery란 SQL문 안에 포함돼있는 SQL문을 말한다, Mainquery가  Subquery를 포함하는 관계이다.  Subquery에서 Mainquery는  Subquery의 칼럼을 사용할 수 없다. Join은 연산에 참여하는 두 집합간의 Product 관계이다. 모든 테이블이 대등한 관계에 있기 때문에 어느 위치에서든 연산에 참여하는 테이블의 칼럼들을 사용할 수 있다. 결과는 동일하게 가져올 수 있으나  DB내에서 수행되는 로직은 다르다. Subquery를 써야할 때 Join을 사용하거나 Join을 사용할 때 Subquery를 사용하는 경우 DB가 불필요한 연산과 블록 액세스 작업을 수행할 수 있다. 그렇다면 무엇을 기준으로 Join이 적합한 연산, Subquery가 적합한 연산임을 판단할까? 결과 집합의 레벨이 무엇인 따져본다. Subquery의 결과 집합은 항상 Subquery를 감싸는 메인 쿼리의 레벨로 귀결된다. Join의 결과 집합은 어떤 테이블 관계냐에 따라 다른데, 1:1 -> 1 x 1 = 1 레벨 집합 1:N -> 1 x N = N 레벨 집합 N:M -> N x M = N x M 레벨 집합 의 결과가 나온다. 결과의 집합 레벨을 기준으로 Join을 사용할지 Subquery를 사용할지 결정한다. 만든 예시) A시의 투표소 목록을 출력 SELECT STATION_NAME AS 투표소명, LATITUE AS 위도, LONGITUDE AS 경도 FROM POLLING_STATION WHERE CITY_ID= (SELECT CITY_ID                                     FROM CITY           ...

본 게시글은  'NoSQL 프로그래밍 Professional NoSQL : A hands-on guide to leveraging NoAQL Databases'를 읽고 정리한 글입니다. 해당 서적은 NoSQL 입문서로 기존 SQL과의 비교가 잘 되어있다. NoSQL 개념이 왜 등장했고 왜 빅데이터와 관련있는지 NoSQL, SQL의 차이점을 각 실습 파트의 초입부에 설명하면서 잘 와닿게 설명하고있다. 다만 2013년에 출판된 책인만큼 24년의 기술과 차이를 생각하면서 읽는 것이 좋다고 생각한다.

Primary key  CREATE TABLE IF NOT EXISTS product_type_code(     product_type_id char(8) PRIMARY KEY not null,     product_type_name char(100),     created_at timestamp default current_timestamp.     created_by varchar not null default current_user,     updated_at timestamp default current_timestamp,     updated_by varchar default current user, ) 예시 create table 스크립트에서는 trigger 예제를 제외하였다. updated_at 필드가 current_timestamp로만 찍히는 걸로 보일 수 있으나 row 데이터 update시 updated_at필드가 update 시각으로 변경되는 trigger와 procedure(function)를 추가하면 된다. Foreign key CREATE TABLE IF NOT EXISTS product(     product_id char(8) PRIMARY KEY not null,     product_type_code char(8) not null,     product_name char(100),     ...           constraint fk_product_type_code FOREIGN KEY(product_type_code) references                    product_type_code(pro...

DB설계 툴로 DBeaver와 psql이라는 SqlShell을 사용하고 있다. 테이블이 잘 만들어졌는지, 테이블에 올바른 Trigger와 함수가 걸려있는지  확인하기위해 Dbeaver의 SQL편집기에서 pg_catalog 테이블을 참조하지만 간혹 psql의 간단한 명령어로도 원하는 정보를 볼 수 있어서  psql도 같이 켜놓고 이용하고 있다. psql command shell을 활용하는 방법 자주 쓰는 커맨드 정리 \dft 함수목록을 보여준다. \dS 테이블이름 테이블의 column 정보, 인덱싱이 어떻게 되었는지, 걸린 Trigger 등을 보여준다. postgres 에서는 trigger를 삭제할 때 반드시 trigger가 걸려있는 테이블을 지정하도록 한다. 하지만 이는 표준 SQL문법이 아니다. 표준 SQL에서는 테이블 이름을 지정하지 않고  DROP TRIGGER를 통해 Trigger를 삭제한다고 한다.  postgresql sql query로 열람하는 방법 전체 테이블 당 전체 trigger 열람 SELECT  event_object_table AS table_name ,trigger_name          FROM information_schema.triggers   GROUP BY table_name , trigger_name  ORDER BY table_name ,trigger_name  특정 테이블의 전체 trigger 열람 SELECT  event_object_table AS table_name ,trigger_name          FROM information_schema.triggers WHERE event_object_table ='테이블 명'  GROUP BY table_name , trigger_name  ORDER BY table_name...

SELECT * FROM pg_catalog.pg_tables where schemaname = 'public'; postresql은 내부적으로 pg_catalog를 통해서 관리용 정보, meta정보들을 테이블 형태로 관리한다. 사용자가 서비스를 구현하기 위해 직접 관리하는 테이블은 아니라는 의미에서 내부적이라는 용어를 사용하였음. schemaname에는 'public'이외에도 'pg_catalog','information_schema'가 존재

Function, Trigger 관리는 번거롭다, 하지만... DB를 관리하는 입장에서는 사용자가 생성한 Function과 Trigger가 많다면 이것또한 비즈니스 로직 및 시스템 구조 변경시 관리할 대상이 된다. git으로 모듈, 코드의 버전 관리를 하는만큼  DBA는 Function, Trigger를 관리하는 것이다.  때문에 처음에는 최대한 내부 Function이나 Trigger를 두지 않고 차라리 history테이블을 하나 더 만드려고 했다. 하지만 테이블 field에 row가 생성된 날짜, 생성한 user 이외에 row의 데이터에 변경이 일어났을 때도 기록하기 위해 updated_at, updated_by field를 추가하려고 했더니  postgre에는 데이터 갱신 날짜를 추적해주는 함수는 없었다. 그래서 데이터 갱신용 function과 trigger를 만들었다. A 테이블에서 ROW 데이터를 갱신시, 언제, 누군가에 의해 갱신됐는지도 기록하려한다면 A 테이블에 ROW 데이터를 갱신시 TRIGGER 될 TRIGGER를 만들어야한다. 그리고 그 A 테이블에 걸린 TRIGGER가 실행할 FUNCTION을 만들어야한다. 1. TRIGGER가 실행할 FUNCTION에 맞는 FIELD 설정에 맞는 테이블 생성 2. TRIGGER가 실행할 FUNCTION 생성 3. TRIGGER 생성 FUNCTION의 재사용 A 테이블 이외의 B,C,D,...등의 테이블에도 똑같은 로직이 필요하다고 한다면 FUNCTION을 그대로 두고 TRIGGER를 해당 테이블에 걸어주면 된다. $$ 표현 create or replace function update_history() returns trigger as $$ begin new.updated_at = NOW(); new.updated_user = CURRENT_USER; return new; end; $$ language plpgsql; 여기서 $$표현은 FUNCTION을 정의할 때 시작과 끝...

<원격DB 연결> AWS Postgresql RDS에 연결한다고 가정하면 server host에 aws 리소스 이름(ARN) db 이름 db에 설정한 password를 입력. connection test가 성공적이면 정상연결 된 것. <원격DB 연결 실패> 연결 실패시, 인코딩 문제가 있는 에러 메세지가 뜨는 경우가 있는데 대부분 에러 메세지 내용은 db를 public으로 설정해놓지 않았거나, remote db로 들어오는 인바운드 규칙에서 필터링 되어 생기는 연결 실패 문제. remote db setting에서 vpn 설정, access 설정을 손 봐야한다. <로컬DB 연결> remote db가 아니라 local에 db를 생성하여 연결하는 것을 의미한다. project의 connection에서 각 SQL에 맞는 Port를 알아서 지정해준다. (postgre : 5432) local host이므로 DBeaver 설치시 입력했던 admin용 password를 입력해야 정상적으로 연결된다.  <로컬DB 연결실패> (pgjdbc: autodetected server-encoding to be ISO-8859-1, if the message is not readable, please check database logs and/or host, port, dbname, user, password, pg_hba.conf) 1. pg_hba.conf 파일 수정  에러가 뜬다면 pg_hba.conf 파일을 열람해본다. 보통 경로는 C:\Program Files\PostgreSQL\12\data이다. hba = host-based authentication, conf = configuration의 약자이다. 클라이언트 인증에 쓰이는 파일의 이름은 pg_hba.conf이며 데이터베이스 클러스터의 데이터 디렉토리에 저장되는 환경 설정 파일로 제어된다. pg_hba.conf 파일은 디렉토리가 initdb에 의해 초기화 될 때 ...

Dbeaver에서 프로젝트를 만들고 postgreDB로 connection 설정시, 로그인 오류가 발생할 때가 있다. (pgjdbc: autodetected server-encoding to be ISO-8859-1, if the message is not readable, please check database logs and/or host, port, dbname, user, password, pg_hba.conf) 원인 텍스트가 깨져서 보이기 때문에 텍스트 인코딩 문제같다고 생각했지만, 접근 권한 에러다. 서버 인코딩이 ISO-8859-1로 감지되었을 뿐이다. 해결법 pgAdmin 프로그램에서 접근 제한 설정(Login/Group 설정)을 해주어야한다. 여러 DB서버들 중 PostgreSQL12 서버의 'postgres'라는 db에 접근할 때,    Superuser 권한을 가진 유저를 하나 생성한 뒤, 이 유저로 접근하면 접근권한에러를 피할 수 있다.  또는  pg_hba.conf 라는 configuration 파일에서 local connection에 대한 정보( IP와 권한 )를 추가한다.

Data Lake - 모든 유형의 데이터를 유지하도록 설계된다. - 조직에서 대규모로 다양한 유형의 데이터를 생성한다. - 데이터에 기반하여 전략적 통찰력을 얻고 결정 하기 위해 데이터를 분석해야 하지만   어떻게 사용할지 확신할 수 없는 경우 사용한다. - 데이터를 분석할때는 데이터 엔지니어, 사이언티스트를 필요로 한다. 1.구조화된(관계형 데이터), 2.반구조화된(CSV 또는 JSON 파일), 3.원시적인(기계 및 센서 데이터) 형태로 저장된 비정형(기계 및 센서 데이터) 를 저장한다. DataLake는 내부 및 외부 소스의 데이터를 집계하고, 많은 다른 사용자에게 접근을 허용하여 보안 침해에 취약하다.   Usage(사용)                                    Advanced predictive analytics (고급 예측 분석) Time-to-market(출시 시기)             Weeks, months Cost(비용)                                        Very high Users(사용자)                                         Low Data growth(데이터 증가) ...

 DB에서의 view(뷰) - 가상 테이블의 일종 - 가상 테이블이기 때문에 물리적 저장소(이를 테면 Disk)에 적재된 데이터가 아니다. - 그렇기 때문에 실제 데이터를 가지고있지 않다. - 1개 이상의 기본 테이블로부터 유도된다. Example 휴대전화번호가 010로 시작하지 않는 고객들에게  번호 변경 권장 문자메시지를 보내기 위해 고객 정보 테이블에서 휴대전화번호가 010로 시작하지 않는 고객들을 뽑을 때 CREATE VIEW Non010(name, phone_number)  AS SELECT name phone_number  FROM User_Info WHERE not phone_number like 010__________ WHERE not phone_number like 010__________를 조건문으로 사용하게 된다면 010으로 시작하지 않는 고객 뿐 아니라 010-xxxx-xxxx의 자릿수를 만족하지 않는 고객까지 조회됨. 위와 같이 임시적인 작업들이나 기본 테이블의 내용을 변경하지 않고  미리 작업할 내용을 테스트 할 때 적재된 데이터들을 MODIFY 하기전 확인용도로 쓰일 수 있다.   <뷰의 보안> - 뷰마다 접근 설정을 할 수 있다.볼 수 있는 정보를 다르게 할 수 있다. - 사용자A는 접근 가능하게, 사용자B는 접근 불가능하게. - 권한과 관련이 많은 객체이다. <뷰의 재사용성> - 한 번 정의된 뷰는 다른 뷰를 만들때 재사용할 수 있다. - SELECT 문을 객체로 저장하여 Table처럼 사용할 수 있다. <뷰 삭제시> -  뷰는 한 번 생성되면 DDL을 통해 정의를 변경할 수 없다. - 변경이 필요한 경우 삭제후 생성해야함. DROP VIEW VIEW1 RESTRICT 다른 곳에서 VIEW1를 참조하고 있을 때, VIEW1 삭제 취소 DROP VIEW VIEW1 CASCADE  다른 곳에서 VIEW1를 참조하고 있을 때...

온라인으로 ERD를 설계할 수 있는 사이트들이다. Aquerytool : https://aquerytool.com/ QuickDB : https://app.quickdatabasediagrams.com/

 aggregate function(집계 함수) 집계를 도와주는 함수. 집계 결과가 1개의 row에 나타난다. avg(salary) window function(윈도우 함수) 집계를 도와주는 함수. 각 row단위 마다 결과를 보여준다. 윈도우 함수 뒤에는 항상  OVER  절을 사용한다.  이 규칙은 이 함수가 윈도우 함수로 처리할 것인지, 그렇지 않을 것인지를 구분하는 문법상 규칙이다.   네번째 칼럼은  depname  칼럼 값을 기준으로 그룹화된 자료의 평균값을 각 로우마다 보여준다. OVER  절에는 윈도우 함수의 계산 대상이 되는 로우들을 집합화하는 방법을 정의한다.  PARTITION BY 로 정의하는 목록은 같은 그룹인지, 다른 그룹인지 구분하는 기준으로 사용되고,  같은 그룹 내에서는 현재 로우 값도 포함해서 계산 된 윈도우 함수의 결과값을 공유 한다. SELECT depname, empno, salary, avg(salary) OVER (PARTITION BY depname) FROM empsalary; empsalary 테이블에서  depname 기준으로 그룹화하여 OVER (PARTITION BY depname)  depname, empno, salary, avg(salary) 값을 조회한다. -> 그룹화된 자료들의 평균값인 avg(salary) PostgreSQL에서는 Aggregate function을 만들고, aggregate function을 window function처럼 사용할 수 있다. 윈도우 프레임 조절 및 자세한 원리는 자습서 참조. https://postgresql.kr/docs/9.5/tutorial-window.html

현업에서 다음과 같은 변수들을 고려하여 성능 개선 Plan을 고안했었다. (개인 경험) 1.쿼리 로직 1.1 쿼리가 어떤 작업을 수행하는지 1.2 쿼리가 왜 이 작업을 수행하는지 -> 쿼리 튜닝 (Full scan 테이블이 있는지, 불필요한 Column을 가지고오는지 등 ) 2. 핸들링하는 데이터량  3. Execution time, Elapsed time  4. 테이블 스키마(인덱싱이 걸려있는지, 키가 적합하게 설정되어있는지 등) 5. DB서버 설정 (Setting 값) 최악의 경우, 테이블 스키마를 수정하여 재구성.. 스키마 수정 후, 백업되어있던 데이터를 다시 추가하여 재구성해주어야함.

   delete 명령어 행이 삭제될 때 리소스 소모가 truncate에 비해 상대적으로 크다. -> how? trigger가 걸려있다면 행이 삭제될때마다 실행된다. 이전에 할당된 영역은 삭제되어, 빈 테이블이나 클러스터에 남는다. -> why?  truncate명령어 테이블의 모든 데이터를 삭제한다. delete와 비교하여 상대적으로 빠르게 데이터를 삭제한다. rollback 정보를 만들지 않으며 즉시 커밋한다. 때문에 한 번 truncate를 수행하면 rollback 할 수 없다. 행을 삭제할 때 trigger가 걸려있더라고 trigger를 실행하지 않는다. Truncate 옵션 postgresql의 truncate 옵션에는 다음 4가지가 있다. - RESTART IDENTITY : 타깃 테이블에 걸려있는 시퀀스(자동증가 값)을 재시작하면서 테이블 정보를 모두 삭제 - CONTINUE IDENTITY : 시퀀스 값 리셋 X, 데이터만 모두 삭제 - CASCADE : 타깃 테이블의 데이터를 모두 삭제하고 이 테이블과 연결된 데이터가 다른 테이블에 있으면, 다른 테이블의 데이터도 모두 삭제. 외래키 기준으로 다른 테이블을 참조할 때. - RESTRICT : 타깃 테이블에 연결된 데이터가 하나라도 있으면 데이터를 삭제하지 않는다. Postgresql에서의 delete, truncate 비교 database 사용자 입장에서는 똑같이 데이터를 삭제하는 작업처럼 보인다. 내부적으로는 다르게 작동한다. DELETE를 수행하고나면 -database pages 안에 dead rows가 남는다. -dead rows의 dead pointer가 색인에 남는다. 반면 TRUNCATE를 수행하고 나면 dead rows, indices(색인)이 비워지고 table 통계가 초기화된다. 신규 테이블을 생성할 때의 설정값과 비슷하게 구성됨.  -> 정확하게 어떻게 구성되는지는 공식문서를 보고 비교 해봐야한다. TRUNCATE는 작업하는데 ...