No name

프라이머리 키에 의한 클러스터링 프라이머리 키는 다른 보조 인덱스에 비해 높은 비중 다른 인덱스는 프라이머리 키를 논리적인 주소로 활용 외래키 외래키 지원함 다만 데이터의 수정이 다른 테이블로 전파되므로, 데드락 등의 잠금이 발생할 가능성이 큼 MVCC 멀티버전: 하나의 레코드에 여러 개의 버전이 동시에 관리 목적: 잠금을 사용하지 않는 일관된 읽기 제공 레코드가 트랜잭션 중에 읽기 요청이 발생할 경우, 격리 수준에 따라 제공되는 값이 다름 READ_UNCOMMITED: 트랜잭션에 의해 변경된 값을 반환 REPEATABLE_READ, SERIALIZABLE: 트랜잭션 이전의 값을 반환 잠금 없는 일관된 읽기 MVCC 기술을 이용해 트랜잭션 중이더라고 잠금 없이 읽기가 가능 격리수준에 따라 읽기 명령의 값..

백엔드에 입문한 이래로, 계속하여 대용량 데이터 혹은 대용량 트래픽처리는 어떻게 하는 것인가에 대한 생각을 하고 있다. 백엔드 개발자로써 모든 능력이 중요하겠지만, 대용량 트래픽을 감당할 수 있는 아키텍처 설계 및 구현보다 더 중요한 능력은 없다고 생각하기 때문이다. 아마 이는 병렬컴퓨팅과 비슷한 내용일 것이다. 병렬컴퓨팅은 여러 컴퓨터를 사용하여 하나의 거대한 계산을 처리하는 컴퓨팅 방법으로, 병목현상이 어디서 발생하는 지, 어떤 오버헤드가 발생할 지에 대해 끊임없이 생각하여야 한다. 물론 코드의 계산 효율을 고려하는 것은 당연시해야 한다. 아직은 잘은 모르겠지만, 대용량 트래픽 처리 역시 서비스에서 발생하는 병목지점을 찾고 이를 해결하는 방법에서 시작하리라 믿는다. 현재 존재하는 대부분의 어플리케이션..

Sears, R., C. Ingen, J. Gray, 2006: To BLOB or Not to BLOB: Large Object Storage in a Database or a Filesystem?, MSR-TR-2006-45 들어가기에 앞서 일반적으로 이미지나 동영상 파일을 DB에 저장할 때는, 파일은 파일시스템에 저장하고 그 링크만 DB에 저장한다(현재 부트캠프에서도 이와 같이 배웠다). 그런데, 링크만 저장할 경우에는 DB를 읽고, 그 링크에서 따로 파일을 로딩하는 로직을 따로 거쳐야 하는 코드를 작성하는 등 이중으로 로직을 작성해야 한다. 하지만, 이미지나 데이터를 DB에 바로 저장한다면 추가적인 작업이 필요가 없을텐데 라는 생각이 들어서 검색을 하게 되었다. 개발자 포럼 중 한 곳에서 DB에 ..