mathengi

redis 위치정보 처리(GeosPatial 자료구조)

worldint — Sat, 21 Dec 2024 12:38:05 +0900

Redis는 Geospatial 데이터를 사용하면 위치정보를 저장할 사용할 수 있다

Geospatial 자료구조는 sorted set의 확장이다

sorted set 형태로 데이터를 저장하는데

이때 내부적으로는 위도,경도를 geohash로 인코딩한 값을 저장하게 된다

Geohash란?
아래 사진 처럼 특정 위치(위,경도)를 문자열로 인코딩 하는 방식
지구를 평면 지도로 만들고 그것을
지구를 평면 지도로 만들고 그것을 나누어서 문자를 하나씩 맵핑해놓은것이다
중국부근이 w에 대응되고 그 w안에서 또 사각형으로 나누어서 문자들을 맵핑하고
이런식으로 쭉 나가는 것이다
그래서 서울은 wydm9가된다
https://geohash.softeng.co/ 여기서 확인 가능

저장

위치정보를 저장하게 되면

위 geohash가 sorted set의 score부분에 들어가게된다

Redis Cli에서는 GEOADD 명령어를 사용하여 key를 지정하고 경도, 위도, 이름을 저장할 수 있다

GEOADD location 126.823162 35.191378 "Vino Cafe"

만약 이런식으로 추가하게 되면

키는 'location' score는 위,경도데이터, member는 "Vino Cafe" 가 들어간다

저 위경도가 `wssdf7as` 이런 `geohash` 문자열로 바뀌고
이것이 정수형태로 또 변경되어서 `score`부분에 들어감

범위 검색

`GeoPatial`의 범위 검색하는 명령어는

`georadiusbymember`와 `georadius`가 있다

georadiusbymember : member를 기준으로 반경내의 다른 member검색

georadius : 입력된 위경도를 기준점으로 반경내의 다른 member검색

*이렇게 두개로 쓰던것 redis 6.2.0부터 `GEOSEARCH`로 통합되고 위의 것들은 deprecated되었다고 한다.

GEOSEARCH

georadiusbymember는 `FROMMEMBER`와 `BYRADIUS` 옵션을 통해서 사용가능

GEOSEARCH KEY FROMMEMBER "member" BYRADIUS 100 m  [ASC | DESC]
GEOSEARCH location FROMMEMBER "Vino Cafe" BYRADIUS 100 m ASC

georadius는 `BYLONLAT`과 `BYRADIUS`옵션을 통해 사용 가능

GEOSEARCH locations BYLONLAT 127.0 37.5 BYRADIUS 100 km

spring에서의 사용

	public List<String> findDriversWithLocation(Double latitude, Double longitude) {
		String key = RedisKey.DRIVER_LOCATIONS;
		Distance radius = new Distance(5, Metrics.KILOMETERS);
		Circle circle = new Circle(new Point(longitude, latitude), radius);

		GeoResults<RedisGeoCommands.GeoLocation<Object>> results = redisTemplate.opsForGeo()
			.radius(key, circle);

		List<String> driverIds = results.getContent().stream()
			.map(result -> (String)result.getContent().getName())
			.collect(Collectors.toList());

		return driverIds;
	}

[spring] 캐시 추상화

worldint — Thu, 5 Dec 2024 17:05:16 +0900

캐시란

애플리케이션 개발시 자주 사용되는 데이터들을 '캐시 저장소'라는 곳에 넣어두고
다음에 또 동일한 데이터를 요청시에 그 캐시 저장소에서 꺼내서 주는것

spring의 캐시 추상화

spring에서는 이런 캐시 기능을

AOP 패러다임에 따라서

추상화하여 사용하기 쉽게 해놓음

사용 방법

원하는 메서드위에 어노테이션을 붙임으로 캐시기능을 사용할 수 있다

클래스나 인터페이스 단위로도 캐시를 적용 할 수 있지만 드물다고 한다

스프링에서는 아래와 같은 캐싱을 위한 메서드 레벨 어노테이션이 존재한다(공식문서에 몇개 더 있음)

@Cacheable
@CachePut
@CacheEvict

@Cacheable

@Cacheable("books")
public Book findBook(ISBN isbn) {...}

* isbn은 책의 고유 번호 같은것

