일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | |
7 | 8 | 9 | 10 | 11 | 12 | 13 |
14 | 15 | 16 | 17 | 18 | 19 | 20 |
21 | 22 | 23 | 24 | 25 | 26 | 27 |
28 | 29 | 30 | 31 |
- 데이터 타입
- jpa
- Lock
- 자바
- 스프링
- iterator
- gc
- 동시성 문제
- 가비지 컬렉션
- MVCC
- text
- iterable
- Locking Read
- 백엔드
- 가비지 컬렉터
- foreach
- 동시성
- java
- Synchronized
- MySQL
- Atomic Type
- Di
- Varchar
- db
- CAS
- reflection
- Today
- Total
목록Database (6)
과정을 즐기자
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/Ei4Vt/btsF3XgLhEz/lBLzPKLUNVqkR7mkjeRmdK/img.png)
대학교 내 단체 모임 생성/참여 서비스 프로젝트를 진행하면서 영속적인 데이터를 RDB에 저장하기 위해 테이블 설계를 해보았습니다. 회원 정보, 학과 정보, 학교 정보, 클랜 정보(동아리 같은 그룹), 어셈블 정보(모임) 등의 테이블이 존재합니다.이때 유연한 설계가 필요한 요구 사항을 마주하게 되었는데 이번 글에서는 RDB로 어떻게 풀었는 지에 대한 글을 작성해보려고 합니다.📚 어려웠던 주요 요구 사항테이블 설계하면서 설계하기 어려웠던 요구 사항은 크게 2가지가 있었습니다. 1. 커스텀 필터 기능2. 어셈블 (모임 정보) 통합 관리 기능 이제부터 하나씩 살펴 보겠습니다.📘 커스텀 필터 기능문제 상황저희 서비스에서는 관리자가 어셈블(모임 정보)을 쉽게 관리할 수 있도록 하기 위해 참여한 회원을 학번, ..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/eiTPYK/btsv8wH3Jf4/HUYvsDdwDzpv9R3g65t6D0/img.png)
여러 트랜잭션이 동시에 실행된다면 데이터의 무결성에 문제가 생길 수 있으며 여러 트랜잭션을 순차적으로 실행한다면 성능이 좋지 않을 수 있습니다. 트랜잭션의 특징인 ACID 중에서 I인 Isolation level은 여러 트랜잭션을 실행할 때 트랜잭션끼리 얼마나 격리되어 있는 지를 나타냅니다. 트랜잭션의 격리 레벨에는 크게 4가지가 있습니다. 격리 레벨이 높은 순서대로 Serializable, Repeatable Read, Read Commited, Read Uncommited가 있습니다. Serializable 수준은 동시 처리 성능이 상당히 떨어지기 때문에 거의 사용되지 않으며 Read Uncommited 수준은 데이터의 무결성에 문제가 생길 수 있기 때문에 거의 사용되지 않습니다. 대부분의 RDBMS..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/b3jiST/btsv7dvceBL/WJL3zY6NxrFXmrkYzy9vxk/img.png)
백엔드 애플리케이션을 개발하면서 동시성 문제를 처리해야 하는 경우가 있습니다. DB의 Isolation Level이 있어서 적절한 레벨로 설정해주면 DB에서 동시성 문제는 발생하지 않을까요? 이번 글에서는 동시성 문제를 처리하는 방법에 대해 알아보겠습니다. 트랜잭션의 Isolation Level 트랜잭션의 특징인 ACID에서 I를 나타내는 Isolation Level은 여러 트랜잭션이 동시에 실행될 때 트랜잭션끼리의 격리 수준을 말합니다. 4가지 레벨이 있는데 격리성이 높은 순서대로 Serializable, Repeatable Read, Read Commited, Read Uncommited가 있습니다. MySQL, InnoDB에서는 기본적으로 Repeatable Read 레벨을 사용합니다. 이 레벨에서..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/GxY7m/btsHSVvm7Ws/PklkGkWK61No1Wg76BKvq1/img.png)
이번 글은 MySQL과 InnoDB 스토리지 엔진을 기준으로 작성하였습니다. MySQL에는 여러 데이터 타입이 있습니다. 숫자형 데이터 타입, 문자열 데이터 타입, 날짜 시간 데이터 타입 등..이 중에서 문자열 데이터 타입의 종류에는 CHAR, VARCHAR, TEXT 등이 있습니다.CHAR는 고정 크기 문자열 방식이고 VARCHAR는 가변 크기 문자열 방식이고 TEXT는 긴 문자열을 저장할 때 사용합니다. 이때 한가지 의문이 듭니다. VARCHAR가 가변 크기 문자열 방식이라면 TEXT를 사용하지 않고 그냥 최대 크기인 VARCHAR(16683)로 (65535 bytes) 선언하면 되지 않을까요? 어차피 10글자만 입력하면 실질적인 10글자인 40bytes를 저장하고 나머지 4byte는 길이정보로 사용..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/laH5X/btsnEnMpgy4/NPjq8zi0mGN1iS71JQFsm1/img.png)
저번 글인 MySQL 엔진 아키텍처에 이어서 이번에는 MySQL의 스토리지 엔진 가운데 가장 많이 사용되는 InnoDB 스토리지 엔진에 대해 알아보겠습니다. MySQL 전체 구조 InnoDB 스토리지 엔진 아키텍처 InnoDB는 MySQL에서 사용할 수 있는 스토리지 엔진 중 거의 유일하게 레코드 기반의 잠금을 제공하여 높은 동시성 처리가 가능하고 안정적이며 성능이 뛰어납니다. 프라이머리 키에 의한 클러스터링 InnoDB의 모든 테이블은 기본적으로 프라이머리 키를 기준으로 클러스터링되어 저장됩니다. 프라이머리 키가 클러스터링 인덱스이기 때문에 프라이머리 키를 이용한 레인지 스캔은 상당히 빠르게 처리될 수 있습니다. 쿼리의 실행 계획에서 프라이머리 키는 기본적으로 다른 보조 인덱스에 비해 비중이 높게 설정..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/cLSIA9/btsnbJvy1mT/b5KDHhRfd1ZrzU8ehp3N20/img.png)
MySQL 서버는 사람의 머리 역할을 담당하는 MySQL 엔진 과 손발 역할을 담당하는 스토리지 엔진 으로 구분할 수 있습니다. 이번 글에서는 MySQL 서버의 전체적인 구조와 MySQL 엔진에 대해서 작성해보겠습니다. MySQL의 전체 구조 MySQL의 전체 구조는 위 그림과 같습니다. MySQL은 일반 상용 RDBMS와 같이 대부분의 프로그래밍 언어로부터 접근 방법을 모두 지원합니다. MySQL 고유의 C API 부터 시작해 JDBC, ODBC 등을 제공합니다. 이러한 라이브러리를 이용해 모든 언어로 MySQL 서버에서 쿼리를 사용할 수 있게 지원합니다. 여기서 MySQL 엔진은 커넥션 핸들러, SQL 파서, 전처리기, 옵티마이저, 쿼리 실행기로 이루어지는데 각각의 요소에 대해 알아보겠습니다. MyS..