database on 오늘도 개발을 한다.

[DB] PostgreSQL 알아보기 + PostGIS를 활용한 연산해보기 (w. DBeaver, GiST)

Wed, 18 Dec 2024 09:12:20 +0900

서론

CS 스터디에서 12월 17일 발표한 PostgreSQL 알아보기에 대해 정리하고, 이를 실습해본 문서를 블로그에 공유하고자 한다.

개요

`PostgreSQL`?

복잡한 데이터 워크로드들을 안전하게 저장 및 확장할 수 있는 기능들을 제공하는 오픈 소스 객체-관계형 데이터베이스 시스템
- 객체-관계형 DB(Object-relational DB, ORD): 일반적인 관계형 DB와 유사하지만, 객체지향 개념이 추가적으로 지원되는 DB. 즉, DB단에서 클래스, 객체 및 상속의 개념을 지원
2001년부터 ACID를 지원해왔으며, 대부분의 주요 OS들을 지원함
- Linux(Debian, Ubuntu, Redhat 등..), macOS, Windows, BSD(OpenBSD, FreeBSD, ..), Solaris
지리공간 데이터를 효과적으로 저장 및 인덱싱하고 관련 쿼리를 지원하는 PostGIS, DB단에서 암호화를 수행할 수 있는 기능들을 제공하는 pgcrypto와 같은 다양한 확장 기능들을 사용할 수 있음
(2023년 기준) SQL:2023(*또는 ISO/IEC 9075*)의 필수 기능 177개 중 170 이상을 준수하는, 가장 표준을 완벽하게 준수하는 관계형 DB

기원

PostgreSQL은 버클리 캘리포니아 대학교에서 작성된 POSTGRE 패키지로부터 파생됨

`POSTGRES` 프로젝트

마이클 스톤브레이커 교수가 주도한 프로젝트로, 1986년 구현이 시작됨
POSTGRES는 INGRES의 후속으로 1986년 개발되기 시작한 DBMS
- INGRES: 1975년 개발되기 시작한 관계형 DBMS로, UNIX 운영체제 상에서 동작하며 쿼리 언어로 QUEL을 사용(이후 SQL도 지원)
  - 참고
    - INGRES—A relational data base system* - by G. D. HELD, M. R. STONEBRAKER and E. WONG
    - The Design and Implementation of Ingres
- INGRES의 초기 설계로는 스톤브레이커 교수를 포함한 개발진들이 추가 및 확장하고 싶은 기능들을 INGRES에 통합할 수 없어, 새로운 데이터베이스 시스템인 POSTGRES를 구축하게 됨
POSTGRES의 목표는 크게 다음과 같음 #
1. 복잡한 객체를 더 원활하게 지원할 것
  - 기존의 관계형 데이터베이스가 적합하지 않았던 CAD 시스템, 지리 데이터 등의 환경에 대한 지원
  - 즉, 이러한 환경에서 사용되는 지오메트리(Point, Polygon, …)와 같은 타입의 지원
2. 데이터 타입, 연산자 및 접근 방법에 대한 사용자 확장성 제공
  - 이 역시, CAD용 기하학 자료형이나, 매핑 애플리케이션용 위도/경도와 같은 자료형과 연산자를 DBMS에 추가할 수 있는 기능을 제공하고, 일부 유형에 적합한 액세스 방법(ex. Point -> K-D-B 트리, Polygon -> R-트리) 방법을 추가할 수 있도록 하는 것을 의미
3. 활성 데이터베이스(알림 및 트리거)와 포워드/백워드 체이닝에 대한 추론을 위한 기능 제공
  - 활성 데이터베이스 #: 데이터베이스 내/외부에서 발생하는 이벤트에 대응할 수 있는 이벤트-기반 구조를 포함하는 데이터베이스.
  - 포워드/백워드 체이닝 #: 데이터 기반 추론에서, ‘알려진 사실에 규칙을 적용해 나가 목표까지 도달하는 추론 기법’(포워드 체이닝)과 ‘목표에서 시작해 역방향으로 알려진 사실에 도달하는 추론 기법’(백워드 체이닝)
  - 버그 리포트 시스템처럼, 특정 이벤트가 발생시 관리자에게 알림을 보내거나(alerter) 특정 데이터의 업데이트 발생시 일관성 유지를 위해 업데이트를 전파(trigger) 할 수 있도록 활성 데이터베이스와 규칙(rule)을 지원하는 것
    - 규칙의 경우, 일정한 규칙(ex. 수업 일정 DB에서 교수는 N학점 이상 강의를 개설 및 진행하고 … 와 같은 규칙)을 따르는 테이블이라면, 복잡한 제약 조건들로 이를 강제하는 것이 아니라, 데이터들을 기반으로 이러한 규칙을 추론하는 방향으로 구현해야 함
4. 충돌 복구를 위한 DBMS 코드 간소화
  - 대부분의 DBMS는 작성하기 까다롭고, 희귀한 케이스로 가득하며, 테스트 및 디버깅이 힘든 충돌 복구 코드들이 존재
  - 게다가 앞선 목표 중 사용자 정의 접근 기법을 제공하는 것이 있었으므로, 충돌 복구 모델은 가능한 간단하고 확장하기 쉬워야 함
  - 따라서, 로그를 일반 데이터로 취급해 복구 코드를 단순화하고, 기록 데이터에 대한 접근을 지원
5. 광디스크, 워크스테이션(여러개의 프로세서로 이뤄진), 커스텀 VLSI 칩 등의 이점을 취할 수 있는 설계
  - VLSI(초고밀도 집적회로) 칩: 수십억개의 MOS 트랜지스터를 결합해 단일 칩에 올리는 집적 회로 칩
  - 워크스테이션의 CPU 자원을 활용할 수 있고, 광디스크와 VLSI 칩을 효과적으로 활용할 수 있는 설계를 조사
6. 관계형 모델을 가능한 적게 변경(가급적이면 변경 X)
  - 많은 사용자들이 관계형 모델에 익숙해질 것이고, 관계형 모델이 데이터를 단순한 테이블 수준으로 강제하고, 관계형 대수 연산을 통해 테이블을 생성할 수 있는, 이른바 스파르탄 단순성(Spartan Simplicity)이라는 이점이 있기 때문
  - 또한, 일반적인 계층 구조부터 CAD 데이터와 같은 복잡한 구조를 모두 다룰 수 있는 크고 복잡한 데이터 모델 보단, 확장 가능한 작고 단순한 모델을 기반으로 시스템을 구축해야 한다고 생각

왜 `PostgreSQL`을 써야할까?

장점

함수, 데이터 유형, 언어 등을 추가할 수 있는 확장성이 높음
구조화되지 않은 데이터 유형 지원
- JSON, XML, H-Store(키-값 쌍으로 데이터를 저장하는 자료형)와 같은 다양한 데이터 유형을 지원하며, NoSQL기능을 지원.
교착 상태가 거의 발생하지 않고 동시 처리가 가능하며 트랜잭션 속도가 빠른 MVCC
- MVCC(Multi-Version Concurrency Control, 다중버전 동시성 제어): 동시 접근이 가능한 환경에서, 원본의 스냅샷과 변경중인 데이터를 동시에 유지해 별도의 락이 필요하지 않아 더 빠르게 동작하는 동시성 제어 방식
고가용성 및 서버 오류 복구
데이터 암호화, SSL 인증서, 고급 인증 방법과 같은 고급 보안 기능
활발한 오픈소스 커뮤니티가 지속적으로 솔루션을 개선하고 업데이트
이외의 추가적인 장점은 PostgreSQL: About의 Why use PostgreSQL?에 나와 있음

단점

SQL Server 및 MySQL과 같은 다른 RDBMS보다 성능이 느림
- 다만 이는 경우에 따라 다름
- 일반적으로 읽기 작업만 수행할 경우, MySQL/MariaDB 대비 PostgreSQL이 느리다고 알려져 있음
호환성에 더 주력, 속도 향상을 위해서는 추가 작업이 필요함
MVCC 모델로 인해 발생하는 여러 문제점 참고 1 - The Part of PostgreSQL We Hate the Most // Blog // Andy Pavlo - Carnegie Mellon University 참고 2 - PostgreSQL Vacuum에 대한 거의 모든 것 | 우아한형제들 기술블로그
- 쿼리가 한 튜플을 업데이트하면, DBMS는 모든 컬럼을 새로운 버전에 복사함
- Dead Tuple(기존 원본 데이터를 저장하여, 어디에도 참조되지 않는 Tuple)을 정리하는 Vaccum(Java로 비유하자면 GC)이 워크로드의 write 작업 속도를 따라잡지 못할 경우 쿼리 성능 저하(DBMS는 Dead Tuple을 메모리에 로드해야 하므로), Dead Tuple에 의한 부실한 쿼리 플랜 최적화 등이 발생할 수 있음

MySQL -> PostgreSQL로 마이그레이션 하기

PostgreSQL 생태계에는 다른 데이터베이스에서 자료를 가져올 수 있는 컨버터 툴들이 존재
- Converting from other Databases to PostgreSQL - PostgreSQL wiki
- MySQL의 경우 pgloader, pg-chameleon, lanyrd/mysql-postgresql-converter, philipsoutham/py-mysql2pgsql 등 다양한 툴들이 존재함
하지만 이들을 본인의 경우 사용하기 쉽지 않았음
- 대부분의 툴들이 Linux 환경에서나 원활하게 동작하기 때문(특히, pgloader와 pg-chameleon은 Windows를 사실상 지원 X)
- 또한, mysqldump를 통해 MySQL 데이터를 추출한 뒤, pg_store를 통해 복구하는 방법을 시도하는 사람들도 있었지만 두 DBMS의 규격이 달라 실패
따라서 다음과 같이 DBeaver를 활용해 자료를 CSV로 변환하고, 이를 PostgreSQL에서 import하는 방식으로 마이그레이션을 진행
- 먼저, CSV 파일로 MySQL 테이블을 export함
- 이후, PostgreSQL DB의 Schemas>Tables에서 데이터 가져오기를 수행
- 이때, 사양의 차이로 MySQL의 지오메트리 타입이 온전히 옮겨지는 것이 아닌, WKT의 형태로 옮겨짐
  - 컬럼 값을 확인해보면, 아래와 같이 WKT 포맷으로 varchar 타입의 문자열들이 기록되어 있음을 알 수 있음
- 이를 지오메트리 타입으로 변환하는 과정을 수행해야 함
  - 먼저, 지오메트리 타입 컬럼을 테이블에 추가하는 AddGeometryColumn 함수를 호출
