db

인덱스 수직적 탐색 정렬된 인덱스 레코드 중 조건을 만족하는 첫 번째 레코드를 찾는 과정 즉 인덱스 스캔 시작 지점을 찾는 과정 인덱스 수평적 탐색 수직적 탐색으로 찾은 스캔 시작점에서 찾고자 하는 데이터가 더 안 나타날 때까지 수평적으로 스캔하는 과정 즉 실제로 데이터를 찾는 과정 WHERE 절의 조건 순서에 따라서 성능이 결정된다? 잘못된 정보임. 비교 연산 횟수를 줄일 수 있다는 설명은 맞음. 하지만 인덱스의 자료구조인 B+Tree는 평면 구조가 아님. 어떤 순서로 해도 일 량에는 차이가 없음. (자세한 건 인덱스 성별 여자 이름 유관순으로 검색해볼 것, 대부분이 잘못된 자료인 경우라고 함) 인덱스를 RANGE SCAN 할 수 없는 이유 1. 인덱스 칼럼을 가공하면 인덱스를 정상적으로 사용할 수 없..

SQL의 성능을 결정하는 디스크 I/O 1. I/O를 처리하는 동안 프로세스는 잠을 잔다. 2. 즉 프로세스가 디스크에서 데이터를 읽어야 할 때, CPU는 OS에 반환하고 잠시 waiting state 상태로 진입해 I/O가 완료되길 기다린다. 즉 프로세스가 I/O가 많을수록 대기시간이 길어지고 성능이 느려진다. 3. 아무리 하드웨어 성능이 향상되고 있지만 여전히 느리다. 그러므로 디스크 I/O를 줄이기 위한 최적화가 필요하다. SQL의 데이터 구조 1. 블록: 데이터를 읽고 쓰는 단위 2. 익스텐트: 공간을 확장하는 단위, 연속된 블록 집합 3. 세그먼트: 데이터 저장공간이 필요한 오브젝트(테이블, 인덱스, 파티션, LOB 등) 4. 테이블 스페이스: 세그먼트를 담는 컨테이너 5. 데이터 파일: 디스크..

소프트 파싱 vs 하드 파싱 1. SQL 파싱, 최적화, 로우 소스 생성 과정을 거쳐 생성한 내부 프로시저를 반복 재사용할 수 있도록 캐싱해 두는 메모리 공간을 라이브러리 캐시(Library Cache)라고 한다. 2. 라이브러리 캐시는 SGA(System Global Area)의 구성요소다. SGA는 서버 프로세스와 백그라운드 프로세스가 공통으로 액세스 하는 데이터와 제오 구조를 캐싱하는 메모리 공간이다. 3. SQL문을 전달하면 DBMS는 파싱 후 해당 SQL이 라이브러리 캐시에 있는지 확인한다. 캐시에 있으면 곧바로 실행 단계로 넘어가지만 캐시 미스가 발생하면 최적화 단계를 거친다. 소프트 파싱 --> 라이브러리 캐시에 SQL이 존재해서 바로 실행단계로 넘어가는 과정 하드 파싱 --> 라이브러리 캐..

NoSQL SQL 쿼리는 다음과 같은 단계를 거친다 1. 쿼리의 수신 2. 구문 해석 3. 테이블의 오픈 4. 테이블의 잠금 5. 실행 계획의 작성 6. 레코드로의 액세스 7. 테이블의 잠금 해제 8. 테이블의 클로즈 9. 결과 회신 기본 키 검색이라는 용도로 사용할 때 실제로 애플리케이션에서 의미가 있는 작업은 1,6,9번 밖에 없다. 그 이외의 작업은 모두 불필요한 작업이다. 이 불필요한 작업 때문에 데이터베이스의 성능을 발목 잡는다. NoSQL은 이런 관점에서 MySQL 보다 약 3배 이상의 빠른 쿼리 처리량을 보여준다. 탄생 배경 기본키 이용한 단순 검색 같은 경우처럼... SQL문과 같은 복잡한 언어를 사용하지 않고 프로그래밍 언어의 라이브러리 함수를 사용하여 직접 데이터를 액세스 하는 편이 훨..

분석계 처리는 무엇이 어려운가? 1. 데이터베이스는 데이터를 안전하고 빠르게 저장하는 것도 중요하지만, 결국 저장된 데이터를 어떻게 사용할지가 근본적인 존재 이유다. 2. 그러나 "분석 자체에 너무 시간이 걸려 현실적인 시간 내에 처리를 완료할 수 없다"라는 문제가 발생한다. 3. 그 이유는 RDBMS 자체가 DWH 같은 형태의 작업 형태에 적합하지 않기 때문이다. 4. 테이블은 크게 2개로 분류할 수 있다. 팩트 테이블, 디멘션 테이블이 그것이다. 5. 디멘션 테이블은 상대적으로 데이터의 삽입이나 갱신이 적은 테이블을 의미한다. 예를 들어 "고객", "협력사" 등의 테이블은 데이터의 갱신이 자주 이루어질 필요가 없다. 하지만 이 테이블의 데이터는 다른 테이블의 FK로 사용된다 6. 팩트 테이블은 축적계..

대량의 데이터를 고속으로 처리하는 기술 인덱스 특징 1. B+Tree 구조를 띄고 있다. 2. 참조 및 갱신이 O(logmN)으로 처리할 수 있어 매우 빠르다. 3. 모든 액세스가 랜덤 액세스다. 액세스 되는 블록이 군데군데 위치하고 있고 HDD는 랜덤 액세스가 매우 느리다. 4. 인덱스가 메모리에 들어가 있는 경우는 매우 빠르지만 그렇지 않은 경우 HDD에 랜점 액세스로 접근해야 하고, 성능은 크게 악화된다. 5. 인덱스가 메모리에 올라가지 못한 다는 것은 그만큼 데이터 양이 많아졌다는 뜻이다. 6. 인덱스 크기를 어떻게 하면 줄일 수 있을지를 고민하고, 이를 줄이는 것이 성능 향상으로 이어진다. 7. 처리하는 데이터가 대량으로 되었을 경우에 DML이 느려지게 되면 성능 면에서 큰 리스크를 책임 저야 ..