인덱스를 살펴보기 전 해당 인덱스 장에서 자주 언급될 랜덤 I/O, 순차 I/O와 같은 디스크 읽기 방식을 먼저 간단히 알아보고 인덱스를 살펴보려한다. 컴퓨터의 CPU나 메모리처럼 전기적 특성을 띤 장치의 성능은 짧은 시간 동안 매우 빠른 속도로 발전했지만 디스크 같

여러 트랜잭션이 동시에 처리될 때 특정 트랜잭션이 다른 트랜잭션에서 변경하거나 조회하는 데이터를 볼 수 있게 허용할지 말지를 결정하는 것READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE 4가지로 나뉜다DI

MySQL에서 사용되는 잠금은 크게 스토리지 엔진 레벨과 MySQL 엔진 레벨로 나눌 수 있다.스토리지 엔진 레벨의 잠금은 스토리지 엔진 간 상호 영향을 미치지 않는다MySQL 엔진 레벨의 잠금은 모든 스토리지 엔진에 영향을 미친다글로벌 락은 FLUSH TABLES W

MySQL의 동시성에 영향을 미치는 잠금과 트랜잭션, 트랜잭션의 격리수준을 살펴보려한다.트랜잭션은 작업의 완전성을 보장해 주는 것이다.즉, 논리적인 작업 셋을 모두 완벽하게 처리하거나, 처리하지 못할 경우에는 원 상태로 복구해서 작업의 일부만 적용되는 현상(Partia

MySQL 서버가 시작되거나 종료될 때는 MySQL 서버(InnoDB 스토리지 엔진)의 버퍼 풀 내용을 백업하고 복구하는 과정이 내부적으로 실행된다. 실제 버퍼 풀의 내용을 백업하는 것이 아니라, 버퍼 풀에 적재돼 있던 데이터 파일의 데이터 페이지에 대한 메타 정보를

MySQL 서버는 사람의 머리 역할을 담당하는 MySQL 엔진과손발 역할을 담당하는 스토리지 엔진으로 구분됨손과 발의 역할을 담당하는 스토리지 엔진은 핸들러 API를 만족하면 누구든지 스토리지 엔진을 구현해서 MySQL 서버에 추가해서 사용할 수 있다.MySQL 엔진과

REST란 "Representational State Transfer"의 약자이다.REST API는 URI(Uniform Resource Identifier)를 사용해 자원(Resource)을 식별하고, HTTP를 통해 해당 자원에 대한 CRUD 요청을 수행한다.가장

이번에 사내 업무로 IoT 연결 상태 동기화를 위해 기존의 폴링 방식 아키텍처에서 이벤트 기반 아키텍처로 변경해 성능 및 비용 효율화를 진행한 건이 있어 기록하고자 한다.우선 어떤 문제를 풀었는지 얘기하기 전에, 기존 시스템 구조에 대해 간략히 설명하겠다.솔루션은 아래

티켓팅 서비스 개발 중 관습처럼 사용하던 엔티티 ID Long에 대해서 왜 long은 안쓰는 건지 궁금해 알아보았다.우선 둘의 차이점은 간단하게 다음과 같다.Wrapper Classnull을 허용함Primitive Typenull을 허용하지 않음기본값 0Hibernat

지난 3편에서의 CQRS 개념까지 반영해, 길고길었던 설계를 마무리하고 다음과 같은 산출물이 나왔다.Redis의 SortedSet을 사용해 유저들을 대기 순번 기준으로 정렬해 큐처럼 사용현재 순위(순번) 조회가 많이 발생할 것으로 예상되어, 해당 작업에 O(N)이 발생

이전 설계 2편에 이어 해당 편은 도입 검토중인 CQRS에 대해서 알아본 것을 정리하고 어떤 형태로 적용할지 결정하려 한다.명령(시스템 데이터 변경) 역할을 수행하는 구성 요소와 쿼리(시스템 데이터 조회) 역할을 수행하는 구성 요소를 나누는 것.명령시스템 데이터 변경기

지난번 이벤트 스토밍 설계에 이어 이번엔 이 설계를 어떻게 기술적으로 구현할지에 대한 고민을 해보려 한다. 서비스는 회원, 공연, 대기, 결제 도메인으로 나뉘는데 가장 중요하고 트래픽이 많이 발생할 것으로 보이는 공연/대기/결제 도메인 먼저 설계하려한다. 이 중

드디어 본격적으로 자바, 객체지향, 토비의 스프링 공부가 마무리 되어가 애초 목표했던 안정적인 대용량 트래픽 처리가 가능한 인터파크 같은 온라인 대용량 티켓팅 서버를 구축해보려 한다.점점 경력이 쌓여감에 따라, 이전까지 해왔던 경험과 지식만으로는 부족함을 느꼈고, 시니

SOLID 객체지향 5대원칙에 대해 정리해보고자 한다.

Stream의 성능적 관점에 대해서 얘기해보고자 한다.

본 주제를 다루기 앞서, 먼저 단방향 암호화에 대해 정리하려한다.

자바의 신 마무리 1편이 너무 길어져 2편에서 마저 정리해보려한다.2편의 키워드는 Thread, File, Serializable, Network이다.

드디어 이번주면 자바의 신 1,2권 멘토링이 마무리 된다.지금까지 열심히 공부해왔던 자바의 신 책 마지막에 기말고사가 있어 이를 스스로 정리해보고자 한다.

이번엔 멘토링 수업에서 받았던 Thread 관련 질문 중 명확히 설명하지 못한 키워드들을 한데 모아서, 다시 한번 개념 정리를 해보려 한다. 키워드들은 아래와 같다.race conditionspinlocksemaphoremutexdeadlockmonitor먼저 race

Synchronized Collection과 Concurrent Collection의 차이에 정리해보려 한다.