Database

mongodb+srv://mongodb-atlas-serverles.asdf.mongodb.net 위와같은 mongodb connection string이 있을때 해당 mongodb에 접속할 수 있는 실제 서버의 IP주소를 알고싶은 경우 다음과 같이하면 된다. # -type=SRV 옵션을 사용해서 DNS 레코드 중 SRV 타입을 검색한다 # connection string에 명시된 주소 앞쪽에 _mongodb._tcp 를 붙여준다. $ nslookup -type=SRV _mongodb._tcp.mongodb-atlas-serverles.asdf.mongodb.net Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: _mongodb._tcp.mongodb-atlas-serverles.asdf.mongodb.net service = 0 0 27017 mongodb-atlas-serverless-example-dev-lb.asdf.mongodb.net. 출력된 결과를 보면 mongodb-atlas-serverless-example-dev-lb.asdf.mongodb.net 부분이있는데 이것이 실제 주소이다. # 위에서 얻은 주소로 다시한번 쿼리 $ nslookup mongodb-atlas-serverless-example-dev-lb.asdf.mongodb.net Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: mongodb-atlas-serverless-example-dev-lb.dvfze.mongodb.net canonical name = 123456-nlb-12345.elb.ap-southeast-1.amazonaws.com. Name: 123456-nlb-12345.elb.ap-southeast-1.amazonaws.com Address: 13.213.131.24 Name: 123456-nlb-12345.elb.ap-southeast-1.amazonaws.com Address: 13.213.229.91 여기서 나온 IP 주소들이 실제 mongodb 서버의 주소이다. ...

RDBMS만큼의 정합성과 영속성을 보장할 필요가 없는 데이터들을 빠르게 처리하거나 일정 기간동안만 보관하고 있기 위한 용도로 레디스(Redis), memcached 등의 in-memory 기반 저장소가 많이 사용된다. 그중에서도 Redis는 빠른 성능을 유지하면서도 일정 수준 이상의 persistence를 제공하고, 다양한 native 데이터 구조들을 제공하여 효율적이고 편리한 사용이 가능하게 해주기 때문에 다양한 use-case들이 존재한다. 이 글은 실제 명령어를 날려서 레디스를 직접 사용해보는 것을 배우기 보다는 어떤 in-memory 저장소를 선택할지 고민하는 분들을 위해서 주요 운영 방식, 레디스의 내부 동작 방식 및 특징, 주요 클라이언트들에 대한 정보를 제공하는 쪽에 초점이 맞춰져 있다. ...

MySQL의 InnoDB 엔진은 SQL 표준에 정의된 4가지 트랜잭션 격리 수준(transaction isolation level)을 모두 제공한다. InnoDB 엔진의 트랜잭션 격리 수준 기본값은 REPEATABLE READ이다. MySQL client는 SET TRANSACTION 구문을 실행해서 격리 수준을 변경할 수 있고, server 자체에 옵션을 줘서 모든 client 연결에 대해 동일한 격리 수준을 적용하는 방법도 있다. 그러면 각각의 트랜잭션 격리 수준을 제공하기위해서 MySQL의 InnoDB 엔진이 어떤 방식을 사용하고있는지 가장 많이 사용되는 격리 수준 순으로 각각 알아보도록 하자. 1. REPEATABLE READ 앞서 언급했듯이 REPEATABLE READ 레벨의 경우 InnoDB 엔진에서 사용하는 디폴트 트랜잭션 격리 수준이고 특별한 성능 이슈가 없다면 잘 변경하지 않기때문에 가장 많이 사용된다. REPEATABLE READ를 만족시키기 위해서 MySQL InnoDB 엔진은 아래 두가지 방식을 사용한다. ...

대규모의 많은 요청이 동시에 들어오는 데이터베이스(Database, DB) 어플리케이션의 경우 데이터의 정합성을 유지하면서 최대한 동시성을 높이는 것이 매우 중요한 포인트이다. MySQL InnoDB 엔진의 경우 상황에 따른 여러가지 락(Lock)을 통해서 동시성을 제어하며 이를 통해서 사용자가 설정한 대로 원하는 수준의 트랜잭션 격리 수준(Transaction Isolation level)을 유지해준다. MySQL InnoDB 엔진은 사용자가 필요에 따라 명시적으로 locking read를 할 수 있도록 두가지 쿼리를 제공한다. 한 트랜잭션에서 읽어간 데이터를 다른 트랜잭션에서 배타적으로 수정하기 위해 락을 획득하려 할때 (읽어가는 것은 허용) 기다리게 만들고 싶다면 SELECT ... LOCK IN SHARE MODE 사용 한 트랜잭션에서 읽어간 데이터를 다른 트랜잭션에서 배타적으로 읽거나, 수정하기 위해 락을 획득하려할 때 기다리게 만들고 싶다면 SELECT ... FOR UPDATE 사용 예) 특정 필드의 값을 읽어온 후 (SELECT), 해당 값을 1 증가시켜서 저장 (UPDATE)하고 싶을때 이 경우 SELECT .. FOR UPDATE를 사용하지 않으면, 여러 트랜잭션이 동시에 접근할 경우 정상 동작 하지 않을 수 있다. 즉, 트랜잭션 2개가 실행되었는데 값이 2만큼 증가되지 않고 1만 증가되어있을 가능성 존재. 먼저 이러한 locking 구문들이 실제 어떤 lock들을 통해서 내부적으로 구현되는지 좀더 자세히 알아보도록 하자. ...

Thread에서 공유 자원에 동시 접근을 제한하기 위해 Lock을 걸듯이 DB에서도 트랜잭션들 간에 같은 동일한 데이터에 대한 동시 접근을 제한하기 위하여 Lock을 설정할 수 있다. Lock을 건다는 것은 그만큼 동시처리량이 줄어든다는 의미이기 때문에 과도하게 사용하면 성능에 문제가 생길 수 있다. 따라서 상황별로 꼭 필요한 수준의 Lock을 걸어서 정합성을 유지하고 최대한의 성능을 내기 위해서는 동시성 이슈가 발생할 수 있는 상황들을 정확히 정의하여 구분하는 것이 매우 중요하다. 다음에 설명하고있는 트랜잭션 격리 수준(Transaction isolation level)을 통해 이 부분을 명확히 정의 할 수 있다. ...

MySQL에서 벌크 인서트를 실행할때 내부 동작을 찾아보다 보니, 어찌어찌 MySQL InnoDB 스토리지 엔진 내부에서 AUTO_INCREMENT(오토인크리먼트)를 어떤식으로 핸들링하고 있는지가 더 궁금해져서 MySQL 레퍼런스 문서(MySQL 5.7 기준)를 읽으면서 아래 내용을 요약해보았다. 이제까지 AUTO_INCREMENT 컬럼에 대해서 아무 고민없이 값이 자동으로 잘 증가하겠거니 하고 사용해 왔을텐데, 내부적인 동작 방식을 정확히 이해해서 concurrency를 높여서 성능을 향상시킬 수 있는 튜닝 포인트를 확인해 보자. 인서트의 종류 구분 설명에 들어가기에 앞서 다양한 상황을 좀더 쉽게 설명하기 위해 인서트 구문의 종류를 구분해보면 다음과 같다. ...