```
/* 
`AddGeometryColumn(varchar table_name, varchar column_name, integer srid, varchar type, integer dimension, boolean use_typmod=true) 함수를 호출
*/
select addgeometrycolumn('geotesttable', 'geotesttable', 'location_geom', 4326, 'POINT', 2)
```
- 이후, update geotesttable set location_geom = ST_GeomFromText(location); 문을 통해 기존 컬럼의 WKT를 기반으로 지오메트리 데이터를 생성해 컬럼 갱신

PostGIS의 공간 인덱스 및 공간 연산

공간 연산을 수행해보기 전, 먼저 공간 인덱스를 생성하여 SELECT 쿼리의 속도를 개선할 수 있도록 해야 함

공간 인덱스 생성하기

참고
PostGIS에서 공간 인덱스를 생성하는 구문은 다음과 같음
- CREATE INDEX mytable_geom_x ON mytable USING GIST (geom)
- CREATE SPATIAL INDEX 구문을 사용하던 MySQL과 다르게, PostGIS에서는 USING GIST 구문을 사용함
  - USING GIST: 인덱스에서 GiST(Generalized Search Tree) 구조를 사용할 것을 의미
    - GiST(Generalized Search Tree): 단순한, 일반적인 자료형 뿐만 아니라, 지리 정보 시스템, 멀티미디어 시스템 등 다양한 환경에서 사용되는 자료 유형을 지원하기 위해 ‘확장 가능한 쿼리 및 데이터 유형 집합‘을 지원하는 인덱스 구조.
      - B+ 트리, R-트리 등 다양한 트리 구조를 지원함
      - 참고1, 참고2
  - 이 키워드를 통해 인덱스를 설정할 경우, 기본 인덱스가 R-트리로 설정되며, 해당 키워드를 사용하지 않을 경우 표준 PostgreSQL B-트리 인덱스를 생성함

공간 연산 사용하기

PostGIS와 공간 인덱스의 성능을 확인하기 위해, 다음 두 가지 케이스를 비교해보려 함
1. 공간 인덱스를 사용해 사전 필터링을 거친 쿼리
2. 공간 인덱스를 사용하지 않는 함수를 사용하는 쿼리
- 참고로 공간 인덱스를 사용하는 함수는 다음과 같음
예시
- 한 점(POINT(128.593317 35.865807))으로 부터 5km 떨어진 점들 검색하기
  - 약 237만개의 POINT가 기록된 테이블에서 이를 검색하고자 함
  - 먼저, 공간 인덱스를 사용하지 않는 ST_DistanceSphere 함수를 사용해봄
    - 이 경우, 쿼리는 다음과 같음
      SELECT * FROM geotesttable WHERE ST_DistanceSphere(ST_GeomFromText('POINT(128.593317 35.865807)', 4326), location_geom) < 5000;`
      - 위 쿼리에 대해 EXPLAIN문을 사용해 실행 계획을 살펴보면 공간 인덱스가 활용되지 않으며(Seq Scan), 많은 양의 row들을 살펴봄을 알 수 있음
      - 또한, 쿼리문을 수행하고 데이터를 가져오는데 약 3초정도 소요됨
  - 반면, ST_DWithin(g1, g2, distance) 함수를 사용할 경우 공간 인덱스를 사용해 더 빠르게 탐색이 이뤄짐
    - ST_DWithin(g1, g2, distance)는 주어진 두 geometry(또는 geography) g1, g2 사이의 거리가 distance이내인지 여부를 반환하는 함수
      - 추가하자면, ST_DWithin()에 g1, g2로 geography 인자가 주어질 경우, 지구타원형 형태를 기준으로 하게 됨
        
        따라서 ST_DistanceSphere 와 동일한 기준 상에서 검색하려면 4번째 선택 인자인 use_spheroid을 false로 해주어야 함
    - 이 경우, 쿼리는 다음과 같음
      SELECT * FROM geotesttable WHERE ST_DWITHIN(location_geom::geography, ST_GeomFromText('POINT(128.593317 35.865807)', 4326)::geography , 5000, false);
      - 이때, 지오메트리 자료형인 location_geom과 ST_GeomFromText의 결과값을 geography 타입으로 캐스팅 하고 있음을 알 수 있음
      - 이는 ST_DWITHIN 함수가 geometry 값 2개를 인자로 받을 경우, distance의 단위가 SRID:4326의 단위인 도(degree)로 바뀌어버리기 때문에, 미터를 사용하려면 geography 값 2개를 인자로 주어야 하기 때문임
        
        그리고 이렇게 할 경우, 공간 인덱스 역시 하나 더 만들어 주어야 함
        
        위에서 만들었던 공간 인덱스는 geometry 타입인 location_geom을 기준으로 했기 때문에, geography로 캐스팅하여 DWITHIN 함수를 호출할 경우 인덱스를 사용하지 못하기 때문
        
        따라서 아래 구문을 통해 geography 형태의 인덱스를 하나 더 만들어야 함
        
        CREATE INDEX location_idx_geo ON geotesttable USING GIST ((location_geom::geography));
    - 위 쿼리에 대해 EXPLAIN문을 사용해 실행 계획을 살펴보면, 공간 인덱스가 잘 활용되고 있으며(Index Scan), 탐색하는 row 갯수도 훨씬 줄어들었음을 알 수 있음
    - 또한, 쿼리 수행도 총 0.4초가량으로 빠르게 이뤄짐

참고

[DB] 공간 인덱스 알아보기 + 쿼리 성능 개선해보기 (w. SRS, EPSG, SRID)

Wed, 11 Dec 2024 08:12:35 +0900

서론

CS 스터디에서 12월 12일 발표 예정인 공간 인덱스에 대해 정리하고, 이를 실습해본 문서를 블로그에 공유하고자 한다.

`공간 인덱스(Spatial Index)`란?

공간 데이터(Spatial Data)를 지원하는 데이터베이스에서 공간 쿼리(Spatial Query)를 최적화하기 위해 사용되는 인덱스
- 기존의 인덱스는 데이터들을 선형 순서로 정렬해 조회 속도를 최적화하는 반면, 2차원/3차원 공간 상의 데이터들을 정렬하기 위해 R-Tree와 같은 자료구조를 사용

`공간 데이터(Spatial Data)`

2차원 또는 3차원 공간에 위치할 수 있는 공간 또는 지리적 참조 형태의 데이터
주로 점, 선, 다각형과 같은 기하학적 객체들을 말함
지리 공간 데이터, 위치 기반 서비스 등에 대한 표준을 개발 및 유지하는 기구인 개방형 공간 정보 컨소시엄(OGC)에서는 Simple Feature와 2020년 이를 대체하기 위해 발표된 Feature Model 등을 꾸준히 개발 중
- 여러 DBMS는 이를 기반으로 한 공간 기능을 제공 중
- MySQL에서도 OGC의 기하 도형 모델(OpenGIS Geometry Model)에 대응되는 GEOMETRY, POINT, LINESTRING 등 다양한 타입을 제공

공간 참조 시스템(SRS) #조사추가필요

POINT, LINESTRING과 같은 모든 지오메트리 객체가 존재할 수 있는 공간
하나의 지오메트리 객체는 오직 하나의 공간 참조 시스템에만 존재할 수 있음
- 이는 각 공간 참조 시스템마다 좌표가 존재할 수 있는 표면이 다를 수 있기 때문
- 예를 들어, A SRS는 구형, B SRS는 평면이라고 하면 같은 좌표라도 각 SRS마다 다른 위치에 존재하게 됨
- 따라서 두 지오메트릭 객체가 동일하기 위해서는 좌표 뿐만 아니라 존재하는 SRS도 동일해야 함
  - 이 때문에 보통 다른 SIRD를 갖는 지오메트리 값 간에는 어떤 연산도 이뤄지지 않고 거부됨
각 SRS는 고유한 공간 참조 식별자(SRID)가 존재하며, 이를 통해 어떤 SRS에 속해있는지 구분함
SRID와 이에 해당하는 SRS는 EPSG(유럽 석유 조사 그룹)에서 제작 및 운영하고 있는 EPSG의 좌표계 식별 데이터셋라는 사실상 표준이 정해져 있음
주로 사용되는 SRS는 WGS 84(World Geodetic System 1984)라고 불리는 SRID 4326, WGS 84/슈도 메르카토르 라고도 불리는 SRID 3857가 주로 사용됨
- 둘의 가장 큰 차이는 3차원 구체를 기반으로 하는지(4326), 2차원 평면을 기반으로 하는지(3857)가 차이

EPSG:4326 - WGS 84#

경도(longitude), 위도(latitude)를 통해 3차원 타원 표면에서의 좌표를 표현하는 좌표계
GPS, Google Earth 등에서 사용됨
각도(Degree)를 단위로 함

EPSG:3857 - WGS 84 / Pseudo-Mercator / Spherical Mercator#

x, y 좌표를 통해 WGS 84 타원체 데이텀(좌표 축의 원점이 되는 기준점)에 메르카토르 투영을 적용한 좌표계
- 메르카토르 투영의 일종이기 때문에, 고위도 지역으로 갈수록 왜곡이 심해진다는 특징이 여전히 존재
Google Maps, OpenStreeMap 등 웹 지도 도구들에서 사용됨
미터(metres)를 단위로 함

MySQL의 공간 데이터 타입

MySQL에는 크게 단일 지오메트리 값을 저장할 수 있는 자료형과 지오메트리 값의 집합을 저장할 수 있는 자료형으로 나뉨

WKB와 WKT

OpenGIS에서는 기하학적 객체의 표현을 위해 WKT(Well-Known Text) 포맷과 WKB(Well-Known Binary) 포맷을 사용
- MySQL에서는 내부적으로 지오메트리 값을 WKT, WKB가 아닌 다른 포맷을 사용해 저장
  - WKB와 유사하지만 앞의 4바이트가 SRID를 나타냄
    - SRID(공간 참조 식별자): 지오메트리 값이 어떤 공간(공간 참조 시스템, SRS)을 기준으로 하는지 구분하는 식별자. 다른 SIRD를 갖는 지오메트리 값 간에는 어떤 연산도 이뤄지지 않고 거부됨

WKT(Well-Known Text)

지오메트리 값을 ASCII 형태로 교환하기 위해 설계됨
OpenGIS 사양에서는 WKT값 작성을 위한 배커스-나우르 문법을 제공
자료형에 따라 필요한 점의 갯수는 다르지만 X-Y 좌표 값을 (X Y) 형태로, 즉 쉼표가 아닌 공백을 통해 구분하는 문법을 공통적으로 사용함
- 예시
  - Point - POINT(15 20)
  - LINESTRING - LINESTRING(0 0, 10 10, 20 25, 50 60)
MySQL에는 WKT 형태의 문자열로부터 지오메트리 값을 만들어내는 ST_타입FromText 함수들이 존재 #
- 예시
  - POINT - ST_PointFromText
  - GEOMERTY - ST_GeomFromText

WKB(Well-Known Binary)

지오메트리 WKB 정보를 담고있는 BLOB 형태의 이진 스트림 형태로 지오메트리 값을 교환하기 위해 사용됨
WKB는 1바이트의 unsigned Integer(byte order), 4바이트의 unsigned Integer(WKB type), 8바이트의 배정밀도(double precision) 숫자 값(X, Y 좌표)들을 사용
- byte order
  - 0일 경우 빅 엔디안(작은 주소에서 데이터의 높은 바이트(MSB)부터 저장하는 방법)
    - 만약 0x12345678을 저장한다면, 앞에서 부터 0x12 / 0x34 / 0x56 / 0x78을 저장
  - 1일 경우 리틀 엔디안(작은 주소에서 데이터의 낮은 바이트(LSB)부터 저장하는 방법)
    - 만약 0x12345678을 저장한다면, 앞에서 부터 0x78 / 0x56 / 0x34 / 0x12를 저장
