0222 TIL 🧋

looggi·2023년 2월 22일

데이터베이스 락과 데드락 뷰 코테 클러스터

TILs

목록 보기

3/114

데이터베이스

SQL과 NoSQL의 차이를 말해보세요
SQL은 관계형데이터베이스 모델로 데이터를 행과 열에 저장해서 관리하며 고정된 스키마가 존재합니다. 정규화를 통해 중복없이 테이블을 분리해서 관리하며 보통 SCALE-UP 방식으로 확장을 하여 비용이 많이 소모됩니다.
NoSQL은 비구조적 데이터를 저장하는데 사용하는 데이터베이스 모델입니다. 고정된 스키마가 없어 유연하게 데이터를 관리할 수 있으며 scale-out방식으로 확장을 하여 SQL에 비해서 비용이 적게 들고 대용량 트래픽을 처리하기 좋아 많이 사용되고 있습니다.
SQL과 NoSQL은 데이터베이스를 관리하는 방식에 차이가 있습니다.
SQL은 관계형데이터베이스 모델로 데이터를 행과 열에 저장하며 정규화를 통해 중복없이 테이블을 분리하여 SQL을 통해 테이블 간의 관계를 바탕으로 필요한 데이터를 뽑아서 쓸 수 있습니다.
NoSQL은 비관계형데이터베이스를 관리하는 방식으로 특별한 구조가 없는 데이터를 저장하는 방식입니다. 고정된 스키마가 없어 유연하게 사용할 수 있으며 SQL과 달리 scale-out방식으로 확장을 할 수 있어 비교적 저렴하며 분산 시스템 구축으로 대용량 트래픽을 보다 효율적으로 처리할 수 있습니다.

DB

DBMS
데이터를 저장하고 관리하는 방식

RDBMS SQL사용
- MySQL
  Oracle
  SQLite
  MariaDB
  PostgresSQL

SQL

Structured Query Language
관계형 모델은 중복성을 줄이도록 정규화되고 일반적으로 저장에 최적화된 데이터베이스에서 데이터베이스가 테이블 사이에서 참조 무결성을 실현할 수 있도록 고안

SQL을 사용하려면, 고정된 형식의 스키마가 필요하다
데이터를 행과 열로 구성된 테이블에 저장
수직적 확장(Scale-up)
ACID속성 제공
- 원자성: 가는 완벽하게 실행하거나 혹은 전혀 실행하지 않는 트랜잭션을 필요로 합니다.
- 일관성: 트랜잭션이 커밋되면 데이터가 데이터베이스 스키마를 준수하도록 요구합니다.
- 격리성: 동시에 일어나는 트랜잭션들이 각기 별도로 실행되어야 함을 의미합니다.
- 내구성: 예기치 못한 시스템 장애 또는 정전 시 마지막으로 알려진 상태로 복구하는 기능을 필요로 합니다.

NoSQL

Not Only SQL/ non SQL
비관계형 데이터베이스
관계형 데이터 또는 정형데이터가 아닌 데이터, 즉 비정형데이터라는 것을 보다 쉽게 담아서 저장하고 처리할 수 있는 구조를 가진 데이터 베이스

뛰어난 확장성(수평적 확장 scale-out)
유연한 스키마 (융통성 있는 데이터 모델 사용)
→ 빠르게 개발가능
특정 목적/기능에 특화됨
- 초고용량 데이터 처리 등 성능에 특화된 목적을 위해, 비관계형 데이터 저장소에, 비구조적인 데이터를 저장하기 위한 분산 저장 시스템
- 데이터의 저장 및 검색/단순 검색 및 추가 작업을 위한 특화(최적화)된 매커니즘(키 값 저장 기법)을 제공 →레이턴시(응답속도)나, 스루풋(처리 효율)등이 뛰어남
  - 레이턴시: 자극과 반응에 대한 지연시간
  - 스루풋: 단위 시간당 디지털 데이터 전송으로 처리하는 양
- ex. Facebook, Twitter, Netflix, Instagram, Apple의 iCloud, 삼성의 SCloud

RDBMS와 차이점

관계형 모델을 사용하지 않으며 테이블간의 조인 기능 없음
직접 프로그래밍을 하는 등의 비SQL 인터페이스를 통한 데이터 액세스
대부분 여러 대의 데이터베이스 서버를 묶어서(클러스터링) 하나의 데이터베이스를 구성
분산형 하드웨어 클러스터를 이용해 확장
관계형 데이터베이스에서는 지원하는 Data처리 완결성(Transaction ACID 지원) 미보장
데이터의 스키마와 속성들을 다양하게 수용 및 동적 정의 (Schema-less)
데이터베이스의 중단 없는 서비스와 자동 복구 기능지원
다수가 Open Source로 제공
확장성, 가용성, 높은 성능

