Indexing, ACID properties, Eventual Consistency

Indexing

인덱싱이란 db검색을 좀 더 빠르고 효율적으로 수행하기 위해 정의된 개념이다. 인덱싱을 해서 데이터 대소를 비교해 정렬해두고, 이를 이진탐색을 통해 검색하면 훨씬 빠르게 검색을 수행할 수 있기 때문이다. 실제로 인덱싱을 해두지 않은 db는 검색 시 Full Table Scan을 하게 되는데, 이는 모든 데이터 칼럼을 까서 하나씩 비교해 검색하는 방식으로 매우 비효율적이다.

• 데이터베이스에서 자주 검색하는 컬럼에 선별적으로 인덱스를 붙여줘서 해당 컬럼을 검색하는 속도를 높여 주는 것
• 데이터베이스에서 인덱스 없이 검색하면 Full Table Scan을 하기 때문에 시간&비용 비효율적인데, 인덱싱을 해놓으면 이진탐색이 가능해 더 빠르고 효율적으로 검색이 가능

인덱싱이란?

모든 데이터 타입에는 데이터의 "대소 비교 규칙"이 정해져 있으며 (ex) 문자열은 알파벳 순서로 왼쪽 부터 한글자씩 비교 등등) 이 대소에 따라 문자열을 작은것부터 큰것까지 정렬할 수 있다. 인덱싱이란, 결국 문자열들을 이 대소 규칙에 따라 정렬한 것이다.

EX) 인덱싱 유무에 따른 차이
▶원본 테이블 (인덱싱 안됨)
Row 1: kim@email.com
Row 2: lee@email.com
Row 3: park@email.com
Row 4: aaa@email.com
...
Row 1,000,000: jung@email.com
▶변경 테이블 (인덱싱 됨)
aaa@email.com → Row 4
bbb@email.com → Row 847
ccc@email.com → Row 23
...
jung@email.com → Row 1,000,000
kim@email.com → Row 1
lee@email.com → Row 2
...
zzz@email.com → Row 9876

 

이진탐색이란?

크기에 따라 정렬된 데이터에 대해 절반씩 쪼개가며 데이터를 검색하는것이다.

EX)100만 개 인덱스에서 'jung@email.com' 찾기:
1회차: 가운데(50만번째) 확인 → 'mmm@email.com' → jung보다 뒤쪽이므로 앞쪽 절반만 검색
2회차: 25만번째 확인 → 'fff@email.com' → jung보다 뒤쪽이므로 25만~50만 구간 검색
3회차: 37.5만번째 확인 → 'kkk@email.com' → jung보다 앞쪽이므로 25만~37.5만 구간 검색
...
약 20회차: 찾음!

 

• 즉 테이블 인덱싱을 해두면, 테이블을 정렬 시켜놓은 후 이진탐색을 하기 때문에 빠르고 효율적인 것.
• 100만개의 데이터가 있는 테이블에서 특정 데이터를 조회하는경우,
  인덱스가 없으면 100만번 비교
  인덱스가 있으면 log₂(1,000,000) ≈ 20번 비교
  

---

ACID properties

관계형 데이터베이스 트랜잭션이 안전하게 처리되기 위한 4가지 특성:

• Atomicity (원자성): 트랜잭션의 모든 작업이 성공하거나 모두 실패해야 함
• Consistency (일관성): 트랜잭션 전후로 데이터베이스가 일관된 상태를 유지해야 함
• Isolation (격리성): 동시에 실행되는 트랜잭션들이 서로 간섭하지 않아야 함
• Durability (지속성): 완료된 트랜잭션의 결과는 영구적으로 저장되어야 함

트랙잭션이란 하나의 작업을 위해 묶인 여러개의 데이터베이스연산이다. 계좌이체라는 작업을 하기 위해선 a계좌에서 1만원을 빼서 b계좌에 1만원을 추가해야하는데, 이 2가지 연산이 하나의 작업으로 묶이게되며, 이를 "계좌이체"라는 트랜잭션으로 정의한다.

BEGIN TRANSACTION;
UPDATE accounts SET balance = balance - 10000 WHERE account_id = 'A';  -- A계좌에서 1만원 차감
UPDATE accounts SET balance = balance + 10000 WHERE account_id = 'B';  -- B계좌에 1만원 추가
COMMIT;

 