- WKB type
  - 어떤 지오메트리 유형인지 나타내는 값
  - MySQL의 경우 1부터 7까지 각각 Point, LineString, Polygon, MultiPoint, MultiLineString, MultiPolygon, GeometryCollection 에 대응 됨
- 예시
  - POINT(1 -1)에 대응되는 WKB는 다음 2개의 16진수로 표현되는 21바이트 시퀀스
    - 0101000000000000000000F03F000000000000F0BF
    - 이는 01 / 01000000 / 000000000000F03F / 000000000000F0BF로 나누어 볼 수 있음

단일 지오메트리 값 자료형

GEOMETRY는 어떤 유형의 지오메트리 값이든 저장할 수 있으며, 나머지 단일 값 유형은 특정 도형의 유형으로 값을 제한함

GEOMETRY

모든 지오메트리 클래스(타입)의 루트 클래스
추상 클래스(인스턴스화 할 수 없음)
GEOMETRY의 하위 클래스들은 GEOMETRY가 갖는 여러 속성 값들을 갖고있으며, 특정 서브클래스에는 각각 고유한 프로퍼티가 있을 수 있음
속성 값
- type
  - 각 지오메트리 값은 지오메트리 클래스 중 인스턴스화 가능한 클래스 중 하나에 속해야 함
- SRID
  - 해당 지오메트리 값의 공간 참조 식별자
  - 지오메트리 값과 연관된 공간 참조 시스템(SRS)을 식별
  - MySQL에서 SRID는 0부터 $2^{32} -1$ 사이이며, 지정되지 않을 경우 기본값은 0
- coordinates
  - 공간 참조 시스템상의 좌표 값으로, 배정밀도(8바이트) 숫자로 표현됨
  - 비어있지 않은 지오메트리는 적어도 한 쌍의 (X, Y) 좌표가 포함되어야 함
- interior, boundary, exterior
  - interior는 지오메트리가 차지하는 공간, exterior는 지오메트리가 차지하지 않는 모든 공간, boundary는 interior와 exterior 사이의 경계
- MBR(최소 경계 사각형, Minimum Bounding Rectangle)
  - 최소 및 최대 (X, Y) 좌표로 구성된 경계 지오메트리
  - ((MINX MINY, MAXX MINY, MAXX MAXY, MINX MAXY, MINX MINY))
- simple / nonsimple
  - LineString, MultiPoint, MultiLineString유형은 simple이거나 nonsimple
- closed / not closed
  - LineString, MultiLineString 유형은 closed이거나, not closed
- empty / nonempty
  - 지오메트리에 점이 하나도 존재하지 않는 경우 empty, 그렇지 않은 경우 nonempty
- dimension
  - -1: 비어있는 지오메트리
  - 0: 길이도, 면적도 없는 지오메트리
  - 1: 길이가 0이 아니지만, 면적은 0인 지오메트리
  - 2: 면적이 0이 아닌 지오메트리
  - Point는 0, LineString은 1, Polygon은 2
  - MultiXXX 객체는 이를 이루는 요소들의 차원과 동일

POINT

좌표 공간에서 단일 지점을 나타내는 지오메트리
X, Y 좌표값을 가지며 0차원 도형으로 정의되고 boundary는 비어있는 집합임

LINESTRING

점 사이 선형 보간(Linear Interpolation)을 사용하는 Curve 지오메트리
- 선형 보간: 양 끝점의 값이 주어졌을 때, 그 사이에 위치한 값을 추정하기 위하여 선형 다항식을 사용해 계산하는 방법
- Curve
  - 1차원이며, 시작점과 끝점이 같으면 closed
  - 동일한 점을 2번 지나지 않거나, 시작점과 끝점이 같은 경우 simple
  - closed인 Curve의 boundary는 비어있으며, not closed인 Curve의 boundary는 양 끝점
각 점 쌍으로 구성된 세그먼트의 좌표값을 가짐
정확히 두 점으로만 구성되면 Line, closed 이며 simple인 경우 LinearRing임

POLYGON

다면체를 나타내는 평면형 Surface
하나의 exterior boundary와 0개 이상의 interior boundary로 구성되며 각 interior boundary는 Polygon 내부의 구멍의 경계를 정의함
Polygon의 Boundary는 내/외부 경계를 구성하는 LinearRing 객체 집합으로 구성됨
Polygon은 교차하는 Ring이 존재하지 않으며, Boundary의 Ring이 점과 교차할 수 있지만, 접선으로만 교차
interior로 연결된 Point 집합을 가짐

지오메트리 값 집합 자료형

GEOMETRYCOLLECTION은 모든 유형의 객체 집합을 저장할 수 있으며, 나머지 집합 자료형은 집합 멤버를 특정 도형 유형을 가진 멤버로 제한함

MULTIPOINT

POINT로 구성된 지오메트리 집합으로, 각 POINT들은 연결되거나 정렬되지 않음
0차원 지오메트리이며, 이를 구성하는 각 POINT 간의 좌표가 같지 않으면 simple
boundary는 비어있음

MULTILINESTRING

LineString로 구성된 MultiCurve 컬렉션
MultiCurve
- 1차원 지오메트리
- 이를 이루는 모든 요소들이 simple할 때만 simple
- boundary는 mod 2 union 규칙(홀수-짝수 규칙)으로 구할 수 있음
  - 한 Point가 홀수 개의 Curve요소의 경계에 있는 경우 MultiCurve의 경계에 있다고 할 수 있음
  - 모든 요소가 closed이면 closed
  - boundary는 비어있음

MULTIPOLYGON

Polygon으로 구성된 MultiSurface 컬렉션
각 Polygon 요소는 교차하는 interior가 없어야 함
무한한 수의 점에 닿는 Polygon 요소를 가질 수 없음
2차원 지오메트리이며, boundary는 요소들의 경계들에 대응되는 LineString 집합
MultiPolygon의 경계를 이루는 각 Curve들은 각각 하나의 Polygon요소의 경계에 존재해야 함

GEOMETRYCOLLECTION

0개 이상의 지오메트리로 이뤄진 컬렉션
GEOMETRYCOLLECTION의 모든 요소는 동일한 좌표계(공간 참조 시스템)에 있어야 함

`공간 인덱스(Spatial Index)`

공간 인덱스와 비공간 인덱스

공간 인덱스는 R-트리 인덱스를 생성하며, 이를 지원하지 않는 다른 엔진(즉, 비공간 인덱스를 지원하는)의 경우, B-트리 인덱스를 생성
- B-트리 인덱스는 정확한 값을 조회하는데는 유용하지만, 범위 스캔에 대해서는 그렇지 않음

공간 인덱스

MySQL의 스토리지 엔진 중 InnoDB와 MyISAM에서만 공간 인덱스를 지원
일반 인덱스를 생성할 때 처럼 CREATE INDEX문을 사용하되, SPATIAL 키워드를 사용
- ex) ALTER TABLE mytable ADD SPATIAL INDEX(geomcolumn);
단일 공간 열에 대해서만 인덱스를 생성할 수 있음
인덱스로 지정된 열은 NOT NULL이어야 함
기본 키나 유니크 인덱스에는 허용되지 않음
옵티마이저는 SRID가 제한된 열에 정의된 공간 인덱스를 사용할 수 있음

비공간 인덱스

ARCHIVE를 제외한 나머지 공간 열을 지원하는 스토리지 엔진에서 사용 가능
인덱스가 기본키가 아닌 경우 NULL을 허용
- InnoDB, MyISAM, MEMORY에서만

공간 인덱스 사용하기

옵티마이저는 WHERE절에서 MBRContains(), MBRWithin()와 같은 함수를 사용하는 쿼리에 대해, 가용한 공간 인덱스를 검색에 포함할 수 있는지 조사
따라서 공간 인덱스를 사용하는 함수를 통해 탐색할 row의 범위를 줄이면 최적화가 가능
예시
- 한 점으로 부터 5km 떨어진 점들 검색하기
  - 약 237만개의 POINT가 기록된 테이블에서 이를 검색하고자 함
  - ST_DISTANCE() 또는 ST_DISTANCE_SPHERE()를 사용할 경우 공간 인덱스를 사용하지 않고, 한 점 한 점 모두 연산을 거치기 때문에 비효율적
    - 이 경우 쿼리는 다음과 같음
```
set @lat = 35.865807;
set @lng = 128.593317;
SET @g1 = ST_GeomFromText(CONCAT('POINT(', @lng, ' ', @lat, ')'), 0);
SELECT * FROM geotesttable WHERE ST_DISTANCE_SPHERE(@g1, location) < 5000;
```
    - 위 쿼리를 분석하면, 공간 인덱스가 활용되지 않고 237만개의 row들을 모두 불러옴을 알 수 있음
      - 참고로 explain query문을 수행시, 실제 DB의 row 갯수와 다른 값이 불러와 질 수 있음
        
        이는 explain문이 INFORMATION_SCHEMA 테이블에서 제공하는 러프한 추정치를 사용하기 때문
        
        따라서 ANALYZE TABLE table_name; 문을 수행해 이를 업데이트 해주면 올바른 값을 불러옴
      - 해당 쿼리문을 실제로 수행하면, 데이터를 불러오는데 약 20초가 소요됨
  - 이를 최적화하고자, 먼저 각 변이 한 점으로 부터 각각 5km씩 떨어진 정사각형 Polygon을 만들고, ST_CONTAINS(A, B) 함수를 사용해 이에 포함되는 점들만 검색
    - 이를 위해 먼저 다음과 같은 형태의 Polygon을 만듦
      - 각 변이 가운데 점으로부터 5km씩 떨어진 정사각형
    - 이후 공간 인덱스를 사용하는 지오메트리 함수인 ST_CONTAINS(A, B)를 사용해 각 점이 해당 Polygon 내부에 존재하는지 확인
      - ST_CONTAINS(A, B)는 B가 A 내부에 포함되는지 여부를 반환하는 함수
  - 이후 각 점들에 대해 ST_DISTANCE_SPHERE(A, B) < 5000 조건을 수행해 기준점과의 거리가 5km 이내인 점들을 불러온다
  - 이를 모두 반영한 쿼리는 다음과 같다
