[TIL - 1017] 트랜잭션 격리수준, mysql 설치/계정 설정, stored procedure, operation process
데이터베이스
트랜잭션 격리 수준(Lock 정책)
- 멀티쓰레드 환경에서 트랜잭션이 지켜야하는 트랜잭션 간의 간섭 금지(Isolation)와 속도 트레이드오프 발생 : 격리 수준 특징을 알아야 도메인 특징에 따라 알맞는 격리 수준을 골라 트레이드오프 상황을 벗어날 수 있을 것이라 생각됨
- 데이터베이스마다 다르기 때문에 어떤 격리 수준이 있는지는 알아봐야함
명칭 | 설명 | 발생할 수 있는 문제점 |
---|---|---|
read uncommited |
커밋되지 않은 데이터 변경까지도 다른 트랜잭션에서 읽기 가능 | phantom read, non-repeatable read, dirty read |
read commited |
커밋된 데이터 변경을 읽을 수 있음 | phantom read, non-repeatable read |
read repeatable |
조회한 데이터에 대해 Lock이 걸리고 수정할 수 없는 상태 | phantom read |
serializable |
하나의 트랜잭션이 처리될 동안 완전한 Lock - 다른 트랜잭션 처리 대기 | - |
- phantom read : 같은 범위에 대한 검색을 했는데 다른 트랜잭션의 작업으로 인해 다른 개수(삭제, 추가)가 검색됨
- non-repeatable read : 같은 데이터 임에도 불구하고 다른 트랜잭션의 작업으로 인해 변경된 데이터 값이 읽힘
- dirty read : 커밋되지않은 데이터가 읽히다보니 해당 데이터를 변경한 트랜잭션에 의해 커밋되지않았을 때 쓰레기 값이 되었지만 그대로 저장되는 문제
mysql 설치 후 계정 생성
- 설치 이후에는 root 계정만 존재하므로 사용자 계정을 생성해서 사용할 것 : 호스트 종류(localhost, @ <- 외부 접근), 접근 제어(예를 들어 특정 스키마만 접근, select 권한만) 등 생각하고 유저 생성
- mysql 5.7 부터 password가 아닌 authentication_string : user 테이블 조회 시
stored procedure
- 여러 쿼리를 하나의 프로시져로 선언해두고 요청이 들어왔을 때 실행함 : 말 그대로 절차를 저장해둠
- 네트워크에서 주고 받아야할 데이터가 줄어듬 : 쿼리 데이터 주고 받지 않아도 됨 - procedure 호출
- 특징에 대해서도 더 알아보기 : 어떤 점 때문에 사용하고 어떤 점 때문에 사용하기를 꺼리는지까지
- 오늘은 개념까지만…(잘자고 출근해야지!) 내일은 mysql에서 procedure 만들어두고 spring에서 procedure 호출해보는 것까지 해보면 좋겠..!
- mssql(sql-server)에서는 프로시져 권장이라는 말이 있던데 이 부분도 찾아보기
운영
프로세스
- 운영 프로세스에 대한 이해없이 업무를 할 수 없을 것 같다는 생각이 들어 프로세스를 찾아보고 정리해보았음
- 아직까지는 직접 겪어본 바에 비춰 적기보다 그동안 어렴풋이 알고 있었던 개념과 검색과 시니어분께 여쭤 얻은 답을 기반으로 정리함(제대로 느끼는 그 날이 얼른 오길)
- 회사에 따라 아래 프로세스를 다 가져가는 경우가 있는 반면 통합해서 진행하는 것으로 보여짐
환경 | 설명 |
---|---|
local |
개발자 개인 개발 환경 - 공통된 개발 환경과 코드컨벤션과 같은 약속이 되어있어야함(개발 후 통합했을 때에 대한 대비 및 원활한 팀 운영) |
development(dev) |
개발한 소스코드를 서버 환경과 같은 환경에 모아 테스트하는 환경, prod 서버 환경보다는 간소화(기능 위주의 테스트) |
integration |
컴포넌트 간의 의존성을 가지고 있을 때 한 곳으로 모아 테스트하는 환경 |
qa |
QA 엔지니어가 테스트하는 환경 - 항목을 짜두고 테스트 |
staging |
운영 환경으로 들어가기 전 최종적으로 거의 운영 환경과 동일하게 구성하여 테스트 하는 환경 |
production(prod) |
실제 서비스 운영 환경 |