그럼 왜 이 트랜잭션이 안전하게 처리되기 위한 별도의 특성을 정의해야했던 걸까?

 

아래와 같은 예외 상황이 존재하기 때문이다.

 

1) 중간에 시스템이 죽는경우

a계좌에서 1만원을 차감했는데 시스템이 죽어서 b계좌로 돈을 못 넣게됨. 이 경우 1만원이 사라진 격.

 

2) 동시에 여러 사용자가 같은 계좌에 접근하는 경우

사용자 1,2가 a계좌 잔액(5만원)을 동시에 확인하고 각각 3만원씩 동시에 출금을 시도한 경우, 잔액은 5만원인데 6만원을 출금시도한 격.

 

ACID는 이런 문제들을 해결하기 위해 정의되었다.

---

Eventual Consistency

• 분산 시스템에서 사용되는 일관성 모델로, 모든 업데이트가 즉시 모든 노드에 반영되지는 않지만, 시간이 지나면 결국 모든 노드가 같은 데이터를 갖게 된다는 개념
• NoSQL 데이터베이스에서 주로 사용되며, 강한 일관성을 포기하는 대신 가용성과 성능을 높임
• 예를 들어 소셜미디어에서 '좋아요' 수가 잠시 다르게 보이다가 나중에 맞춰지는 것과 같음

분산시스템

여러 컴퓨터(서버)가 네트워크로 연결되어 하나의 시스템처럼 동작하는것을 '분산 시스템' 이라고 정의한다. (ex) 구글 검색이 전세계 수천대의 서버에서 동시에 처리)

 

단일서버로 데이터를 처리할 경우 처리량의 한계도 있고, 이 서버하나가 죽으면 서비스 전체가 중단될수도 있고, 또 지리적 위치에 따라 단일서버로 부터 멀리 있는 사용자는 속도가 느려질 수 있기 때문에 위와 같은 분산시스템의 개념이 만들어 진것이다.

 

노드

분산시스템을 구성하는 각각의 컴퓨터(서버)를 '노드'라고 부른다.

노드1 (서울)        노드2 (도쿄)            노드3 (싱가포르) [데이터베이스]    [데이터베이스]          [데이터베이스]      ↕                             ↕                                    ↕      네        트       워      크        로      연          결       됨

 

일관성 모델

분산된 여러 노드간에 데이터가 얼마나 동일해야하는지에 대한 규칙이 '일관성 모델'이다.

 

일관성 모델은 강한 일관성 (Strong Consistency)과 최종 일관성 (Eventual Consistency)으로 또 나뉘는데,

• 강한 일관성 (Strong Consistency) : 사용자가 게시글을 올리면 모든 노드가 동시에 업데이트될 때까지 대기했다가 업데이트 완료 후에야 "업로드 완료" 응답것을 의미하며,
• 최종 일관성 (Eventual Consistency) : 사용자가 게시글을 올리면 일단 "업로드 완료" 응답을 하고, 백그라운드에서 다른 노드들에 천천히 전파해서 시간이 지나면 모든 노드가 동일해지는 것이다.

강한 일관성은 모든 사용자가 항상 같은 데이터 보이지만 느리고 네트워크 문제 시 서비스가 중단될 수도 있다는 단점이 있고, 최종 일관성은 잠시 동안 사용자마다 다른 데이터를 볼수도 있지만, 빠르고 일부 노드에서 장애가 발생해도 다른 노드들이 있기 때문에 서비스는 계속될 수 있다는 장점이 있다. 

 

최종 일관성을 예를들어 보자면 인스타그램에서 내가 좋아요를 누르면, 도쿄의 사용자에게 바로 좋아요가 안보이고 몇초 ~ 몇분 후 보이는 것과 같다. 

 

대부분의 분산시스템에선 이 최종 일관성을 채택하여 서비스하는데, 비록 일관성은 조금 떨어지지만 성능이 보장되도록 하는 트레이드오프를 선택한 것이라고 볼 수 있다.

 

만약 인스타그램에서 모두가 동시에 똑같은걸 보려면 좋아요 버튼을 누르고 모두 10초 씩 기다려야할 수도 있기 때문..