```
	set @lat = 35.865807;
	set @lng = 128.593317;
	SET @g1 = ST_GeomFromText(CONCAT('POINT(', @lng, ' ', @lat, ')'), 0);
	# 위도(latitude) 1도는 대략 111.1km
	# 따라서 1km당 위도는 0.0090009 ~= 0.0091도
	SET @onelat = 0.0091;
	# 경도(longitude) 1도는 위도에 따라 달라지며, 적도에서 대략 111.1km
	# 계산식은 111.1 * cos(theta * pi/180)
	# 한국은 북위 33~38도 사이에 존재하며, 위에서 선언한 위도인 35.8658도를 기준으로하면
	# 경도 1도는 대략 90.0345km
	# 따라서 1km당 위도는 0.0111069 ~= 0.0111도
	SET @onelng = 0.0111;

	SET @toplat = @lat + @onelat * 5;
	SET @bottomlat = @lat - @onelat * 5;
	SET @toplng = @lng + @onelng * 5;
	SET @bottomlng = @lng - @onelng * 5;
	SET @p1 = ST_GEOMFROMTEXT(CONCAT('POLYGON((', @bottomlng, ' ', @bottomlat, ', ',
		@bottomlng, ' ', @toplat, ', ',
		@toplng, ' ', @toplat, ', ',
		@toplng, ' ', @bottomlat, ', ',
		@bottomlng, ' ', @bottomlat, '))'), 0);
	SELECT * FROM geotesttable WHERE ST_CONTAINS(@p1, location) and ST_DISTANCE_SPHERE(@g1, location) < 5000;
```
- 위 쿼리를 explain문을 통해 분석하면, 설정해놓은 공간 인덱스(idx_location)를 활용해 범위를 줄여 불러옴을 알 수 있음
  - 쿼리 수행에 걸리는 시간도 20초에서 5초로 확 단축됨

주의사항

지오메트리 컬럼 생성시 초기 SRID를 신중히 정할 것

어떤 이유인지는 몰라도, 이미 존재하는 컬럼의 SRID를 변경하려고 하면 변경이 이뤄지지 않음
- 시도해본 구문 목록 (예를 들기 위해 테이블 이름은 table, 컬럼 이름은 geom이라고 하겠음)
  - UPDATE table SET geom = ST_GeomFromText(ST_AsText(geom), SRID)
  - UPDATE table SET geom = ST_Transform(geom, SRID)
  - UPDATE table SET geom = ST_SRID(geom, SRID)