findBook 메소드는 'books'라는 이름의 캐시에 연결되어있다
처음 요청시에는 책의 정보를 디비에서 받아오고
그 정보를 "books"라는 이름의 캐시에 `isbn` 매개변수를 key로 두고 디비에서 가져온 책정보를 `value`로 저장한다
두번째에 동일한 `isbn`으로 요청이 들어오면 캐시에서 `isbn`과 동일한 키가 있어면 그 데이터를주고 해당 메서드는 실행되지않는다
@Cacheable을 사용하는 방식으로는
- 1.위와 같이 키를 명시적으로 지정하지 않는 방법 : 그럼 매개변수가 키가된다
- 2. 고정된 스트링 키를 사용하는방식 `@Cacheable(value = "books", key = "'all'")`
- 3. 객체를 키로 사용하는 방식`@Cacheable(value = "books", key = "#isbn")`
- 4. 객체의 특정 필드를 키로 사용하는방식`@Cacheable(value = "books", key = "#isbn.bookNumber")`

@CachePut

CachePut은 Cachealbe과 비슷하지만 조회시에 캐시저장소에 저장은 하지만 해당 메소드를 스킵하지는 않는다

@CacheEvict

캐시를 제거하는 어노테이션
allEntries=true로 해놓으면 books라는 이름의 캐시 전체 삭제

@CacheEvict(cacheNames="books", allEntries=true) 
public void loadBooks(InputStream batch)

특정 키의 캐시만 삭제하는 경우

@CacheEvict(value = "book", key = "#book.bookNo")
public void updateBook(Book book) {
}

위의 캐쉬 기능을 사용하기 위해서는 config 클래스에 @EnableCaching 어노테이션을 적용해야 사용가능

@EnableCaching
@Configuration 
public class CacheConfig {
    ... 
}

데이터베이스 옵티마이저

worldint — Sun, 1 Dec 2024 10:20:51 +0900

옵티마이저란?

데이터베이스 옵티마이저(Database Optimizer)는

데이터베이스에서 SQL 쿼리를 빠르고 효율적으로 실행하기 위해 최적의 실행 계획을 만들어준다

옵티마이저의 목적은 쿼리 실행에 필요한 비용을 최소화하여 성능을 극대화하는 것이다

이 비용에는 디스크 I/O, CPU 사용량, 네트워크 트래픽 등이 포함된다

https://coding-factory.tistory.com/743

옵티마이저의 종류

규칙 기반 옵티마이저(Rule-Based Optimizer, RBO):
이 옵티마이저는 사전 정의된 규칙에 따라 쿼리를 최적화한다
예를 들어, 특정한 형태의 쿼리에서는 항상 인덱스를 사용하는 방식으로 최적화하는 식
이 방식은 상대적으로 간단하지만 최신 데이터베이스에서는 사용하지 않는다

특정 우선순위
비용 기반 옵티마이저(Cost-Based Optimizer, CBO):
대부분의 현대적인 데이터베이스 관리 시스템(DBMS)에서 사용되는 방법
CBO는 테이블의 통계 정보와 실행 비용을 바탕으로 가장 효율적인 실행 계획을 선택한다
테이블의 데이터 분포나 인덱스의 효율성 등을 고려하여 더 정교한 실행 계획을 수립
통계정보는 딕셔너리라는곳에 저장,업데이트한다

옵티마이저 동작 방식

Parser : SQL문장의 문법, 구조를 분석하여 쿼리 트리 생성
- 쿼리트리란
```
SELECT name
FROM employees
WHERE department = 'IT';

//위와 같은 쿼리가 들어오면 아래의 트리구조로 변경이됨
            SELECT
              |
            FILTER (department = 'IT')
              |
           TABLE SCAN (employees)
```
Optimization
1. Query Trasformer : 파싱된 SQL을 보고, 동일한 결과를 도출하는 더 좋은 쿼리가 있으면 그것으로 바꿈
2. Estimator: 시스템 통계정보를 딕셔너리로부터(통계정보 저장하는 저장소)
  수집하여 SQL을 실행할 때 소요되는 총비용을 계산한다
3. Plan Generator : Estimator를 통해 계산된 값들을 토대로 후보군이 되는 실행계획을 도출한다
Row-Source Genarator : 옵티마이저가 생성된 실행계획을 SQL 엔진이 실제 실행할 수 있는 코드나 프로시저 형태로 포맷팅 한다
- postgresql을 예로들면 row-source genarator에 의해서 c언어로 된 함수가 생성되고, 그것을 엔진이 실행하는 형태라고 한다
SQL Engine : sql을 실행합니다

