BASE란?

ACID와 대조적으로 가용성과 성능을 중시하는 특성을 가진 분산 시스템의 특성

Basically Available

• 가용성을 중시, Optimistic Locking 및 큐 사용
• 다수의 실패에도 가용성을 보장, 다수의 스토리지에 복사본 저장
• 기본적으로 Available 하다

Soft-state

• 사용자가 관리(refresh, modify) 하지 않으면 데이터가 expire 될 수도 있다.
• 노드의 상태는 외부에서 전송된 정보를 통해 결정됨
• 분산 노드 간 업데이트는 데이터가 노드에 도달한 시점에 갱신

Eventually consistency

• 지금 당장은 아니더라도 언젠가는 데이터가 일관성을 가진다.

 

BASE라는 단어는 억지로 만들어낸 느낌이 있는데, 그것은 ACID가 산성을 나타내기 때문에 반대의 개념으로 염기를 나타내는 BASE에 빗대어 표현하기 위함!

 

 

---

낙관적 락(optimistic lock)

낙관적 락은 DB 충돌 상황을 개선할 수 있는 방법 중 2번째인 수정할 때 내가 먼저 이 값을 수정했다고 명시하여 다른 사람이 동일한 조건으로 값을 수정할 수 없게 하는 것입니다. 그런데 잘 보면 이 특징은 DB에서 제공해주는 특징을 이용하는 것이 아닌 Application Level에서 잡아주는 Lock입니다. 어떤 것인지 도식도로 한번 보도록 하겠습니다.

도식도를 글로 나타내면 아래와 같습니다.

1. A가 table의 Id 2번을 읽음 ( name = Karol, version = 1 )
2. B가 table의 Id 2번을 읽음 ( name = Karol, version = 1 )
3. B가 table의 Id 2번, version 1인 row의 값 갱신 ( name = Karol2, version = 2 ) 성공
4. A가 table의 Id 2번, version 1인 row의 값 갱신 ( name = Karol1, version = 2 ) 실패
   • Id 2번은 이미 version이 2로 업데이트 되었기 때문에 A는 해당 row를 갱신하지 못함

위 flow를 통해서 같은 row에 대해서 각기 다른 2개의 수정 요청이 있었지만 1개가 업데이트 됨에 따라 version이 변경되었기 때문에 뒤의 수정 요청은 반영되지 않게 되었습니다. 이렇게 낙관적락은 version과 같은 별도의 컬럼을 추가하여 충돌적인 업데이트를 막습니다. version 뿐만 아니라 hashcode 또는 timestamp를 이용하기도 합니다.

낙관적 락은 version 등의 구분 컬럼을 이용해서 충돌을 예방합니다.

 

(출처 : https://sabarada.tistory.com/175)