DEV/Backend

· DEV/Backend
Secondary Index (보조 인덱스) 데이터베이스에서 보조 인덱스를 사용하는 주요 목적은 데이터 액세스 성능을 향상시키는 것입니다. 보조 인덱스는 테이블의 기본 키가 아닌 열에 구축되는 인덱스입니다. 기본 인덱스는 테이블의 기본 키를 기반으로 하고 데이터에 대한 링크를 제공하지만, 보조 인덱스는 다른 열에 구축 되어, 해당 열을 기반으로 데이터에 더 빠르게 액세스 할 수 있습니다 특징 장점 데이터 검색 속도 향상: 보조 인덱스는 특정 열을 기반으로 데이터를 정렬하여 검색 속도를 높여줍니다. 쿼리 성능 향상: 보조 인덱스를 생성함으로써 WHERE 절이나 JOIN 조건에서 자주 사용되는 열에 대한 쿼리의 성능을 향상시킬 수 있습니다. 단점 저장 공간: 생성하는 각 인덱스에는 추가 저장 공간이 필요합니..
· DEV/Backend
SA : 보안 연관 묶기 SA(보안 연관)이란 그 위에 실어 보내는 트래픽에 보안 서비스를제공하는 송신자와 수신자 사이의 일방향 관계를 의미한다 양방향 보안 교신을 위한 대등 관계가 필요하면 2 개의 보안 연관을 사용한다 AH나 ESP를 사용(2개 동시 사용은 안됨)하기 위해 SA에 보안 서비스를 제공하기도 한다 동일한 트래픽 흐름에 대해 원하는 IPsec 서비스를 제공하기 위해 여러 SA를 결합할 수 있습니다. 연관 묶음 내 SA 종료는 양쪽 단말에서 수행 할 수 있습니다 연결 바인딩 방법 바인딩 방법은 이러한 SA가 보안 서비스를 제공하기 위해 결합되고 구성되는 방법을 나타냅니다. 전송 인접성 및 반복 터널링의 두 가지 주요 방법이 있습니다. 중첩 전송 터널링을 사용하지 않고 동일한 IP 패킷에 둘 ..
· DEV/Backend
캡슐화 보안 페이로드(ESP) 캡슐화 보안 페이로드는 비밀성, 데이터 출처 인증., 비연결형 무결성, 재전송 방지 서비스, 트래픽 흐름의 비밀성을 제공하기 위해 사용된다. 제공되는 서비스의 집합은 SA 설정 시점에 선택된 옵션과 네트워크 위상에서 구현 위치에 따라 의존적이다 ESP는 GCM과 같은 인증 되는 암호화 알고리즘을 포함하여 다양한 암호화와 인증 알고리즘으로 동작한다 ESP 형식 ESP 패킷 최상위 형식 페이로드 데이터 서브 구조 암호화 및 인증 알고리즘 페이로드 데이터 그리고, 패딩 패드 길이, 다음 헤더 필드는 ESP 서비스에 의해 암호화 된다. 암호화 알고리즘이 초기화 벡터(IV)를 필요로 하면 데이터는 페이로드 데이터 필드의 시작 부분에 명시해서 전달된다. IV를 포함하면 암호문의 일부로..
· DEV/Backend
Write Lock과 Read Lock 결국은 공유 자원에 대해서, 데이터를 읽고 쓸 때 트랜잭션(Transaction) 등에 락은 필연적입니다 또한, 공유 자원의 데이터 정합성을 지키기 위해서는 위와 같이 락으로 공유 자원에 순차적인 데이터 접근을 구현합니다 하지만, 잘못된 락은 시스템 성능을 저하시키니 조심해야 합니다다 개발자 입장에서 락을 통해 동시성을 제어할 때는 락의 범위를 최소하는 것이 중요합니다 Write Lock(배타 잠금) 쓰기 잠금은 잠금을 보유한 트랜잭션이 잠긴 데이터를 읽고 쓸 수 있도록 하는 일종의 잠금입니다. 쓰기 잠금이 유지되는 동안 다른 트랜잭션은 잠긴 데이터를 읽거나 쓸 수 없습니다. 이렇게 하면 데이터 일관성이 보장되지만 잠금 범위가 크면 대기 시간이 길어질 수 있습니다...
· DEV/Backend
낙관적 Lock과 비관적 Lock 낙관적 잠금 낙관적 잠금은 충돌이 드물고 전체 트랜잭션 중에 리소스를 잠글 필요가 없다고 가정하는 전략입니다. 대신 트랜잭션이 커밋될 때 충돌을 확인합니다. 충돌이 감지되면(예: 다른 트랜잭션이 데이터를 수정함) 트랜잭션이 롤백되고 오류가 반환됩니다. 낙관적 잠금은 버전 번호를 사용하여 구현됩니다. 트랜잭션이 커밋되면 시스템은 데이터베이스의 현재 버전 번호가 읽은 버전 번호와 일치하는지 확인합니다. 일치하면 트랜잭션이 커밋되고 버전 번호가 증가합니다. 일치하지 않으면 충돌이 발생하고 트랜잭션이 롤백됩니다. 다음은 낙관적 잠금을 사용하는 방법의 예입니다. START TRANSACTION; SELECT version_number FROM table_name WHERE con..
· DEV/Backend
동시성 제어 데이터베이스의 동시성 제어를 통해 여러 트랜잭션(Transaction)이 서로 간섭하지 않고 동시에 발생할 수 있습니다. 동시 실행에도 불구하고 트랜잭션의 일관성, 격리 및 내구성을 보장하게 하는 것이죠! 데이터베이스의 동시성 문제에 대한 일반적인 패턴 공유 리소스 조회 여러 트랜잭션이 공유 리소스를 읽고 있을 때 하나의 트랜잭션이 리소스를 수정하는 경우 제대로 관리하지 않으면 불일치가 발생할 수 있습니다. 공유 리소스 업데이트 여러 트랜잭션이 공유 리소스를 동시에 업데이트하려고 하면 충돌이 발생할 수 있습니다. 이를 종종 쓰기-쓰기 충돌이라고 합니다. 교착 상태 교착 상태는 두 개 이상의 트랜잭션이 서로 리소스를 해제하기를 무한정 기다릴 때 발생합니다. 이는 관리해야 하는 동시성 제어의 일..
· DEV/Backend
트랜잭션 격리레벨 트랜잭션(Transaction) 격리 수준은 한 트랜잭션에서 변경한 내용을 다른 트랜잭션에 표시하는 방법과 시기를 결정합니다. SQL에는 네 가지 트랜잭션 격리 수준이 있습니다. READ UNCOMMITTED 가장 낮은 격리 수준입니다. 이 수준에서 트랜잭션은 아직 커밋되지 않은 다른 트랜잭션에서 쓰고 있는 데이터를 읽을 수 있습니다( 이로 인해 불일치가 발생할 수 있습니다. READ COMMITTED 이것은 많은 데이터베이스 시스템의 기본 수준입니다. 이 수준을 사용하는 트랜잭션은 트랜잭션이 시작되기 전에 커밋된 데이터만 볼 수 있습니다. 이는 더티 읽기를 방지하지만 여전히 반복 불가능한 읽기 및 팬텀 읽기로 이어질 수 있습니다. REPEATABLE READ 이 수준은 읽은 데이터가 ..
· DEV/Backend
트랜잭션 트랜잭션은 하나 이상의 SQL 문을 포함하는 단일 논리적 작업 단위입니다. 트랜잭션은 데이터베이스 시스템에서 데이터 무결성과 일관성을 보장하는 데 사용됩니다. 동일한 데이터에 대한 여러 작업이 동시에 발생할 수 있는 다중 사용자 및 동시 데이터베이스 환경에서 매우 중요합니다. 예시로 아래의 SQL 문이 작동하는 것을 봅시다 홍길동이 김국밥에게 잔액을 +900을 줬지만 3번에서 실패가 발생했습니다 이 경우, 데이터의 정합성이 깨집니다. 위의 그림처럼, 홍길동은 900이 그대로 남았지만, 김국밥은 잔액이 900원이 더 생긴 상태로 쿼리가 종료 되었습니다 눈 먼 돈이 생겨버렸죠 이러한 문제 때문에 여러 SQL문을 마치 하나의 오퍼레이션으로 묶어야 하는 필요가 생겼습니다 ACID ACID로 참조되는 네..
· DEV/Backend
Fan Out On Read (Pull Model) 웹 서비스를 예시로 들며 Fan Out On Read 모델에 대해 알아봅시다 푸시 모델이라고도 하는 Fan Out On Read는 게시물 작성 시 팔로워의 타임라인에 게시물을 즉시 전달하여 실시간 업데이트를 보장하기 위해 소셜 미디어 시스템에서 사용되는 전략입니다. 이 접근 방식은 즉각적인 데이터 일관성을 우선시하여 팔로워가 지체 없이 최신 게시물을 받을 수 있도록 합니다. Fan Out On Read에는 몇가지 특징이 있습니다 즉시 전달 Fan Out On Read를 사용하면 게시물이 생성되는 즉시 팔로워의 타임라인에 즉시 전달됩니다. 게시물 작성과 팔로워의 타임라인에 표시되는 사이에는 지연이 없습니다. Read Latency 증가 시스템이 포스트 데..
· DEV/Backend
Fan Out On Write (Push Model) Fan Out On Read (Pull Model)로 설명을 하면, 게시물 작성 할 때 , 해당 회원을 팔로우하는 회원들에게 데이터를 배달하는 것입니다 일종의 인덱스? 역할을 하는 Timeline 테이블을 만들어, 조회 시간을 줄여 시간복잡도에서 이득을 가져 가는 것이죠 정리를 하자면, Fan Out On Write(푸시 모델)는 게시물이 생성되는 즉시 팔로워의 타임라인에 게시물이 전달되는 소셜 미디어 시스템에서 사용되는 전략입니다. 실시간 업데이트 및 즉각적인 데이터 일관성을 보장하기 위해 타임라인 데이터가 팔로워의 타임라인으로 푸시됩니다. 단순화된 검색 게시물은 이미 팔로워의 타임라인에 전달되어 있기 때문에 팔로워가 자신의 타임라인에 액세스할 때 ..
berom
'DEV/Backend' 카테고리의 글 목록 (2 Page)