Data Model

저장되는 데이터의 구조에 따른 분류

Key Value DB ex.다이나모DB
Wide Columnar Store ex.HBase, Cassandra
Document DB ex.MongoDB
Graph DB

기타

ScyllaDB
Event 기반 Processing 구조로 고성능 처리
CPU Core별 단일 thread기반 processing
-> 어디서 했지??
오픈소스 DBMS인 PostgreSQL의 경우도 2년전부터 NoSQL에서나 처리 가능했던 JSON을 지원함으로서, 시장의 주목을 많이 받았고, 더불어 다른 오픈소스 데이터베이스 업체들도 JSON을 지원하게 되었습니다.

https://www.samsungsds.com/kr/insights/1232564_4627.html
https://aws.amazon.com/ko/nosql/
https://hanamon.kr/%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4-sql-vs-nosql/

클러스터, 넌클러스터란
DB 인덱스에서 사용하는 용어로 넌클러스터 인덱스는 보통 생성하는 인덱스의 생성 방식과 동일하다. 원본 데이터와 별개로 인덱스 페이지가 따로 생성되어 추가 저장 공간이 필요하다. 데이터가 자주 업데이트 되는 경우 넌클러스터를 사용하는 것이 더 좋다.
클러스터 인덱스는 인덱스 페이지를 따로 만들지 않고 항상 정렬된 상태를 유지한다. 검색 속도가 빠르지만 데이터가 업데이트 되는 경우엔 페이지 분할이 일어날 수 있어 넌클러스터보다 속도가 느리다. 따라서 업데이트가 자주 일어나지 않는 대용량 데이터에 사용하는 것이 적합하다.

클러스터 인덱스

인덱스는 검색속도를 향상시키기 위해 있는 것!

따로 클러스터드 인덱스를 지정하지 않으면 기본키 == 클러스터드 인덱스
테이블당 하나
트리 형태로 저장
- 루트 페이지(노드)
  리프 페이지의 주소를 저장
- 리프 페이지(노드)
  실제 데이터 페이지
인덱스 페이지가 따로 없고 항상 정렬된 상태를 유지
- 검색(SELECT)속도가 넌클러스터보다 더 빠름(참조하는 페이지의 수가 적기때문)
  입력/수정/삭제는 더 느림
- 페이지 분할
  리프 페이지에 새로운 데이터가 추가할 공간이 없을 때 데이터를 추가하는 방법
  → 인덱스는 Balancing Tree구조이기 때문에 기본적으로 모두 같은 크기의 페이지를 유지한다. 그래서 새로운 데이터가 중간에 삽입되야하는 경우 새로운 데이터가 추가 될 테이블의 기존 데이터 절반이 새로운 페이지로 이동 후 새로운 데이터가 추가된다.
  이와 같이, 인덱스를 생성/수정/삭제할 때 페이지 분할이 일어날 수 있어 이런 경우 데이터 페이지 전체를 재정렬해야 하기 때문에 느려진다.

넌클러스터 인덱스

데이터 페이지를 건드리지 않고(정렬x), 별도의 장소에 인덱스 페이지를 생성 → 용량을 더 차지한다.

여러 개 생성 가능
인덱스 페이지 (루트노드 → 리프노드(인덱스가 먼저!)) → 데이터 페이지
→ 인덱스 페이지를 한번 거치기때문에 검색 속도는 더 느리지만 데이터의 입력, 수정, 삭제는 더 빠르다
인덱스 조회 시 비용이 많이 발생한다
→ 검색하고자하는 데이터의 키 값을 루트 페이지에서 비교하여 리프 페이지 번호를 찾고, 리프 페이지에서 RID 정보로 실제 데이터의 위치로 이동

https://kosaf04pyh.tistory.com/293
velog.io/@sweet_sumin

뷰

데이터베이스 뷰란
전체 테이블의 (필요한)일부만을 이용해서 만든 가상 테이블로 기본 테이블을 이용해서 다양한 니즈를 충족시킬 수 있다. 뷰를 이용해서 연산이 가능하며 공개하지 않는 자료에 대해서는 보안 기능도 제공하는 셈이다.

