가상 테이블
사용자 편의성
내가 원하는 부분만 쓸수있다
보안
직접 접근X, 접근 가능한 사람 지정가능
종류 | 설명 | 비고 |
---|---|---|
심플 뷰(simple view) | 하나의 테이블에서 데이터를 생성한다. | CREATE VIEW 명령어로 생성한다. |
컴플렉스 뷰(complex view) | 여러 개의 테이블을 조인하여 데이터를 생성한다. | CREATE VIEW 명령어로 생성한다. |
인라인 뷰(inline view) | SELECT 문의 FROM 절에 기술한 SELECT 문 | 1회용 뷰로 권한을 제어할 수 없다. |
SELECT 문의 질의 성능 최적화를 위해서 실행계획을 수립하는 요소
구분 | RBO | CBO |
---|---|---|
개념 | 사전에 정의된 규칙 기반 계획 | 최소 비용 계산, 실행 계획 수립 |
기준 | 실행 우선순위 | 액세스 비용 |
성능 | 사용자의 SQL 작성 숙련도 | 옵티마이저 예측 성능 |
특징 | 실행 계획의 예측이 용이함 | 저장된 통계 정보의 활용 |
고려 사항 | 저효율, 사용자의 규칙 이해도 | 예측 복잡, 비용 산출 공식 정확성 |
주로 CBO 방식을 사용
데이터가 대용량이 될수록 SELECT조회가 효율적으로 떨어진다거나하면 기하급수적으로 느려진다.
데이터를 찾기위한 주소록 느낌
DBMS가 자동으로 생성해주기도 하고 사용자가 생성하는것도 가능
영향도가 없다 뿐이지 생성 할 때 소요시간같은건 있다
버퍼 캐시에 검색데이터가 있다면 더 빠르게 조회되어 출력
그래서 동일한 데이터를 조회한다면
처음 SELECT 할때보다 2번째가 더 빠름
캐시에 없다면 DB에서 조회를 해서 캐시에 쌓은 후 결과를 전달
캐시에다 모든결과를 저장해 둘 수 없기 때문에 DB에 직접접근 해야 될 때도 있다.
그때 색인을 먼저 검색해서 찾으면 효율이 좋다. 그게 인덱스.
행을 식별하기위해서 만드는 색인을 row id 라고 한다.
대표적으로
B-tree 인덱스, bitmap 인덱스가 있는데
일반적으로 B-tree 인덱스를 사용
종류 | 설명 | 사용 예 |
---|---|---|
unique index | 중복 데이터가 없는 경우(unique)에 사용한다. | 기본 키, 유일 키 데이터 |
non-unique index | 중복 데이터가 있는 경우에 빠른 검색 결과를 보장한다. | 인덱스가 필요한 일반적인 데이터 |
descending index | 내림차순 데이터 값으로 인덱스를 생성한다. | 매출, 최근 일자 등 |
composite index | 여러 열을 합쳐서 하나의 인덱스를 생성한다. | 여러 조건이 필요한 경우예 고객번호 and 성별 |
트리 구조로 검색해 나가는 형태
데이터의 종류가 적고 동일한 데이터가 많은경우에 좋음
Y/N, 성별(남/여) 등...
인덱스를 잘못만들면 오히려 성능하락을 일으킴
실시간 처리가 더욱더 중요해진 요즘에 등장
컴퓨터의 주 메모리에 모든 조직 또는 개인의 데이터를 저장합니다.(RAM)
내구성을 보강하기 위해서 여러 기술 도입
스냅샷, 트랜잭션 로깅, 비휘발성 랜덤 액세스 메모리(NVRAM)..
PS.
레디스가 이거였구만..
더 찾아봤는데 속도 말고는 너무 위험한듯? 어쨋든 DB는 내구도가 엄청 중요한데
아무리 보완책이 있다지만 가능성을 무시할수는 없다고 생각됨.
게다가 RAM이 부족한 사태가 일어나면 가상메모리 사용으로 오히려 더 느려질수도 있음
그래서 날아가도 상관없는 데이터에만 붙여서 사용하는듯
ex) 로그인 세션 데이터