친절한 SQL 튜닝 - 2. 인덱스 구조 및 탐색
미리 보는 인덱스 튜닝 특정 데이터를 찾는 방법은 크게 아래의 두 가지로 나뉜다. * 테이블 전체를 스캔한다. * 인덱스를 이용한다. 찾으려는 데이터가 중복이 많다면 전자가 빠를 것이고, 몇 안된다면 후자가 빠르다. 그리고 인덱스의 경우 큰
미리 보는 인덱스 튜닝 특정 데이터를 찾는 방법은 크게 아래의 두 가지로 나뉜다. * 테이블 전체를 스캔한다. * 인덱스를 이용한다. 찾으려는 데이터가 중복이 많다면 전자가 빠를 것이고, 몇 안된다면 후자가 빠르다. 그리고 인덱스의 경우 큰
우선 개발 중인 서버의 요구사항은 아래와 같습니다. Chosung 이라는 테이블이 있고 해당 테이블에서 클라이언트에게 전달될 랜덤한 N개의 초성 데이터를 뽑아내야합니다. 아무래도 선택된 데이터들은 초성 게임에서 사용될 데이터들이니 최대한 빠른 응답성을 가져야 한다는 특징도
1.1 SQL 파싱과 최적화 구조적, 집합적, 선언적 질의 언어 SQL은 단어 그대로 구조적 질의 언어이다. 해당 언어는 아래와 같은 순서로 실행된다. 옵티마이저가 프로그래밍을 대신해서 최적의 계획을 통해 프로시저를 작성한다. * 사용자 ->
가시성 특정 변수의 값을 여러 스레드가 가져갈 때, 한 스레드가 작성한 값을 가져간다는 보장을 할 수 없다. 그래서 메모리상의 공유된 변수를 여러 스레드에서 접근할 때는 반드시 동기화 기능이 구현되어야 한다. public class NoVisibility
자바 병렬 프로그래밍을 읽으면서 문득 ThreadLocal이라는 클래스가 어떻게 스레드마다 서로 다른 참조를 유지시키는지 궁금해졌다. 이를 파악해본다. 먼저 공부를 하기 전 내가 모르는 사항은 아래와 같았다. 1. ThreadLocal 도 클래스이고 인스턴스가 생성될 경우 힙
동기화 프로그램 작성 시 아래의 3가지 사항을 고려한다. 1. 해당 상태 변수를 스레드 간에 공유하지 않거나 2. 해당 상태 변수를 변경할 수 없도록 만들거나 3. 해당 상태 변수에 접근할 땐 언제나 동기화를 사용한다.
본 포스팅은 java의 nio 패키지의 Selector를 활용하여 Redis와 간단한 연산을 통해 통신하는 법을 알아봅니다. 또한 논블로킹과 블로킹 처리의 초당 요청 처리수의 비교도 해보는 포스팅입니다. 단순히 생각해보면 무조건 논블로킹이 더 많은 초당 요청 수를
이번 포스팅에서는 Java Reactive Streams이 어떤 요구사항에 의해 생겼는지 그리고Publisher와 Subscriber의 기본적인 동작에 대해서 작성할 예정입니다. Iterable vs Observable Project Reactor의 공식문서 [https://projectreactor.io/docs/core/release/reference/#intro-reactive]에서 Reactive stream와
이번 글은 Future와 CompletableFuture의 동작을 간단히 소개하고, 왜 Future 타입의 경우 100% non-blocking이라고 할 수 없는지 그리고 이를 해결하기 위해 어떤 점이 개선되어야 하는지 알아봅니다. Future 인터페이스의 문제점 대부분의 개발자가 알고 있듯이, Future는
이번 포스팅에서는 스프링 환경에서 @Async 어노테이션을 통해 비동기로 메서드 로직을 처리하는 방법과 원리에 대해서 알아본다. @Async 적용하기 우선 springboot 환경에서 @Async 를 적용하는 방법부터 먼저 알아보자. 아래와 같이 @EnableAsync 어노테이션을 추가해주자. 별도의 Config가