통계정보

비용기반 옵티마이저에서 실행계획을 짜기 위해서 사용되는 정보이다

특정 주기를 설정하여 디비가 자동으로 통계정보를 갱신하도록 할 수 도 있고

사용자가 직접 만든 통계정보를 사용하도록 할 수도 있다

통계정보요소

테이블 크기	테이블에 저장된 총 레코드 수로, 테이블의 규모를 파악하여 최적의 접근 방식을 결정하는 데 사용된다
데이터 분포	특정 열의 값들이 어떻게 분포되어 있는지를 나타내며, 선택도를 예측하여 최적의 인덱스 사용 여부를 결정한다
인덱스 정보	인덱스가 어떤 열에 적용되었는지, 그리고 그 인덱스의 효율성을 평가하여 실행 계획을 수립하는 데 사용됨
널 값 비율	특정 열에 널(null) 값이 얼마나 있는지를 나타내며, 옵티마이저가 조인이나 필터링 조건을 더 효율적으로 처리하도록 도움
데이터 블록 수	테이블이나 인덱스를 저장하는 데 필요한 데이터 블록의 수로, I/O 비용을 예측하는 데 중요한 요소
클러스터링 팩터	인덱스의 순서와 테이블의 실제 데이터 순서 간의 관계를 나타내며, 테이블에 대한 접근 비용을 추정하는 데 사용

B+트리, B트리 비교

worldint — Sun, 1 Dec 2024 09:15:05 +0900

B+트리란?

B트리에서 확장된 개념으로, 리프 노드에만 실제 데이터를 담는다

B+트리는 리프 노드에만 데이터를 저장하고, 내부 노드에는 데이터가 아닌 키만을 저장한다

키는 데이터를 찾기 위한 인덱스 역할을 하며, 실제 데이터는 리프 노드에서만 접근 가능

이로 인해 모든 데이터 접근이 리프 노드에서 이루어지며, 데이터가 정렬된 형태로 연결되어 있다

B+트리는 리프 노드를 순차적으로 연결하는 포인터 집합을 가지고 있다.

인덱스된 순차 파일 처리시,

포인터를 이용하여, `키 : 값`을 일일이 비교하지 않고 다음 데이터에 접근해서 빠르게 처리할 수 있다.
(이부분 무슨 말인지 이해가 안된다, 다시 알아보자)

https://en.wikipedia.org/wiki/B%2B_tree#/media/File:Bplustree.png

데이터 삽입

처음 1,2가 노드에 들어있을때

3을 추가하면

노드의 최대 키을 초과하여( 3차이기 때문에 키는 2개가 최대이다)

중간에 있는값 2 를 부모노드로 승격시킨다

근데 이때 b트리와 다른점은 데이터는 리프에서만 접근하기 때문에

부모노드로 2를 올려도 리프에 2가 계속 남아있어야한다

부모노드의 2는 탐색키 역활이다.(3을 찾고 싶을때 이것이 2보다 큰지 작은지 따지는 용도)

또 5를 추가하면
2보다 크기 때문에 [2,3]이 있는 노드에 5를 추가하고
[2,3,5]가 되기 때문에 중간의 3을 부모노드에 추가하고 [2],[3,5]로 리프노드를 분할 하게된다

데이터 삭제

*경우의 수가 다양하다고한다

여기서 2를 삭제한다고 하면

리프노드에서 2를 제거하고
근데 노드의 최소 키보다 작아지기 때문에

형제 노드에서 3을 빌려온다

그리고 부모노드를 알맞게 정리한다

B트리 vs B+트리

특성	B-트리	B+트리
데이터 저장 위치	키와 데이터를 같은 노드에 저장	데이터는 리프 노드에만 저장
범위검색	상대적으로 비효율적	매우 효율적
단일 키 검색	더 빠를 수 있음	약간 느릴 수 있음
삽입/삭제	간단	리프 노드에서 주로 작업, 포인터 조정 필요

b+트리가 범위 검색에 좋은 이유 : 연속적 접근이 가능 하기 때문에,
리프 노드의 시작점만 찾으면 나머지는 연결된 노드를 따라가며 데이터를 빠르게 읽을 수 있습니다.
(예: id BETWEEN 10 AND 50)