- 공통적으로 아래와 같은 오류가 발생함
```
	ERROR 3643 (HY000): The SRID of the geometry does not match the SRID of the column 
	'position'. The SRID of the geometry is 0, but the SRID of the column is 4326. 
	Consider changing the SRID of the geometry or the SRID property of the column.
```
이미 존재하는 컬럼의 SRID는 바꾸는게 불가능하다 판단
- 따라서 변경하고자 하는 SRID를 갖는 컬럼을 새로 생성한 뒤, 기존 컬럼의 값들을 복사해오고 공간 인덱스도 재설정함
```
ALTER TABLE `table` ADD geom4326 POINT SRID = 4326;
UPDATE `table` SET geom4326 = ST_GeomFromText(ST_AsText(geom), 4326)`
ALTER TABLE `table` DROP COLUMN geom;
...
```

참고

[DB] SQL Injection 알아보기 (w. PreparedStatement, Stored Procedures)

Sat, 14 Sep 2024 20:29:34 +0900

서론

CS 스터디에서 9월 4일에 발표한 SQL Injection에 대해 정리한 문서를 블로그에 공유하고자 한다.

SQL Injection에 대해 설명해 주세요.

SQL Injection이란, 데이터베이스를 사용하는 웹 애플리케이션을 공격하는데 사용되는 코드 인젝션 공격 기법을 말합니다.
주로 공격자가 입력 필드에 악성 SQL 문을 삽입해 실행시키는 방식으로 공격하며, 데이터베이스의 정보를 불법적으로 열람 또는 조작할 수 있는 취약점입니다.
Injection 공격은 오픈소스 웹 애플리케이션 보안 프로젝트인 OWASP에서 매년 상위 10대 취약점에서 근 20년간 상위권을 차지하고 있으며, 단순히 신원 위조, 기존 데이터 변조와 같은 공격 뿐만 아니라 관리자 탈취, 데이터 삭제, 시스템 데이터 공개와 같이 시스템에 치명적인 공격을 불러올 수 있습니다.

공격 유형

SQL Injection은 기본적으로 데이터 입력 란에 메타 문자('', OR 등 SQL문을 이루는 문자들)를 삽입해 기존에 존재하지 않던 SQL 명령을 제어 영역(control plane, SQL 명령어 및 관련 구조가 위치하는 영역. ~= user input)에 배치하는 방식으로 이뤄집니다.
이러한 구조적 결함은 SQL이 제어 영역과 데이터 영역(data plane, 실제 데이터 값이 위치하는 영역. ~= SQL Query)을 구분하지 않고, 단순히 문자열로 된 명령을 실행한다는 점에서 기인합니다.
SQL Injection은 크게 아래 3가지 유형으로 구분됩니다.

에러 기반 SQL 인젝션(Error-based SQL Injection)

에러 기반 SQL 인젝션은 데이터베이스 서버에서 발생한 오류 메세지를 바탕으로 현재 API가 어떤 SQL 명령을 호출하는지, 데이터베이스 구조는 어떤지 등의 정보를 얻어내 공격하는 기법입니다.
이는 공격당하는 웹 애플리케이션 서버가 SQL 쿼리 수행시 발생한 오류를 HTTP 응답으로 반환하도록 동작하는 경우 가능한 공격입니다.

예시

위와 같은 입력 폼으로 아이디, 비밀번호를 입력받아 로그인을 수행하는 웹 애플리케이션이 있다고 가정하겠습니다.
위 애플리케이션이 구동되는 Spring 서버에서는 DB에서 일치하는 유저를 불러오기 위해 다음과 같은 코드가 동작하게 됩니다.

{
	...
	Statement st = conn.createStatement();
	ResultSet rs = st.executeQuery(
	"SELECT * FROM member WHERE userid = '" + ID + "' AND userpw ='" + PW + "'");
}

즉, DB에서는 다음과 같은 SQL문이 동작하게 될 것입니다.

SELECT * FROM member WHERE userid ='$ID' AND userpw ='$PW'

이때, pw에 'OR 1=1 --를 입력하거나 extractvalue() 함수 등을 사용해 DB 정보를 탈취할 수 있습니다.
OR 1=1 --는 WHERE 절의 조건을 항상 참이 되도록 하고, 이어지는 조건들을 --를 통해 주석 처리하게 됩니다. 따라서 id에 (실제 서비스에 가입된) id중 어떤 것을 입력해도 로그인할 수 있게 됩니다.
extractvalue(xml_frag, xpath_expr) 함수의 경우 XML과 XPath 표현식을 인자로 받아, XML에서 XPath 표현식에 일치하는 데이터를 추출 및 반환하는 함수입니다.
이때, 두 번째 인수에 유효하지 않은 XPath 표현식이 사용될 경우 XPATH syntax error를 통해 해당 인수 값을 출력하게 되는데, 이것이 SQL 쿼리일 경우 실행 결과를 에러 메시지에 포함한다는 점을 활용해 공격에 사용됩니다.
따라서 두 번째 인수에 콜론(':' 또는 0x3a(16진수 표현)을 사용)을 맨 앞에 추가하므로써 항상 유효하지 않은 XPath 표현식을 만들고, concat()으로 뒤에 실제 실행할 SQL 쿼리를 넘겨 정보 탈취를 시도합니다.
가령 PW에 ' AND extractvalue(rand(),concat(0x3a,version()))-- 라는 구문을 넣게 된다면 실제 SQL 쿼리 문은 다음과 같게 될것입니다. (version()은 현재 MySQL 버전을 반환하는 함수입니다.)

SELECT * FROM member WHERE userid ='' AND userpw ='' AND extractvalue(rand(),concat(0x3a,version()))--'

이를 실행하면 아래 그림처럼 서버의 MySQL 버전을 에러와 함께 반환하게 됩니다.

이를 통해 공격자는 DB 버전, DB 명, 테이블 명, 컬럼 명 등 다양한 데이터들을 추출할 수 있게 됩니다.

UNION 기반 SQL 인젝션(Union-based SQL Injection)

UNION 기반 SQL 인젝션은 웹 애플리케이션이 DB 질의한 결과를 HTTP 응답에 포함해 반환하는 경우, SQL문을 조작하여 DB 구조 및 데이터를 탈취하는 공격 기법입니다.
이때, 원래 애플리케이션이 반환할 데이터는 필요하지 않으므로 음수 값과 같이 DB에 존재하지 않을만한 값을 입력 값으로 전달하고, 이후 UNION 또는 UNION ALL을 이용해 DB의 다른 데이터 값을 추출하는 SQL 쿼리를 덧붙여 서버에 전달하게 됩니다.

`UNION`과 `UNION ALL`

UNION과 UNION ALL은 두 개 이상의 SELECT 쿼리 결과를 하나로 합쳐주는 집합 연산자로, 이때 합쳐질 쿼리들은 다음 조건을 만족해야 합니다.

각 쿼리들은 SELECT절에서 동일한 갯수의 열을 사용해야 한다.
각 쿼리에서 동일한 순서의 컬럼들은 서로 호환되는 자료형을 가져야 한다.

또한, UNION은 쿼리 결과값 통합시 중복된 레코드를 제거하는 반면, UNION ALL은 중복 제거 절차 없이 모든 레코드들을 반환한다는 차이가 있습니다.

예시

쇼핑몰 웹 애플리케이션에서 물품의 ID를 사용자로 부터 입력받으면, 해당 물품의 ID, 이름, 가격을 조회하는 API가 있다고 가정하겠습니다.
해당 API가 DB에 요청할 SQL 쿼리는 다음과 같을 것입니다.

SELECT item_id, item_name, item_price 
FROM item 
WHERE item_id = '$item_id';

또한, 해당 API는 HTTP 응답으로 이름과 가격, 즉 item_name, item_price를 반환합니다.

이러한 상황에서 ID로 -99 UNION ALL SELECT version(), database(), 2--를 전달한다면 SQL 쿼리는 다음과 같이 바뀌게 됩니다.

SELECT item_id, item_name, item_price 
FROM item 
WHERE item_id = -99 
UNION ALL 
SELECT version(), database(), 2--;

당연히 상품 ID가 음수인 상품은 존재하지 않을 것이므로 상품 데이터는 전혀 반환되지 않고 UNION으로 결합한 SELECT 쿼리에 포함된 SQL 서버 버전, DB명, 숫자(컬럼 갯수 및 타입을 맞추기 위한 임의 값)를 반환하게 됩니다.

열 갯수 알아내기

그리고 UNION에서 열의 갯수를 맞춰야 하는 조건 때문에, 현재 쿼리의 컬럼 갯수를 알아야 할 수 있습니다.
이때 ORDER BY 절을 활용하면, 원래의 SQL 쿼리의 열 갯수를 알아낼 수 있습니다.
ORDER BY 절에서 정렬 기준 컬럼을 지정할 때, 열 이름을 직접 기입할 수도 있지만 해당 컬럼의 순번을 기입할 수도 있습니다.
즉, 위 케이스의 경우 ORDER BY 3을 기입하면 SQL 쿼리의 세 번째 컬럼인 item_price를 기준으로 정렬하게 됩니다.
이러한 순번은 SQL 쿼리가 불러올 컬럼 갯수만큼 배정되므로 해당 갯수 이상의 숫자를 기입하게 되면 다음과 같은 오류가 발생하게 됩니다.

따라서 ORDER BY 문에 기입할 순번을 하나씩 차례대로 증가시키다가 DB에서 오류가 발생하거나 비정상 응답을 반환하게 되면, 바로 전의 순번이 원래의 SQL문의 컬럼 갯수와 같게되는 것입니다.

블라인드 SQL 인젝션은 상기한 SQL 인젝션들과 달리, 웹 애플리케이션이 HTTP 응답에 DB 오류 메시지나 데이터를 포함하지 않을때 사용할 수 있는 공격 기법입니다.
즉, 서버의 직접적인 응답 대신 알고싶은 정보가 포함된 특정 조건을 SQL 쿼리에 포함시켰을때 HTTP 응답의 상태가 달라지거나, 응답에 걸리는 시간의 차이를 통해 해당 조건이 참인지 거짓인지 알아내므로써 데이터베이스 내 정보를 유추하는 공격 기법입니다.
크게 응답의 차이를 통해 유추하는 불린 기반 방식과 서버의 응답 시간 차이를 통해 유추하는 시간 기반 방식이 있습니다.

블라인드 불린 기반 SQL 인젝션은 SQL 쿼리의 참/거짓여부에 따른 HTTP 응답 내용, 상태 코드 등의 차이가 존재할 때 이를 통해 정보를 유추할 수 있는 공격 기법입니다.

예시

게시판 애플리케이션에서 게시글 id를 URL 인자로 받아 게시물을 불러오는 API를 예시로 들어보겠습니다. 해당 API는 다음과 같은 SQL 쿼리를 요청합니다.

SELECT subject, content, author  
FROM board  
WHERE id='$id'

만약 올바른 게시글 id를 전달받았다면 정상적으로 해당 게시글을 가져올 것이고, 그렇지 않다면 아무것도 반환하지 않을 것입니다.
예를 들어 id를 1 AND 1=0-- 로 넘겼다면 SQL문은 다음과 같게 됩니다.

SELECT subject, content, author  
FROM board  
WHERE id=1 AND 1=0--

우리가 넘긴 AND 1=0 조건 때문에 게시물 조회 SQL 쿼리는 거짓이 되어 아무 것도 불러올 수 없을 것입니다. 반면 1 AND 1=1 --을 넘겼다면 정상적으로 게시물을 조회해올 것입니다.
이를 바탕으로 데이터베이스의 이름을 알아내고 싶다고 가정해보겠습니다.
그렇다면 먼저 DB 이름의 길이를 알아내야 하므로, SQL의 LENGTH()을 활용합니다.
id로 1 AND LENGTH(database()) = 1 --, 1 AND LENGTH(database()) = 2 --, … 처럼 점점 값을 증가시키며 응답이 정상적으로 반환될 때 까지 반복합니다.

1 AND LENGTH(database())=1--+                (결과:거짓)
1 AND LENGTH(database())=2--+                (결과:거짓)
1 AND LENGTH(database())=3--+                (결과:참) <- 현재 DB의 이름의 길이는 3임

이후 한글자 한글자씩 비교하며 DB 이름의 각 자리가 무엇인지 확인합니다. 이때 SUBSTRING() 함수를 활용합니다.

1 AND SUBSTRING(database(), 1, 1)='a'--+                (결과:거짓)
1 AND SUBSTRING(database(), 1, 1)='b'--+                (결과:거짓)
1 AND SUBSTRING(database(), 1, 1)='c'--+                (결과:참) <- 현재 DB의 이름의 첫 글자는 'c'임

이를 반복해 알아낸 각 자리의 문자들을 결합하면 DB의 이름을 알아낼 수 있습니다.

블라인드 불린 기반 SQL 인젝션은 SQL 쿼리의 참/거짓여부에 따른 HTTP 응답 내용, 상태 코드 등의 차이가 존재를 확인할 수 없지만, 서버 응답 시간을 제어할 수 있을 경우 사용 가능한 공격 기법입니다.
즉, 기존 SQL 쿼리에 특정 조건이 참일 경우 응답을 지연시키는 함수를 사용해 해당 조건의 참/거짓 여부를 판별하게 됩니다.
응답 시간을 제어하는 함수는 DBMS별로 상이하며, 예시로 들 MySQL(및 MariaDB)의 경우 sleep() 함수를 사용합니다.

예시

위와 마찬가지로 게시판 애플리케이션에서 게시물 조회 API를 사용한다고 가정하겠습니다.
이때 id로 1 AND if(1=1, sleep(5), false)-- 와 같은 구문을 전달했을 때 기존 SQL 쿼리에 정상적으로 포함된다면, SQL문은 다음과 같게 됩니다.

SELECT subject, content, author  
FROM board  
WHERE id=1 AND if(1=1, sleep(5), false)--

이때 if문이 동작하기 때문에 첫 번째 인자로 주어진 조건식인 1=1이 참이므로, 서버는 5초간 대기 상태에 있다가 응답하게 될 것입니다.
이를 바탕으로 불린 기반 공격 처럼, 조건문에 원하는 정보에 대한 조건을 포함해 API 요청을 반복하므로써 원하는 정보를 알아낼 수 있습니다.

1 AND if(LENGTH(database())=1, sleep(5), false)--+                (결과:거짓)
1 AND if(LENGTH(database())=2, sleep(5), false)--+                (결과:거짓)
1 AND if(LENGTH(database())=3, sleep(5), false)--+                (결과:참) <- 현재 DB의 이름의 길이는 3임

방어법 #

이러한 SQL 인젝션을 방지하기 위해서는 ① 문자열들을 연결해 동적 SQL 쿼리를 생성하지 않거나, ② 실행된 쿼리에 악성 SQL 입력이 포함되지 않도록 해야 합니다.

Prepared Statement 사용하기

준비된 구문(Prepared Statement), 또는 파라미터화 된 쿼리(Parameterized Query)를 사용하게 되면 동적 쿼리보다 쿼리를 작성 및 이해하는데 쉬우며, 개발자가 먼저 SQL 쿼리를 정의한 뒤 이후에 각 매개변수들을 쿼리에 전달하도록 합니다.
또한 DB 쿼리가 이러한 형태를 띄는 경우 DB는 사용자 입력에 상관없이 항상 코드와 데이터를 구분합니다. 그리고 공격자가 SQL 명령을 삽입해도 쿼리의 원래 의도를 변경할 수 없도록 보장합니다.

// 코드 예시

// 매개변수로 사용될 해당 인자는 꼭 검증하는 것이 좋습니다.
String custname = request.getParameter("customerName");
String query = "SELECT account_balance FROM user_data WHERE user_name = ? ";
PreparedStatement pstmt = connection.prepareStatement( query );
pstmt.setString( 1, custname);
ResultSet results = pstmt.executeQuery( );

Java의 PreparedStatement, C# .NET의 OleDbCommand 등이 이를 구현하고 있으며 이외에도 Ruby, PHP, Perl 등 다양한 언어에 Prepared Statement 구현체가 존재합니다.
또한 SQL 인젝션과 유사한 HQL 인젝션이 존재하는 SQL 추상화 계층인 HQL(Hibernate Query Language)에도 Prepared Statement 형태의 구현체가 존재합니다.

Stored Procedures 사용하기

저장 프로시저 (Stored procedure)란 DBMS에 저장되어 재사용 및 공유할 수 있는 일련의 SQL 쿼리 집합입니다.
Stored Procedure가 항상 SQL 인젝션으로 부터 안전하지 않지만, 특정 표준 Stored Procedure를 사용하면 Parameterized Query를 사용하는 것과 동일한 효과를 갖게 됩니다.
다만, Stored Procedure를 사용할 경우 오히려 시스템이 노출될 경우의 위험을 증가시킬 수 있습니다.
가령 db_datareader, db_datawriter, db_owner세 가지 기본 역할이 존재하는 MS SQL Server에서는 Stored Procedure 실행을 위해 실행 권한(Execute right)이 필요하며, 만약 이 세가지 역할만 사용하는 서비스라면 웹앱이 db_owner 역할로 실행되어야 Stored Procedure를 사용할 수 있게 됩니다.
따라서 사용자에게 읽기 접근 권한만 할당하기 위해 db_datareader 역할을 할당하는게 불가능해지며, 공격자는 DB에 대한 모든 권한을 얻게 됩니다.

String custname = request.getParameter("customerName");
try {
  // Stored Procedure를 호출할 때, 매개변수들을 인자로 전달한다.
  CallableStatement cs = connection.prepareCall("{call sp_getAccountBalance(?)}");
  cs.setString(1, custname);
  ResultSet results = cs.executeQuery();
  // … result set handling
} catch (SQLException se) {
  // … logging and error handling
}

입력 허용 목록을 통한 유효성 검사

만약 사용자 입력에 의해 변경될 값이 테이블 이름, 컬럼 명 처럼 바인드 변수를 할당할 수 없는 위치라면 쿼리를 재설계 하거나, 설명할 입력 유효성 검사를 수행하는 것이 알맞은 방어책 입니다.
이때, 테이블 또는 컬럼 명을 사용자 매개변수 값을 통해 전달 받을 경우, 해당 값이 다른 테이블의 다른 컬럼을 이름을 가질 수도 있습니다.
이러한 경우 근본적으로 이를 막도록 코드를 재작성 하는것이 좋지만, 이는 현실적으로 쉽지 않습니다. 따라서 사용자 매개변수를 예상 가능한 테이블에 매핑하여 유효하지 않은 사용자 입력이 쿼리에 포함되는 것을 막아야 합니다.

String tableName;
// 사용자 매개변수 값에 따라 tableName을 코드에서 지정합니다.
switch(PARAM):
  case "Value1": tableName = "fooTable";
                 break;
  case "Value2": tableName = "barTable";
                 break;
  ...
  default      : throw new InputValidationException("unexpected value provided"
                                                  + " for table name");

추가로, 꼭 동적 쿼리를 사용해야 한다면 동적 쿼리에 SQL 구문을 삽입할 수 없도록 API 또는 StoredProcedure의 매개변수를 가능한 문자열이 아닌 타입으로 받는것이 좋습니다.
즉, 예를 들어 Date, Number, boolean, enum 등으로 받게 된다면 안전하게 사용자로부터 입력을 받는것이 가능합니다.

public String someMethod(boolean sortOrder) {  String SQLquery = "some SQL ... order by Salary " + (sortOrder ? "ASC" : "DESC");`  ...

참고

[DB] DB Locking 알아보기

Mon, 26 Feb 2024 01:13:22 +0900

서론

CS 스터디에서 2월 20일에 발표한 DB Locking에 대해 정리한 문서를 블로그에 공유하고자 한다.

DB Locking이란?

