💻

보호되어 있는 글입니다.

Redis 동시성 처리동시성 이슈데이터 불일치여러 스레드가 동시에 동일한 데이터를 수정데드락 (Deadlock)두 개 이상의 스레드가 서로의 자원을 기다리다가 멈추는 상태라이브락 (Livelock)스레드가 락을 반복적으로 획득하려다 아무런 진전이 없는 상태경쟁 조건동시에 자원에 접근하여 예상하지 못한 결과가 발생하는 상태=> 동시성 제어(: 멀티스레드 환경에서 일관된 데이터 처리를 보장하는 방법) 필요동시성 제어 기법락(Lock)한 스레드가 자원을 사용하는 동안 다른 스레드가 해당 자원에 접근하지 못하도록 막는 기법Mutex (Mutual Exclusion): 가장 기본적인 락/ 하나의 스레드만 자원에 접근할 수 있도록 보장Reentrant Lock: 동일한 스레드가 여러 번 락을 획득할 수 있는 락세마..

Memcached(멤캐시드)사용이 간편한 고성능 인 메모리 데이터 스토어 장점1밀리 초 미만의 응답 시간서버의 주 메모리에 모든 데이터를 유지PostgreSQL, Cassandra 및 MongoDB와 같은 데이터베이스: 데이터 대부분을 디스크 또는 SSD에 저장인 메모리 데이터 스토어: 반복해서 디스크를 왕복할 필요 X → 더 ↑ 작업 처리 + 더 빠른 응답 지원단순성 및 사용 편의성간단하고 일반적이 되도록 설계되었으므로 애플리케이션 개발에 사용하기에 쉬우면서 강력다수의 오픈 소스 클라이언트를 사용지원되는 언어: Java, Python, PHP, C, C++, C#, JavaScript, Node.js, Ruby, Go 등확장성분산 및 다중 스레드 아키텍처를 사용하면 손쉽게 확장여러 노드 간에 데이터를 ..

두 번의 갱신 분실 문제(Second lost updates problem)두 트랜잭션에서 데이터 변경 → 최종적으로 한 트랜잭션의 결과만 남는 것⇒ 해결: 마지막 커밋만 인정 / 최초의 커밋만 인정 / 충돌하는 갱신 내용 병합⇒ JPA에서는 비관적 락/낙관적 락 매커니즘 제공Pessimistic트랜잭션의 충돌이 발생한다고 가정트랜잭션이 시작될 때 데이터베이스에 락 → 다른 트랜잭션 접근 XShared Lock(공유 락, S Lock)특정 Row 읽을(Read) 때 사용여러 트랜잭션이 동시에 한 Row에 S Lock 걸 수 있음하나의 Row를 여러 트랜잭션이 동시에 읽을 수 있음S Lock이 설정된 Row에는 X Lock 사용 XInnoDB에서 일반적인 `SELECT` 쿼리는 Lock 사용 XBut, `..

트리거트리거를 건다어떤 트랜잭션 일어날 때 반응 → 다른 명령 실행하게 하는 것테이블에 대한 이벤트(INSERT, UPDATE, DELETE)에 반응 → 자동으로 실행DDL, DML, 일부 DB 작업⇒ 데이터 무결성, 특정 작업 자동화ex. 결제 삽입, 업데이트 → 실시간 결제상태/이력 테이블 업데이트프로시저프로시저를 실행한다일련의 쿼리 작업 → 하나의 함수처럼 실행하기 위한 쿼리 집합미리 SQL문 작성, 필요할 때마다 호출읽기 성능 최적화, data 조회ex. 결제 프로시저 정의(결제 승인 → 기록 삽입 → 잔고 갱신 → 알림 전송)⇒ 트랜잭션 실패 → 롤백 ⇒ 데이터무결성

1. MySQL 서버의 데이터 암호화5.7 버전부터: 데이터 암호화 기능 지원, 처음에는 데이터 파일(테이블스페이스)에 대해서만 암호화 기능 제공8.0 버전 이후: 데이터 파일, 리두 로그, 언두 로그, 복제를 위한 바이너리 로그 등 모두 암호화 기능 제공 데이터베이스 서버와 디스크 사이의 데이터를 읽고 쓰는 지점에서 암호화/복호화-> 디스크 입출력 ㅣㅇ외의 부분에서는 압호화 처리 필요 X== MySQL 서버(InnoDB 스토리지 엔진)의 I/O 레이어에서만 데이터 암호화/복호화 과정 실행사용자의 쿼리를 처리하는 과정에서 테이블의 데이터가 암호화돼 있는지 여부 식별할 필요 X암호화 O 테이블, 암호화 X 테이블 => 동일한 처리 과정: 데이터 암호화 기능이 활성화 O -> MySQL 내부와 사용자 입장에..