여기서 삽입 삭제 해볼 수 있음

https://www.cs.usfca.edu/~galles/visualization/BPlusTree.html

데이터베이스 Cluster

worldint — Sat, 23 Nov 2024 12:04:43 +0900

클러스터란?

데이터베이스 클러스터링은 여러 대의 데이터베이스 서버(노드)를 하나의 논리적인 데이터베이스처럼 동작하게 만드는것

이를 통해 병렬처리, 고가용성 ,성능 향상

을 구현할 수 있다

고가용성

데이터 베이스에서 가용성이란
1년 동안 몇 분이 정지했음을 비율로 나타낸 것

고가용성이란 데이터베이스 장비(서버나 스토리지 등)를 각 2대 이상으로 구성하여

한쪽에 장애가 발생하면 동일한 데이터를 가진 복제 데이터베이스(이중화된 데이터베이스)로

빠른 시간내에서비스를 재개할 수 있도록 하는 것을 의미

병렬처리

데이터가 많거나, 복잡한 SQL을 실행하게 될 경우 많은 시간이 걸리게 된다

이때 동일한 데이터를 가지고 있는 여러 데이터베이스가

복잡한 SQL을 나누어서 작업한뒤
결과를 통합하여 넘겨준다면 훨씬 빠르게 결과를 얻을 수 있다

병렬처리가 될 수 있는 작업들을 디비들에게 잘 나누어 주어야한다

성능 향상

조회같은경우 사용자가 많아졌을 때, 어차피 같은 데이터를 가지고 있기 때문에
여러개의 디비에 부하를 분산 시켜 성능 향상을 시킬 수 있다

데이터베이스 트랜잭션

worldint — Sat, 23 Nov 2024 11:26:37 +0900

트랜잭션이란 무엇인가?

트랜잭션은 데이터베이스에서 하나의 논리적 작업 단위로 간주되는 일련의 연산

보통 은행 이체 작업을 예로 들어 설명한다

은행 계좌 이체 작업은 한쪽의 출금과 반대쪽의 입금 두 가지 연산이 함께 이루어져야만 올바른 결과를 가져온다

트랜잭션은 이러한 일련의 작업들이 모두 성공하거나 모두 실패하도록 보장하여 데이터의 일관성을 유지합니다.

ACID

관계형 데이터 베이스에서 하나의 트랜잭션(transaction)의 안전성을 보장하기 위해 필요한 성질

트랜잭션은 ACID라는 네 가지 기본 특성을 준수해야 한다

원자성(Atomicity): 트랜잭션 내의 모든 연산은 하나의 단위로 처리되어야 함
일부만 실행되거나 취소되는 일이 없어야 하며, 모두 성공하거나 모두 실패해야 함
예)디비에서 A테이블에 insert를하고, 그것과 연관된 B테이블을 수정하는 작업이 하나의 트랜잭션일때,
B테이블 수정에서 에러가 났을때 A테이블 insert 작업도 다시 원복되어야한다
일관성(Consistency): 트랜잭션 실행 전후에 데이터베이스는 일관된 상태를 유지해야 한다
이는 모든 데이터 무결성 제약 조건이 항상 만족됨을 의미
예) 학생테이블과 수강기록테이블이 있을때, 학생 한명이 삭제되었는데 그 학생의 수강기록은 남아있으면 안된다
격리성(Isolation): 동시에 실행되는 트랜잭션들은 서로 간섭하지 않아야 한다
하나의 트랜잭션이 완료되기 전까지는 다른 트랜잭션이 그 변경 내용을 볼 수 없다
지속성(Durability): 트랜잭션이 성공적으로 커밋되면 그 결과는 영구적으로 저장되어야 함
시스템 오류가 발생하더라도 데이터는 손실되지 않아야 한다

ACID는 완벽히 지켜지는게 아니고
상황에 따라(아래의 격리 수준에 따라) 다른 강도로 지켜진다

격리 수준(Isolation Levels)

트랜잭션 간의 격리성을 제어하기 위해 다양한 격리 수준이 존재한다