병행 트랜잭션이 가능한 환경에서, 변경중인 record를 다른 transaction들이 접근하지 못하도록 막음으로써, 병행 수행 문제를 해결하려는 접근 방법입니다.
이러한 Locking을 위한 규약(Protocol)으로는 Shared Locking Protocol, 2PLP(2-Phase Locking Protocol), Multiple Granularity Locking Protocol 이 있습니다.

병행 트랜잭션(Concurrent Transaction) 이란?

동시에 실행되고 있는 둘 이상의 트랜잭션을 의미합니다.

병행 트랜잭션의 장점

DB의 공용도(Sharability) 제고

응답시간(Response Time) 단축

시스템 활용도(System Utilization) 증대

병행 트랜잭션의 동시성 문제

병행 트랜잭션의 병행 수행률이 상승할수록, 아래와 같은 병행 문제들의 발생률도 상승합니다.
설명의 편의를 위해 병행 실행되는 트랜잭션 두 가지를 아래에서 T1, T2라고 부르도록 하겠습니다.

갱신 분실(Lost Update)

두 트랜잭션이 병렬로 같은 데이터를 읽고 갱신하는 과정에서, 한 트랜잭션이 다른 트랜잭션의 갱신 값을 덮어쓰는 문제입니다.

예시) T1이 연산 후 갱신 작업을 수행한 뒤, 이후에 T2가 갱신된 값이 아닌 이전의 값을 기준으로 연산 후 갱신 작업을 수행해 T1의 갱신이 무효화 됩니다.

모순적 읽기(Inconsistent Read)

두 트랜잭션이 병렬로 같은 데이터를 읽고 갱신하는 과정에서, 데이터 불일치가 발생하는 문제입니다.

Dirty Read

격리성 수준이 Read Uncommitted 이하인 환경에서 발생가능한 문제로, 한 트랜잭션이 다른 트랜잭션으로부터 커밋되지 않은 값을 읽어 발생하는 문제입니다.

예시) T1이 커밋되기 전, 중간에 T2가 T1에서 작업하던 데이터(T1의 수정이 반영되지 않은)을 읽고 작업을 수행해 T1 연산 이전의 값으로 T2가 수행되게 됩니다. 이는 정확하지 않거나 일관되지 않은 결과를 야기할 수 있습니다.

Non-repeatable Read

같은 데이터를 한 트랜잭션 내에서 읽었음에도, 둘의 값이 다른 문제입니다.

예시) T1이 한 데이터를 두 번 읽을 때, 중간에 T2가 해당 데이터의 값을 변경한 뒤 커밋하게 되면 두 번째로 읽었을 때의 값은 처음 읽었던 값과 다르게 됩니다.

Phantom Read

같은 조건에 대한 검색을 한 트랜잭션 내에서 수행했음에도, 다시 읽으려 할 때 이전에 존재하던 값이 없어지거나, 새로운 값이 추가로 검색되는 문제입니다.

예시) T1이 한 데이터를 두 번 읽을 때, 중간에 T2가 해당 데이터를 삭제한 뒤 커밋하게 되면 두 번째로 읽었을 때 해당 데이터는 존재하지 않게 됩니다.

연쇄적 롤백(Cascading Rollback)

한 트랜잭션이 갱신한 데이터를 다른 트랜잭션이 또 다시 갱신한 뒤, 앞선 트랜잭션을 롤백하려할 때 이후 실행했던 트랜잭션도 롤백해야 하나 이미 해당 트랜잭션은 완료되어 롤백이 불가능한 문제입니다.

예시) T1이 한 데이터를 갱신한 뒤, T2이 해당 데이터를 또 갱신한 뒤 완료처리한 상태에서 T1을 롤백하려 하면 T2이 처리한 부분에 대해서는 롤백이 불가능하게 됩니다.

Transaction Schedule이란?

트랜잭션들이 연산을 실행하는 순서를 의미합니다.
스케줄의 개수는 Interleaving(트랜잭션을 쪼개서 수행하는 것)이 가능한 경우 거의 무한대이고, 허용되지 않으면 $n!$ 개 입니다.
병행 수행상 문제가 야기되느냐 그렇지 않느냐에 따라 직렬/비직렬 스케줄로 나뉩니다.

직렬 스케줄(serial Schedule)

스케줄에 포함된 모든 트랜잭션이 하나씩 실행되는 스케줄을 의미합니다.
병행 수행의 문제가 발생하지 않으나, 병행 트랜잭션으로 실행되지 않게 됩니다.

비직렬 스케줄(non-serial Schedule)

스케줄에 포함된 모든 트랜잭션이 서로 interleaved되는 스케줄을 의미합니다.
같은 트랜잭션 내 작업이라도 쪼개서 수행될 수 있기 때문에 쪼개진 작업이 실행되는 시점에 따라 잘못된 결과를 얻을 수 있습니다.

직렬 가능 스케줄(serializable Schedule)

어떤 직렬 스케줄과 동등한 비직렬 스케줄을 의미합니다.
모든 충돌 직렬 가능 스케줄은 뷰 직렬 가능 스케줄이지만, 역은 성립하지 않습니다.

충돌 직렬 가능 스케줄

비직렬 스케줄 S에 대해 충돌 동등한 직렬 스케줄 S’가 존재하면, S를 충돌 직렬 가능 스케줄 이라고 합니다.

뷰 직렬 가능 스케줄

비직렬 스케줄 S에 대해 뷰 동등한 직렬 스케줄 S’가 존재하면, S를 뷰 직렬 가능 스케줄 이라고 합니다.

스케줄 동등

결과(result) 동등

결과가 동일한 스케줄을 의미합니다.

충돌(conflict) 동등

충돌 연산의 순서가 동일한 스케줄을 의미합니다.

뷰(view) 동등

스케줄 S1, S2에 포함된 트랜잭션이 같고 아래 조건을 만족하는 경우를 의미합니다.

S1에서 $T_i$가 $x$의 초기 값을 읽는다면, S2에서도 그러해야 합니다.
S1에서 $T_i$의 모든 read(x)가 $T_j$가 write한 x값을 읽는다면, S2에서도 그러해야 합니다.
S1에서 $T_i$가 write(x)를 마지막으로 수행하면, S2에서도 그러해야 합니다.

Lock 이란?

DB상의 데이터 항목에 대한 잠금장치입니다.
Lock이 걸린 데이터 항목은 Lock을 건 트랜잭션만 접근할 수 있습니다.
Lcok은 Lock을 건 트랜잭션에 의해서만 Unlock할 수 있습니다.

Lock의 종류

공용 로크(Shared Lock, S-Lock)

다른 트랜잭션이 해당 데이터를 Read 할 수 있습니다.

전용 로크(Exclusive Lock, X-Lock)

다른 트랜잭션이 해당 데이터를 Read/Write 할 수 없습니다.

로크 단위(Lock granularity)

row, table, database 등 Locking할 자원의 크기를 말합니다.
단위의 크기가 커질수록 병행성 수준은 낮아지고, 병행 제어 기법은 간단해집니다.

로크 호환성 (Lock Compatibility)

이미 자원에 특정 Lock이 설정되어 있는 경우, 다른 트랜잭션도 해당 자원에 대해 Lock을 설정할 수 있는지 여부를 말합니다.

구 분	Request S-lock	Request X-lock
S-locked data item	ok	not ok
X-locked data item	not ok	not ok

Locking Protocol

아래 설명된 Protocol들 이외에도 기본적인 Locking Protocol은 다음과 같습니다.

트랜잭션 T가 x에 대해 read(x)/write(x) 연산을 하려면 먼저 lock(x) 연산을 실행해야 한다.
트랜잭션 T가 실행한 lock(x)에 대해서는 T가 모든 실행(Task)을 종료하기 전에 unlock(x) 연산을 수행해야 한다.
트랜잭션 T는 다른 트랜잭션에 의해 lock이 걸려있는 x에 대해 lock(x) 를 실행할 수 없다.
트랜잭션 T는 자신이 lock을 걸지않은 x에 대해 unlock(x) 을 실행할 수 없다.

`Shared Locking Protocol(공용 로킹 규약)`

트랜잭션 T는 read(x) 전 반드시 lock-S(x) 또는 lock-X(x)를 실행해야 함.
트랜잭션 T는 write(x) 전 반드시 lock-X(x)를 실행해야 함.

이러한 규약 때문에 공용 로킹 규약은 직렬가능성(serializability) 을 보장하지 못합니다.

직렬가능성(serializability) : 비직렬 스케줄을 직렬 스케줄로 변환할 수 있는지를 의미합니다.
- lock과 unlock이 병렬로 수행될 수 있으므로 병행 처리되는 트랜잭션들이 서로 간섭할 수 있어 직렬 가능성이 보장되지 않습니다.

`2PLP(2-Phase Locking Protocol, 2단계 로킹 규약)`

lock만 가능한 Phase와 unlock만 가능한 phase를 나누어 로킹을 수행하는 규약입니다.
직렬가능성을 보장하지만, Deadlock 문제가 존재하는 규약입니다.
변형으로는 Strict 2PLP, Rigorous 2PLP가 존재하며, 상용 DBMS에서는 이 둘 중 하나를 사용합니다.

1 단계(Growing Phase)

트랜잭션은 계속해 lock을 획득할 수 있으나, unlock 연산은 실행할 수 없습니다.

2 단계(Shrink Phase)

unlock 연산만 실행할 수 있으며, 일단 Lock을 해제하면 더 이상 lock을 획득할 수 없습니다.

Strict 2PLP(엄격 2단계 로킹 규약)

2PLP에 ‘모든 X-lock은 트랜잭션 완료시까지 unlock 할 수 없다‘는 규칙이 추가된 형태입니다.
구현이 어려우나 성능이 높고, 연쇄 복귀 문제(Cascading Rollback) 가 발생하지 않습니다.

Rigorous 2PLP(엄밀 2단계 로킹 규약)

2PLP에 ‘모든 lock은 트랜잭션 완료시까지 unlock 할 수 없다‘는 규칙이 추가된 형태입니다.
구현은 쉬우나 성능이 낮다는 단점이 있습니다.

`Multiple Granularity Locking Protocol(다중 단위 로킹 규약)`

병행성 수준을 감소시키지 않기 위해, 필요 이상의 크기로 locking 하지 않는 방법입니다.

로킹 계층 트리 : DB -> 구역(Area) -> 파일(File) -> 레코드(Record)
DB: 모든 파일을 포함하는 데이터베이스입니다. 데이터베이스는 여러 파일로 구성됩니다.
구역(Area): 파일들로 이뤄진 데이터베이스 내 특정 영역입니다.
파일(File): 관련된 레코드들의 그룹입니다.
레코드(Record): DB 테이블에서 하나의 행입니다. 레코드는 여러 필드로 구성됩니다.

Optimistic Lock/Pessimistic Lock란?

낙관적 로크(Optimistic Lock)