사용자에게 접근이 허용된 자료만을 제한적으로 보여주기 위해 하나 이상의 기본 테이블로부터 유도된, 이름을 가지는 가상 테이블

물리적으로는 존재하지 않는다
자료에 대한 권한을 설정함으로써 보안+1
동일 데이터에 대해 동시에 여러사용자의 상이한 응용이나 요구를 지원

기본 테이블의 기본키를 포함한 속성(열) 집합으로 뷰를 구성해야 연산이 가능하다

논리적 데이터 독립성을 제공
독립적으로 인덱스를 가지는 것은 불가능

뷰의 정의를 변경하는 것(ALTER VIEW)은 불가능

CREATE VIEW ↔ DROP VIEW RESTRICT/CASCADE
뷰로 새로운 뷰를 만드는 것은 가능하다

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

락과 데드락 OS

동기화 문제

레이스 컨디션
두개 이상의 프로세스/스레드가 공유자원을 서로 사용하려고 하는 현상 → 뮤텍스/세마포어
데드락
멀티 스레드일 때(자원을 공유하는 상황) 서로 상대방이 가진 자원을 기다리느라 일을 하지 못하는 상황
아래 4가지 조건을 모두 만족하는 경우 발생
- 상호배제: 동시에 한 자원에 접근하는 것을 허용하지 않음 → 점유자원을 계속해서 사용하게 되는 경우 무한 대기를 일으킬 수 있음
- 점유상태로 대기: 락을 획득하여 점유하고 있는 상태에서 다른 자원의 락을 획득하기 위해 기다리는 상태 → 무한 대기 발생 가능
- 선점 불가(비선점): 다른 프로세스/스레드가 자원을 선점하고 있어 자원을 사용할 수 없음 → 무한 대기 발생 가능
- 점유상태대기가 순환적으로 발생한 경우 → 무한 대기 발생 가능
라이브락
데드락을 피하기 위해 락을 획득하지 못한 경우 대기상태로 빠지지 않도록 하고 획득한 락을 해지해서 다른 프로세스/스레드가 락을 획득할 수 있도록 함
락을 획득하고 해제하는 과정이 계속 반복됨

https://cheetile.tistory.com/entry/OS-Race-Condition-Deadlock-Starvation-Livelock

락과 데드락 DB

데드락

데이터베이스의 관점에서 트랜잭션간 발생하는 것
두개의 트랜잭션이 각각의 트랜잭션이 가진 리소스의 락을 획득하려고 할 때 발생함

락

데이터의 무결성을 보장하는 방법 중 한가지
데이터베이스락은 둘 이상의 사용자가 같은 시간에 같은 데이터를 업데이트하는 것을 방지한다.
락이 걸린 데이터는 해제될 때까지 다른 사용자가 조작할 수 없고 COMMIT 이나 ROLLBACK구문 실행 후 해제된다.
*blocking: 락끼리 경합이 발생한 경우(레이스 컨디션?) 프로세스의 작업이 진행되지 않고 멈춘 상태
→ commit/ rollback으로 해결
- 공유락(Read Lock)
  데이터를 읽을 때 사용 select
  다른 프로세서가 볼 수 있지만 변경은 불가능
- 배타적락(Write Lock)
  데이터를 변경할 때 사용 insert, update, delete
  해제되기 전에는 다른 프로세서가 아무것도 할 수 없다
- 내재락(Intent Lock) - IS, IX, SIX
  사용자가 요청한 범위에 락을 할 수 있는지 파악
  row / page / table(index포함) / database(DB복구시)
  *lock escalation: 락이 많아질수록 메모리 효율이 떨어지기때문에 하위락의 비율이 일정 크기를 넘어서면 상위락을 생성함
  → level이 낮을 수록 동시성이 좋지만 메모리 효율은 낮아진다

https://velog.io/@koo8624/Database

0220 TIL 락과 데드락 DB관점에서
0220 TIL 락과 데드락 OS관점에서

프로그래머스 문제풀기

➡️폰켓몬

def solution(nums):
    return min(len(nums)/2,len(set(nums)))

둘중 작은 게 답이 될 땐 if 부등호 쓰지말고 간단하게 min을 쓰자..
아님 else까지 갈 것도 없이 그냥 이런 것도..?

def solution(nums):
    if len(list(set(nums))) < len(nums)/2:
        return len(list(set(nums)))
    return len(nums)/2

looggi

looooggi

이전 포스트

0223 TIL

다음 포스트