Read Uncommitted:
- 특징 : 가장 낮은 수준으로, 커밋되지 않은 데이터도 읽을 수 있다
- 문제점 :
  - 더티 리드 (Dirty Read):
    - 하나의 트랜잭션에서 변경된 데이터가 커밋되지 않았는데, 다른 트랜잭션이 이를 읽음.
    - 이후 원래 트랜잭션이 롤백하면 잘못된 데이터를 읽은 상태가 됨.
  - 데이터 일관성이 전혀 보장되지 않아 RDBMS 표준에는 격리수준으로 인정하지 않는다고 한다
Read Committed:
- 특징: 커밋된 데이터만 읽을 수 있다.
- 문제점:
  - 비반복 읽기 (Non-Repeatable Read):
    - 동일한 트랜잭션에서 같은 데이터를 두 번 조회할 때, 다른 트랜잭션이 데이터를 수정하고 커밋하면 결과가 달라질 수 있음.
    - 데이터가 일관되지 않게 보이는 문제를 초래.
Repeatable Read(반복 가능 읽기):
- 특징 : 동일한 트랜잭션 내에서는 같은 데이터를 읽을 때 항상 동일한 결과를 반환한다
- 문제점 :
  - 팬텀 리드 (Phantom Read):
    - 트랜잭션이 실행 중일 때, 다른 트랜잭션이 새로운 데이터를 삽입하면 동일한 조건으로 데이터를 조회했을 때 결과가 달라짐.
    - 예를 들어, 동일 트랜잭션에서 SELECT COUNT(*) FROM table이 10을 반환했는데, 다른 트랜잭션이 새 데이터를 삽입하면 그다음 작업에서 재조회 시 11로 반환됨.
Serializable:
- 특징: 가장 높은 수준으로, 트랜잭션을 순차적으로 실행한 것과 동일한 결과를 보장.
- 문제점:
  - 동시성 문제가 거의 발생하지 않지만, 성능 저하가 심각.
  - 트랜잭션 간의 락(lock)이 많이 발생하여 병목현상이 생길 수 있음.

격리 수준이 높아 질 수록 성능은 낮아진다

동시성 제어와 잠금(Locking)

동시에 여러 트랜잭션이 실행될 때 데이터의 일관성을 유지하기 위해 동시성 제어가 필요하다
이를 위해 잠금 메커니즘이 사용되며, 데이터에 대한 읽기 및 쓰기 잠금을 통해 트랜잭션 간의 충돌을 방지한다
락의 종류 : https://hwansci.tistory.com/160

트랜잭션에서 각각의 격리수준에 따라 발생할 수 있는 문제점 추가

이진트리, 이진탐색트리

worldint — Mon, 11 Nov 2024 13:11:03 +0900

이진 트리 (Binary Tree):
- 이진 트리는 각 노드가 최대 두 개의 자식 노드를 가지는 트리 구조
- 단순히 각 노드가 자식노드를 2개 이하로 가질 수 있다는 조건만 만족하면 그것은 이진트리라 할 수 있다

이진트리

이진 탐색 트리 (Binary Search Tree, BST):
- 이진 탐색 트리는 이진 트리의 한 종류이지만, 추가적인 정렬 조건을 만족해야 한다
- 각 노드의 왼쪽 자식에는 해당 노드보다 작은 값이, 오른쪽 자식에는 더 큰 값이 위치해야 한다
- 이런 조건을 만족함으로써 탐색 속도를 빠르게 할 수 있습니다. 왼쪽으로 가면 항상 더 작은 값을 찾고, 오른쪽으로 가면 더 큰 값을 찾을 수 있어 탐색 과정이 효율적입니다.

B-tree

worldint — Mon, 11 Nov 2024 13:10:31 +0900

binary search tree 에서 파생된것으로

BST에서 자식노드의 갯수에 제한을 없앤 것이 b-tree이다.

자식노드의 갯수가 3개 이상이려면
부모노드의 key도 하나 이상 이어야한다.

자식노드의 갯수에 따라 n차 b-tree로 불리는데

예시는 자식노드가 3개이므로 3차 B-tree이다.

부모노드의 key들은 오름차순으로 정렬된다.

B-트리에서 각 자식 노드는 부모 노드의 키 값들에 의해 포함할 수 있는 키 값의 범위가 결정된다.

root 노드 아랫 줄을 보면

왼쪽 노드에는 20보다 작은 값의 키 들이 들어갈 수 있고,

가운데에는 20보다 크고 40보다 작은 키,
오른쪽은 40보다 큰 키값이 들어가게 된다