다른 트랜잭션과 충돌하지 않는다고 가정하고, 별도의 Locking 없이 자원에 접근하는 것을 말합니다.
병행 제어를 위해 아래 세 과정을 수행하며, 각 과정마다 Start(T), Validation(T), Finish(T) 세 가지의 타임스탬프 를 사용합니다.

타임스탬프 : 시스템에서 트랜잭션을 유일하게 식별하기 위해 부여한 식별자(identifier) 로, 트랜잭션이 시스템에 들어온 순서대로 부여합니다.

과정

판독 단계(Read Step) : 트랜잭션에 필요한 자료를 DB로 부터 읽어 Local Working Area에 복사합니다. 이후 모든 갱신은 사본을 대상으로 수행합니다.
확인 단계(Validation Step): 직렬(Serialization) 가능성 위반 여부를 검사합니다.
기록 단계(Write Step): 확인 단계를 통과하면 DB에 반영하고, 통과하지 못했다면 실행 결과는 취소하고 트랜잭션은 복귀합니다.

비관적 로크(Pessimistic Lock)

다른 트랜잭션과 충돌한다고 가정하고, 트랜잭션을 처리하기 전에 자원에 대해 Locking을 시도하는것을 말합니다.

과정

자원에 대해 Lock을 겁니다.
트랜잭션을 실행합니다.
자원에 대해 Unlock을 수행합니다.

트랜잭션이 비정상 종료된 경우 Lock을 해제할 해결책이 있는가? 없다면 직접 해결 가능한가?

잘 설계된 DBMS에서는 Lock이 오랫동안 유지되어 Deadlock과 같은 상황을 발생시키지 않도록 여러 대비책을 갖고 있으며, 대부분의 DBMS에서는 Lock 관리를 위한 기능을 제공합니다.

Lock Timeout

Lock을 걸 때, 타임아웃을 설정해 일정시간이 지나면 자동으로 Lock을 해제하도록 합니다.

Deadlock Detection

교착상태가 발생하면 사후에 트랜잭션들 중 하나를 강제종료(rollback) 시키는 조치를 취하는 방식입니다.

일반적인 회복 방법

이외에도 Redo, Undo와 같은 회복 방법을 통해 트랜잭션으로 손상된 부분을 회복시킬 수 있습니다.

Redo (Media Recovery)

비소멸장치(디스크, 테이프 등)의 내용 손상에 대한 회복 기법입니다.
가장 최근의 복제본(dump)을 적재시키고, 해당 복제본 이후의 변경을 log를 이용해 재실행하여 DB를 복원합니다.

Undo

log를 이용해 모든 변경을 취소시키므로써 DB를 복원합니다.

소멸 장치의 정보 회복

Log 이용 회복

트랜잭션이 Write 연산을 실행하거나, 트랜잭션의 시작/완료/철회와 같은 특별 활동시 기록되는 Log를 활용해 회복하는 방법입니다.
Log는 On-line log(실행중인 트랜잭션에 대한 로그), Archival log(누적되는 로그를 안정 저장장치에 저장한 것)로 나뉩니다.

지연 갱신(Deferred Update)의 회복

트랜잭션이 부분 완료될 때 까지 DB 변경내역을 log에 전부 기록한 뒤, 부분 완료되면 보류시킨 Output 연산을 log를 사용해 처리합니다.
트랜잭션 실행 중 장애가 발생했다면 처음부터 다시 실행하고, 완료 후 장애가 발생했다면 Log을 사용해 트랜잭션을 Redo 합니다.

즉시 갱신(Immediate Update)의 회복

트랜잭션이 실행되는 동안 발생한 변경 내용을 DB에 그대로 반영해 처리합니다.
트랜잭션 실행 중 장애가 발생했다면 해당 트랜잭션에 대한 Undo를 실행하고, 완료 후 장애가 발생했다면 트랜잭션을 Redo 합니다.

검사시점(Check Point) 회복

Log를 이용할 경우 Redo/Undo 대상 트랜잭션을 찾기위해 log 전체를 조사하거나,불필요한 Redo를 반복한다는 문제를 해결하기 위해 일정 간격으로 CheckPoint를 설치해 이를 사용하는 기법입니다.
Log를 차례로 검사하며 트랜잭션의 start를 만났다면 해당 트랜잭션을 Undo-list에, 트랜잭션의 commit을 만났다면 Undo-list에서 삭제하고 Redo-list에 추가합니다. 이후 Undo-list의 트랜잭션을 log에 기록된 역순으로 Undo를, Redo-list의 트랜잭션을 log에 기록된 순서로 Redo를 수행합니다.

그림자 페이징(Shadow Paging) 기법

트랜잭션을 실행하는 동안 2개의 page table을 유지하는 방법입니다.
current page table은 write 연산을 실행할 때 변경하며, shadow page table은 트랜잭션 실행 직전의 상태를 유지합니다.
트랜잭션 완료 전 장애가 발생한 경우 shadow page table을 복사해 실행 직전으로 복귀시킵니다.

참고 자료

[자료구조] B Tree와 B+tree 알아보기

Sun, 18 Feb 2024 09:58:46 +0900

서론

CS 스터디에서 2월 13일에 발표한(정확히는 나는 2일 뒤인 15일에 발표했다.) B 트리와 B+ 트리에 대해 정리한 문서를 블로그에 공유하고자 한다.

B-Tree와 B+Tree는 무엇일까

B 트리 (B-Tree)

이진 트리를 확장해 한 노드가 가질 수 있는 자식 노드의 갯수가 2개 이상인 자가 균형 이진 검색 트리(Self Balancing Binary Search Tree)의 일종이며, 각 노드가 갖고있는 키 들은 정렬되어 있습니다.
다른 자체 균형 이진 검색 트리와 달리, B 트리는 DB, File System과 같이 큰 데이터 블록을 읽고 써야하는 스토리지 시스템에 적합합니다.

B 트리의 성질

차수 m(노드 중 가장 많은 자식을 갖는 노드의 자식 수)을 갖는 B 트리는 아래와 같은 성질을 만족합니다.

모든 노드는 최대 m개의 자식이 존재합니다.
모든 내부 노드는 최소 ⌈m/2⌉ 개의 자식이 존재합니다.
루트 노드는 (리프가 아닌 한) 최소 2개의 자식이 존재합니다.
k개의 자식이 있는 리프가 아닌 노드는 k-1 개의 키를 갖고 있습니다.

B 트리의 노드들

B 트리를 이루는 노드는 내부 노드, 루트 노드, 리프 노드로 구성됩니다.

내부 노드 (Internal Node)

적어도 하나의 자식을 갖는 노드로, 리프 노드와 루트 노드를 제외한 모든 노드입니다.
이들은 일반적으로 하위 포인터, 데이터 포인터, 검색 키의 순서 집합으로 표현됩니다.
모든 내부 노드는 최대 U개에서 최소 L개의 자식을 포함합니다. 따라서 내부 노드 내 요소 수는 ‘하위 포인터 수 - 1’ 입니다. (요소 수는 L-1 보다 높고, U-1 보다 낮습니다.)

따라서 U는 2L 또는 2L - 1 이고, 각 내부 노드들은 최소 절반 이상 채워져 있습니다.
- 이는 두 절반이 가득 찬 내부 노드를 하나의 노드로 병합하거나, 하나의 완전한 노드를 두 개의 정상적인 노드로 나눌 수 있음을 의미합니다.
- 이러한 점을 통해, B 트리는 새 값을 삽입하거나 삭제하고 B 트리 속성을 유지하도록 트리를 조절할 수 있습니다.

내부 노드의 구조

$pt_0$	$k_0$	$pt_1$	$pr_0$	$k_1$	$pt_2$	$pr_1$	…	$k_{K-1}$	$pt_K$	$pr_{K-1}$

$pt_i$ : 하위 서브 트리의 루트 노드를 가리키는 포인터
$pr_i$ : 데이터를 갖고 있는 레코드를 가리키는 포인터
$k_i$: zero-based 노드 인덱스 $i$의 검색 키

또한, 각 내부 노드의 키는 해당 노드의 서브 트리를 나누는 기준 값으로 사용됩니다.

만약 내부 노드에 3가지 자식 노드(또는 트리)가 있는 경우, 내부 노드에는 최소 2개의 키(예시로 $a_1$, $a_2$)가 있어야 합니다.
- 가장 왼쪽 서브 트리의 모든 값은 $a_1$보다 작고, 중간의 서브 트리의 모든 값은 $a_1$ 보다 크고 $a_2$보다 작으며, 가장 오른쪽 서브 트리의 모든 값은 $a_2$보다 큽니다.

루트 노드 (Root Node)

루트 노드의 자식 수는 내부 노드와 동일한 상한이 존재하지만, 하한은 존재하지 않습니다.

전체 트리에 L-1 보다 적은 요소가 존재한다면, 루트 노드는 트리에서 자식이 전혀 없는 유일한 노드가 됩니다.

리프 노드 (Leaf Node)

실질적인 데이터 객체/청크를 갖는 노드입니다. 모든 리프 노드들은 같은 레벨에 존재해야 합니다.

B 트리의 장점

정렬되어있는 키

저장된 키들이 정렬되어 있어, 순차적인 순회에 유용합니다.

동일한 삽입/삭제/검색 시간 복잡도

기존의 이진 탐색 트리와 달리, 한 노드에 저장할 수 있는 키의 수가 많아 트리는 더 얕은 높이를 가질 수 있게 되었습니다.
이러한 계층형 인덱스를 사용하므로써 디스크 I/O가 줄어들어 더 낮은 삽입/삭제/검색 시간 복잡도를 가집니다. 이러한 점 때문에 B 트리는 대용량 데이터 셋, 실시간 애플리케이션에 적합합니다.
특히 DB에서 B 트리 인덱스를 사용하면 검색 성능을 크게 향상 시킬 수 있습니다.

DBMS에서는 인덱스 키 - PK가 매칭이 되어있는 B 트리를 만들어두고 이를 사용합니다.
- 인덱스를 통해 PK를 찾고, 찾은 PK를 통해 레코드를 찾습니다.
- DBMS가 PK를 통해 레코드를 찾으려면, 테이블 전체를 뒤져 검색 해야하지만, B 트리 인덱스를 활용하면 트리를 몇 단계 탐색하므로써 PK를 찾을 수 있고 그 PK를 통해 레코드를 찾아올 수 있으므로 속도가 더 빠릅니다.

자체 균형

B 트리는 자체 균형 이진 검색 트리(Self Balancing Binary Search Tree)의 일종이므로 항상 최적의 높이를 유지하고자 지속적으로 스스로 균형을 맞추려고 합니다.
따라서 기존의 이진 검색 트리의 경우 작업이 최악의 경우(트리가 한쪽으로 쏠린 경우) O(N)의 시간 복잡도를 가졌지만, B 트리는 작업이 최악의 경우에도 O(logN)의 시간복잡도를 유지하도록 보장합니다.

자체 균형 이진 검색 트리(Self Balancing Binary Search Tree) : 임의의 아이템 삽입/삭제 이후 자동으로 높이를 낮게 유지하는 노드 기반의 이진 검색 트리를 의미합니다. 대표적인 예시로 AVL 트리, B 트리, RBT 등이 있습니다.

