index(DB)에 대해(+pk, fk)

인덱스는 DB의 성능의 향상을 위해 쓰인다.

DB에서 테이블을 생성하거나 생성한 이후에도 인덱스를 설정할 수 있다. 혹은 pk를 설정하면 자동으로 걸리기도 한다.(대부분의 데이터베이스에서)

인덱스가 설정되어 있지 않으면 DB는 풀 스캔을 실행하는데, 이는 데이터 크기가 커질수록 낭비가 큰 방법이다.

데이터를 추가할 때마다 인덱스도 추가해야 하므로, 추가 혹은 변경보다는 검색이 많이 되는 컬럼에 인덱스를 걸어주는 것이 좋다.

인덱스와 pk의 차이점 : pk는 유일성을 반드시 보장해야 한다. 즉 열 간에 pk값이 중복되면 안되지만 인덱스는 중복을 해도 된다.

foreign key 는 테이블에 잘못된 데이터를 넣는 것을 방지하기 위한 제한조건이다. 테이블 중 하나 이상의 컬럼에 foreign키 조건을 걸 수 있는데, 조건을 걸 때 참고할 값으로 부모테이블의 pk를 설정하게 된다. 이후 데이터를 수정하거나 추가할 때 foreign키가 설정된 컬럼에다 부모테이블의 pk컬럼에 없는 값을 추가하려고 하면 불가능하게 되는 것이다.

unique index : 중복되지 않는 값을 가져야하는 인덱스. 다만 null은 가능.

pk : unique index + nonNull

Advertisements

기본 키(primary key)에 대해

1. 기술적인 의미

– 기본키는 다른 항목과 절대로 중복되어 나타날 수 없는 단일 값(unique)을 가집니다.

– 기본키는 절대 null(아무런 값이 없는 상태) 값을 가질 수 없습니다.

ex) 예를 들면 주민등록번호 같은 개념이죠. 동일한 이름을 가진 사람은 많을 수 있고,
동일한 날에 동일한 이름을 가진 사람도 존재할 수 있지만, 결국 그 사람들이 만나
서로의 민증을 대조해 보면…. 결국 다른 번호로 구분 됩니다.

– 기본키는 하나 이상의 컬럼이 그룹화 되어 키본키로도 쓰일 수도 있습니다.

– 테이블은 기본키를 하나까지만 가질 수 있습니다.

– 기술적 측면에서 기본키는 단일 값(Unique)하고 not Null(Null 값 비허용)이면 기능적으로 동일하게 동작은 하지만,
실제적으로 기본키처럼 구분되는건 오직 하나입니다. 즉, 다 똑같은 Unique하고 not Null 이라고 기본키가 되는게 아닙니다.
 – 관계형 DB 이론상 모든 테이블은 반드시 하나의 기본 키를 가져야 합니다.
    이런 룰을 PostgreSQL에서 꼭 그렇게 따라야할 필요는 없습니다만, 보통 따라주는게 최선입니다.

여러 시스템들을 컨설팅하면서 발견하는 문제점 중 하나는 primary key가 없거나 잘못 정의되어 있는 것입니다. Primary key를 제대로 정의하는 것은 데이터베이스 디자인에 있어서 매우 중요한 출발점입니다.

야밤에 잠도 안 오고 하여 기본 키(primary key)에 대해서 아주 기본적인(^^) 얘기를 몇 자 적어볼까 합니다.

Primary key란 행을 고유하게 구분해 주는 최소의 정보입니다. 모든 테이블에는 primary
key가 있어야 하며, 오직 하나의 primary key만 존재할 수 있습니다. 그리고 그 하나의primary key는 단일 컬럼으로 구성될 수도 있고 둘 이상의 다중의 컬럼들로 구성될 수도 있습니다. 만일 어떤 하나의 테이블에 primary key 역할을 할 수 있는 컬럼 또는 컬럼들의 그룹이 여러 개 있다면 그 컬럼 또는 컬럼들의 그룹을 candidate key라고 합니다. 하나의 테이블에 여러 개의 candidate key들이 존재할 수 있습니다. 가령 회원 테이블에 각각의 회원에게 고유하게 부여되는 (회원번호) 컬럼과 회원의 (주민등록번호) 컬럼, 그리고 회원이 회원가입 시에 선택하면서 회원별로 고유한 회원의 (로그인ID) 컬럼이 존재한다면 이 테이블에는 세 개의 candidate key가 존재하는 겁니다. 그렇지만 이 세 개의 candidate key 중에서 오직 하나의 candidate key 만이 primary key로 간택(^^) 받을 수 있답니다. 참고로 (회원번호) 컬럼을 primary key로 선택했다면 (회원번호) 컬럼은 회원 테이블의 primary key가 되는 것이고, primary key로 뽑히지 못한 (주민등록번호) 컬럼과 (로그인ID) 컬럼은 alternate key가 됩니다.