B-tree의 중요한 파라미터들로는

최대로 가질 수 있는 자식노드의 수 (M) : M에 따라 M차 B-tree로 불린다. 위의 예시에서는 3
각 노드의 최대 key의 수 (M-1) : 노드에 들어있는 숫자의 갯수를 말함, 3차 b-tree는 최대 2개까지 들어있을 수 있다
각 노드의 최소 자녀 노드 수 (⎡M/2⎤): M/2의 올림, M이 3일때 2
(leef, root노드는 제외)
각 노드의 최소 key 수 (⎡M/2⎤- 1 ) : 예시에서는 1
(root node제외)
b-tree에서 internal node의 key가 x라면 자식노드의 수는 x+1

데이터 삽입 과정

데이터 삽입 할 때 시간복잡도

데이터 삭제 과정

데이터 삭제 할 때 시간복잡도

데이터 조회 과정

데이터 조회시의 시간복잡도

O(logN)의 시간 복잡도를 가짐
N은 테이터의 갯수

만약 데이터가 100개일 때, 3차 B-tree라면 $\log_3 100$
으로 4~5의 값이 나오고
그럼 높이가 4개에서 5개정도가 나오고 시간 복잡도도 그정도 나온다

데이터베이스 파티셔닝

worldint — Thu, 7 Nov 2024 19:19:46 +0900

디비 파티셔닝이란?

큰 테이블을 파티션이라는 작은 단위로 나누어 관리하는것

사용 이유

하나의 DBMS에 너무 큰 table이 들어가면서 용량과 성능 측면에서 많은 이슈가 발생하게 되었고,
이런 이슈를 해결하기 위한 방법으로 table을 ‘파티션(partition)’이라는 작은 단위로 나누어 관리하는 ‘파티셔닝(Partitioning)’기법 이 나타나게 되었다

파티션이라는 단위는 무엇인가?
하나의 파티션은 데이터베이스 내에서 데이터가 물리적으로 분리되어 저장되는 단위를 말하며,
주로 특정 조건에 따라 분리된다

아래는 그 조건들의 예시

범위 단위 (Range)
- 특정 값의 범위를 기준으로 데이터를 분리
- 예를 들어, 날짜가 "2024-01-01"부터 "2024-12-31"까지인 데이터를 하나의 파티션으로 저장하고, 다른 연도의 데이터는 별도의 파티션에 저장하는 것
- 장점:
  - 데이터 검색 속도 향상: 특정 범위에 대해 쿼리할 때 성능이 향상됨. 예를 들어 날짜별 로그 데이터를 자주 조회한다면, 날짜별로 분리하여 조회 성능을 크게 개선할 수 있음.
  - 직관적인 관리: 파티션 구간이 명확하여 관리가 쉬움. 특정 범위의 데이터가 증가하거나 줄어드는 패턴을 쉽게 파악 가능.
- 단점:
  - 데이터 불균형 가능성: 데이터 분포가 고르지 않을 경우 특정 파티션에 데이터가 집중되어 파티션 간의 부하가 균형을 이루지 못할 수 있음.
  - 파티션 관리: 새로운 구간의 데이터가 들어올 경우 파티션을 수동으로 추가해야 하며, 관리가 번거로울 수 있음.
해시 단위 (Hash)
- 해시 함수를 사용해 고르게 데이터를 분산하는 방식
- 예를 들어, 고객 ID의 해시 값을 기준으로 데이터를 나누어, 특정 파티션에 데이터가 몰리지 않도록 합니다.
- 장점:
  - 균일한 분포: 데이터를 해시를 통해 분산하므로 파티션 간 데이터 분포가 균일하여 특정 파티션에 데이터가 몰리는 현상을 방지할 수 있음.
  - 확장성: 대규모 데이터를 다룰 때 파티션이 균등하게 분산되므로 확장성이 좋음.
- 단점:
  - 범위 조회 어려움: 범위를 기준으로 데이터를 조회하는 경우 비효율적임. 데이터를 특정 범위로 쿼리할 때 여러 파티션에 분산되어 있어 조회 비용이 커질 수 있음.
  - 관리의 어려움: 해시 분포가 변하면 모든 데이터를 재분산해야 하므로 파티션 키 변경이나 확장이 어려움.