B 트리의 단점

더많은 디스크 공간 사용

균형 유지를 위해 추가적인 포인터 및 헤더 정보를 유지해야 하므로 더 많은 공간을 사용합니다.

다른 자료 구조에 비해 느린 속도

삽입/삭제 연산 이후 균형 유지를 위해 회전, 병합과 같은 재배치 작업을 수행할 수 있으며, 이 과정에서 오버헤드가 발생할 수 있습니다.

B+ 트리 (B+ Tree)

위는 분기 인자 b=4이며, 1~7 범위의 키와 $d_1$ ~ $d_7$의 데이터 값들을 연결하는 b+ 트리 예시 입니다.

B 트리의 변종 중 하나로, 각 노드가 키-값 쌍이 아닌 키만 포함하며(인덱스 인트리) 하단에 링크드 리프 노드들로 이뤄진 추가적인 레벨(데이터 엔트리)이 붙어있는 B 트리로 볼 수 있습니다.
노드 당 m개 이하의 자식이 있는 다항 트리(m-ary tree) 라고도 일컬어지며, 분기 인자(branching factor, 각 노드 당 자식의 수) $b$ 를 기준으로 삽입/삭제/검색 작업이 $O(log_b{N})$ 의 시간 복잡도를 가집니다.
B+ 트리의 핵심 가치는 블록 지향 스토리지(block-oriented storage)(특히 파일 시스템)에서 효율적인 검색이 가능하도록 데이터를 저장하는 것입니다.

이진 검색 트리와 달리, B+ 트리는 팬아웃이 매우 높아 트리 내 요소를 찾는데 필요한 I/O 작업 횟수를 줄일 수 있기 때문입니다.
B+ 트리는 MS SQL, Oracle, SQLite 등의 RDBMS에서 테이블 인덱스를 구현하는데 활용됩니다.

B+ 트리의 성질

분기 인자가 $b$ 이며, 높이 h인 b+ 트리는 다음과 같은 성질을 갖습니다.

저장된 레코드는 최대 $n_{max} = b^h - b^{h-1}$ 개여야 합니다.
저장된 레코드는 최소 $n_{min} = 2\lceil {b\over2} \rceil^{h-1} - 2\lceil {b\over2}\rceil^{h-2}$ 개여야 합니다.
트리를 저장하기 위한 공간 복잡도는 O(n) 입니다.
레코드를 삽입/삭제/검색하는데 $O(log_b n)$의 시간 복잡도를 갖습니다.
B+ 트리 구조는 레코드 수가 증가/감소 함에 따라 확장/수축 할 수 있으며, 크기에 제한이 없습니다.
리프 노드들이 링크드 리스트 형태로 이어져 있어 빠른 중위 순회(in-order traversal)가 가능합니다.
리프 노드에서 부모 노드가 갖고 있는 키를 중복적으로 가질 수 있습니다(Key Duplication).

B+ 트리의 장점

순서대로 탐색이 가능

B 트리의 경우 모든 데이터 포인터가 리프 노드에 있지 않기 때문에 순서대로 연결된 리스트를 만들 수 없지만, B+ 트리의 경우 모든 데이터 포인터가 리프 노드에 존재하므로 순서대로 연결된 리스트를 만들 수 있습니다. 이를 통해 범위 쿼리나 정렬된 데이터가 필요한 작업들을 쉽게 수행할 수 있습니다.
이러한 점 때문에, B+ 트리는 DB 시스템 인덱스를 구축하는데 유용합니다.

정렬되어있는 키

자체 균형

동일한 삽입/삭제/검색 시간 복잡도

B+ 트리의 단점

B 트리 대비 더 높은 메모리 사용

키, 값(데이터 포인터)을 각 노드에 저장하는 B 트리와 달리, B+ 트리는 내부 노드에는 키만 저장하고 리프 노드 층에 데이터를 저장하기 때문에 키의 개수에 비례해 추가적인 메모리가 필요합니다.

B+ Tree가 B Tree에 비해 반드시 좋다고 할 수 있을까? 그렇지 않다면 어떤 단점이?

웬만한 경우 B+ 트리가 B 트리 보다 더 빠르게 검색할 수 있기 때문에 좋다고 할 수 있습니다.
B+ 트리는 B 트리와 달리 내부 노드에 값(데이터)을 저장하지 않으므로써 내부 노드에 저장되는 키의 수, 즉 팬아웃을 최대화 했고, 이를 통해 트리의 높이를 최소화 하기 때문입니다.
또한 범위 검색 작업 을 효율적으로 진행할 수 있습니다. 리프 노드가 서로 연결되어 있기 때문입니다.
그리고 삽입/삭제 작업이 리프 노드에서 수행되어 더 쉽고 시간 소모가 적습니다.
하지만, B 트리의 경우 특정 노드를 자주 사용하는 경우 더 빠를 수 있습니다. 자주 사용되는 노드를 상승 시킬 수 있기 때문에, 원하는 데이터에 도달하는데 필요한 비교 작업이 적어지기 때문입니다.

DB에서 굳이 RBT와 같은 트리를 사용하지 않고, B-Tree/B+Tree를 사용하는 이유는?

더 빠르기 때문입니다.
이를 설명하려면 먼저 RBT, 즉 레드-블랙 트리(Red-Black Tree)의 구조에 대해 알아야 합니다.
RBT는 B 트리/B+ 트리와 마찬가지로 자가 균형 이진 검색 트리(Self Balancing Binary Search Tree) 의 일종으로, 각각의 노드가 레드 또는 블랙의 색상 속성을 갖습니다.
루트 노드와 모든 리프 노드들은 블랙이며, 레드 노드의 양 자식 노드들은 모두 블랙이라는 특징 때문에, RBT는 블랙과 레드가 번갈아 나오는 형태를 띄게 됩니다(물론 블랙 다음에 블랙이 나올 수도 있습니다).
이러한 특징 때문에 루트 노드로 부터 가장 먼 리프 노드까지의 거리가 가장 가까운 리프 노드까지의 거리의 2배 보다 항상 짧다는 특성을 지니고, 이 때문에 삽입/삭제/탐색에 있어 B 트리와 마찬가지로 $O(logN)$의 시간 복잡도를 갖게 됩니다.
하지만, RBT는 일반적인 BST와 같이 자식을 둘 밖에 가질 수 없으나 B 트리는 둘 이상 가질 수 있기 때문에 훨씬 트리 높이가 짧아지고 더 적은 디스크 I/O 작업을 수행해 결과적으로 더 빠른 속도로 탐색을 진행할 수 있습니다.
또한 B 트리의 경우 내부 노드의 두 개 이상의 키들을 배열 로 다루므로 RBT가 하위 노드들을 참조해 탐색하는 것 보다 더 빠른 접근 속도를 갖게 됩니다.
이러한 차이 때문에 DB에서 B 트리/B+ 트리를 사용하게 됩니다.

오름차순으로 정렬된 인덱스가 있다고 할 때, 내림차순 정렬을 시도할 경우 성능이 어떻게 될까? (B-Tree/B+Tree의 구조를 기반으로)

B 트리의 경우

B 트리의 경우 내림차순 정렬을 시도할 경우, 모든 노드들을 역순으로 하나 하나 탐색해야 합니다. 따라서 B+ 트리 대비 낮은 성능을 보입니다.

B+ 트리의 경우

B+ 트리의 경우 내림차순 정렬을 시도할 경우, 리프 노드만 역순으로 탐색하면 되고, 리프 노드들이 링크드 리스트 형태를 띄고 있으므로 순차 접근에 최적화 되어있어 더 높은 성능을 보입니다.

database on 오늘도 개발을 한다.

[DB] PostgreSQL 알아보기 + PostGIS를 활용한 연산해보기 (w. DBeaver, GiST)

서론

개요

PostgreSQL?

기원

POSTGRES 프로젝트

왜 PostgreSQL을 써야할까?

장점

단점

MySQL -> PostgreSQL로 마이그레이션 하기

PostGIS의 공간 인덱스 및 공간 연산

공간 인덱스 생성하기

공간 연산 사용하기

참고

[DB] 공간 인덱스 알아보기 + 쿼리 성능 개선해보기 (w. SRS, EPSG, SRID)

서론

공간 인덱스(Spatial Index)란?

공간 데이터(Spatial Data)

공간 참조 시스템(SRS) #조사추가필요

EPSG:4326 - WGS 84#

EPSG:3857 - WGS 84 / Pseudo-Mercator / Spherical Mercator#

MySQL의 공간 데이터 타입

WKB와 WKT

WKT(Well-Known Text)

WKB(Well-Known Binary)

단일 지오메트리 값 자료형

GEOMETRY

POINT

LINESTRING

POLYGON

지오메트리 값 집합 자료형

MULTIPOINT

MULTILINESTRING

MULTIPOLYGON

GEOMETRYCOLLECTION

공간 인덱스(Spatial Index)

공간 인덱스와 비공간 인덱스

공간 인덱스

비공간 인덱스

공간 인덱스 사용하기

주의사항

지오메트리 컬럼 생성시 초기 SRID를 신중히 정할 것

참고

[DB] SQL Injection 알아보기 (w. PreparedStatement, Stored Procedures)

서론

SQL Injection에 대해 설명해 주세요.

공격 유형

에러 기반 SQL 인젝션(Error-based SQL Injection)

예시

UNION 기반 SQL 인젝션(Union-based SQL Injection)

UNION과 UNION ALL

예시

열 갯수 알아내기

블라인드 SQL 인젝션(Blind SQL Injection)

블라인드 불린 기반 SQL 인젝션(Blind Boolean-Based SQL Injection)

예시

블라인드 시간 기반 SQL 인젝션(Blind Time-Based SQL Injection)

예시

방어법 #

Prepared Statement 사용하기

Stored Procedures 사용하기

입력 허용 목록을 통한 유효성 검사

참고

[DB] DB Locking 알아보기

서론

DB Locking이란?

병행 트랜잭션(Concurrent Transaction) 이란?

병행 트랜잭션의 장점

DB의 공용도(Sharability) 제고

응답시간(Response Time) 단축

시스템 활용도(System Utilization) 증대

병행 트랜잭션의 동시성 문제

갱신 분실(Lost Update)

모순적 읽기(Inconsistent Read)

Dirty Read

Non-repeatable Read

Phantom Read

연쇄적 롤백(Cascading Rollback)

Transaction Schedule이란?

`PostgreSQL`?

`POSTGRES` 프로젝트

왜 `PostgreSQL`을 써야할까?

`공간 인덱스(Spatial Index)`란?

`공간 데이터(Spatial Data)`

`공간 인덱스(Spatial Index)`

`UNION`과 `UNION ALL`

`Shared Locking Protocol(공용 로킹 규약)`

`2PLP(2-Phase Locking Protocol, 2단계 로킹 규약)`

`Multiple Granularity Locking Protocol(다중 단위 로킹 규약)`