어떤 분의 블로그에 “다시 보자 기본키”라는 글이 있어서 한번 들어가 보았더니, 내용인즉슨 “무지 느려서 잘 보았더니 primary key가 없더라, 그래서 primary key를 만들어 주었더니 잘 수행되더라. Primary key의 유무가 무지한 성능 차이를 보이더라”는 내용의 글이었습니다. 여러분들 중에서도 테이블에 primary key를 만들어 주고 나니까 성능이 현저하게 향상되는 경우를 경험하신 분들이 계실 겁니다. 테이블에 primary key를 생성하면 성능이 현저하게 향상되는 것은, primary key를 정의하면 물리적으로 uniqueness를 보장하기 위하여 unique index가 만들어지기 때문입니다. 일반적으로 primary key를 기준으로 데이터를 selecct 한다거나 primary key를 기준으로 다른 컬럼(들)의 값을 update 또는 delete하는 작업이 흔히 수행되기 때문에 테이블에 primary key를 정의해 주면 where 조건절에 primary key가 SARGs(Search Arguments)로 사용된 쿼리들의 성능은 현저하게 향상됩니다.

불행히도, 테이블에 candidate key들이 2,3개나 있음에도 불구하고 primary key를 정의하지 않은 경우들을 간혹 볼 수 있습니다. 그런 경우 primary key를 생성하지 않아서 primary key를 사용하는 쿼리들의 성능이 나쁜 것은 물론이며, 테이블에 잘못된 중복 데이터들이 저장됨으로 인하여 데이터 무결성까지 손상되어 있는 비극적인 상황까지 발전한 경우도 있습니다. 테이블에서 각각의 행들을 고유하게 구분해 주는 컬럼 또는 컬럼들의 그룹을 찾아서 primary key를 만들어 주는 것은 반드시 빠뜨려서는 안되는 매우 기본적인 작업입니다.

여담으로, primary key 컬럼이 반드시 테이블의 첫 번째 컬럼이어야 하는 것은 아닙니다. 테이블을 만들고 나서 보니 테이블의 두 번째 컬럼이 primary key라고 해서 슬퍼하지 않으셔도 됩니다. ^ ^ 그렇지만 관례상 primary key 컬럼을 테이블의 첫 번째 컬럼으로 배치하는 것이 일반적입니다.

CREATE TABLE 명령어를 사용하여 테이블을 만들어 줄 때 꼭 잊지 마십시오. Candidate key 중 하나를 primary key로 정의해야 한다는 것을요. 그리고 다음과 같이 CONSTRAINT 절을 사용하여 primary key를 정의하면 됩니다. 이 때 이름은 여러분의 시스템에서 표준화한 명명 규칙이 있다면 그 명명 규칙을 따라서 여러분이 정하시면 되고, primary key 컬럼(들)을 clustered index로 정할지 아니면 nonclustered index로 정할지는 인덱스 튜닝 기준에 따라 정하면 됩니다.

계속 읽기 “기본 키(primary key)에 대해”

ubuntu에 h2load 설치하기

Based on this: https://github.com/nghttp2/nghttp2#requirements

Try this:

apt-get update;

apt-get install g++ make binutils autoconf automake autotools-dev libtool pkg-config
zlib1g-dev libcunit1-dev libssl-dev libxml2-dev libev-dev libevent-dev libjansson-dev
libc-ares-dev libjemalloc-dev cython python3-dev python-setuptools -qy;

git clone https://github.com/nghttp2/nghttp2.git;
cd nghttp2;
git submodule update –init;
autoreconf -i;
automake;
autoconf;
./configure;
make;
./src/h2load –help;

— — — — — — — — — — — — — — — —

URL=http://example.com/
NUM_REQUEST=1000
CONCURRENCY=32
THREADS=4

./src/h2load -n$NUM_REQUEST -c1 –h1 $URL

./src/h2load -n$NUM_REQUEST -c$CONCURRENCY -t$THREADS –h1 $URL

 출처 : https://gist.github.com/hedleysmith/d4fb9d8d2907a373b28079a0d11657fc