리스트 단위 (List)
- 특정 값 리스트에 따라 데이터를 분리합니다. 예를 들어, ‘서울’, ‘부산’, ‘인천’ 등과 같이 특정 도시에 따라 데이터를 나누는 것이 가능합니다.
- 장점:
  - 명확한 파티션 전략: 특정 값에 따라 파티션을 지정할 수 있어 직관적이고 명확하게 분류 가능. 예를 들어 국가 코드나 카테고리별로 데이터를 구분할 때 유리함.
  - 필터링 성능 향상: 각 파티션에 대해 명확히 정의된 값을 사용하여 필터링할 경우 성능이 향상됨.
- 단점:
  - 리스트 변경의 복잡성: 새로운 값이 추가되거나 삭제되는 경우 파티션 전략을 재정의해야 하며, 관리가 복잡해질 수 있음.
  - 데이터 불균형 가능성: 특정 리스트 값에 데이터가 집중될 경우 특정 파티션에 데이터가 몰리게 되어 성능 문제가 발생할 수 있음.

하나의 파티션은 데이터를 저장하는 파일로 존재하거나,

데이터 블록이나 데이터 페이지 등과 같은 하위 단위로 구성될 수 있습니다.

논리적으로는 하나의 테이블의 일부로서 취급되지만,

물리적으로는 분리된 공간에 저장되어, 필요한 데이터에만 빠르게 접근할 수 있게 해준다

데이터베이스 인덱스

worldint — Sat, 26 Oct 2024 16:09:51 +0900

데이터베이스 인덱스란?

데이터베이스 인덱스는 책의 목차와 비슷한 역할이다

데이터베이스에서 원하는 데이터를 더 빠르게 찾을 수 있도록 도와주는 도구

인덱스를 사용하면 검색 속도를 크게 향상시킬 수 있으며, 이는 특히 대량의 데이터를 다룰 때 중요함

왜 인덱스를 사용하는가?

만약 인덱스가 없다면, 특정 레코드를 찾기 위해 모든 레코드를 하나씩 확인해야 함

하지만 인덱스를 사용하면 특정 컬럼의 값을 기준으로 데이터를 빠르게 찾아낼 수 있다

사전에서 특정 단어를 찾을 때,

앞에서 부터 한장씩 넘기는것이 아닌
'사과' 면 'ㅅ' 부분으로 바로 넘어가서 찾는것과 비슷한 이치

인덱스의 종류

B-Tree 인덱스: 가장 일반적으로 사용되는 인덱스 타입
데이터를 트리 구조로 관리하여 빠르게 검색, 삽입, 삭제가 가능하다 대부분의 관계형 데이터베이스에서 기본 인덱스 타입으로 사용됨
- B-Tree는 트리 구조로 데이터를 저장하여 검색 속도를 빠르게 함
- 책의 목차처럼 분기점을 따라가며 원하는 데이터를 효율적으로 찾을 수 있다
해시 인덱스: 해시 함수로 데이터를 빠르게 찾을 수 있도록 한다 특정 키에 대해 빠른 조회가 가능하지만 범위 검색은 지원하지 않음
- 해시 인덱스는 데이터를 특정 키에 대해 해시 값으로 매핑하여 빠르게 접근할 수 있게 한다
- 이는 특정 값을 정확히 찾는 데 유리하지만, 범위 검색에는 적합하지 않음
텍스트 인덱스: 대량의 텍스트 데이터를 검색할 때 유용
예를 들어 블로그나 뉴스 기사에서 특정 키워드를 검색할 때 사용됨
- 텍스트 인덱스는 텍스트 데이터의 빠른 검색을 위해 최적화되어 있다
- 블로그나 뉴스 사이트와 같은 대량의 텍스트 기반 콘텐츠에서 특정 키워드를 쉽게 찾을 수 있게 해줌

인덱스의 단점

인덱스는 데이터를 빠르게 찾을 수 있도록 도와주지만,
인덱스를 추가하면 데이터 삽입, 수정, 삭제 작업의 성능이 저하될 수 있댜
인덱스를 유지하기 위해 데이터가 변경될 때마다 추가적인 작업이 필요하기 때문에
모든 컬럼에 인덱스를 만드는 것은 오히려 역효과를 낳는다
자주 사용되는 검색 조건이나 정렬 기준으로 인덱스를 설정하는 것이 좋음