Database 55

ElasticSearch 이해하기!

엘라스틱서치(ElasticSearch)는 Apache Lucene 기반의 Java 오픈소스 분산 검색 엔진이다. 최근 ELK 스택이라는 로그 통합 시스템에도 많이 활용하지만, 해당 포스팅에서는 엘라스틱 서치 자체에 대해서 다룬다. 활용 용도 요즘 충분한 캐시는 규모가 있는 기업이라면 당연하게 되었다. 우리가 구글, 유튜브 등에서 게시글을 조회한다고 가정하자. 검색 결과를 매번 조회하면 엄청나게 큰 부하가 발생한다. 이때 캐시를 사용할 수 있을까..? 검색에서 캐시를 활용하기는 어렵다. 캐시는 보통 Key-Value 구조를 가진다. 아래의 게시글이 있다고 가정하자. 동해물과 백두산이 마르고 닳도록 하느님이 보우하사 우리나라 만세 이때 아래와 같이 엄청나게 큰 데이터를 중복해서는 엄청나게 많은 저장 공간이 ..

Database/NoSQL 2023.02.23

MySQL - 락 불필요한 데이터를 잠그는 문제 정리! (+ Index)

락은 DBMS이나 애플리케이션에서 동시성을 제어할 수 있는 방법이다. 해당 포스팅에서는 MySQL의 락에 대해 다룬다. 락 이란? 락을 통해 동시성을 제어할 때는 락의 범위를 최소화하는 것이 중요하다. 락의 범위가 길어지면 대기중인 DB 커넥션이 많아지므로 커넥션 풀 고갈로 이어질 수 있다. MySQL에서는 트랜잭션의 커밋 혹은 롤백시점에 잠금이 풀린다. 즉, 트랜잭션이 곧 락의 범위가 된다. 트랜잭션과 락 예시를 통해 알아보자. 한 트랜잭션 내에서 DB에 Update를 하고 새로운 이미지를 업로드한다고 한다고 가정하자. 트랜잭션과 락은 각각 아래의 역할을 수행한다. 트랜잭션 업로드가 진행되는 동안에도 DB 커넥션을 유지하고 트랜잭션을 지속한다. 업로드가 성공하면 트랜잭션을 커밋한다. 업로드가 실패하면 ..

Database/SQL 2023.02.17

레디스 데이터 타입 정리!

레디스에서는 다양한 데이터 타입(자료구조)를 지원한다. 각 데이터 타입의 특징과 각 타입 별로 지원하는 명령어를 알아보자. 1. String 가장 기본적인 데이터 타입으로 가장 많이 사용된다. 바이트 배열을 저장한다. (binary-safe) 바이너리로 변환할 수 있는 모든 데이터를 저장할 수 있다. 최대 크기는 512MB 주요 명령어 GET - 특정 키의 문자열 값을 가져온다. SET - 특정 키의 문자열 값을 저장한다. INCR - 특정 키의 값을 Integer로 취급하여 1 증가시킨다. DECR - 특정 키의 값을 Integer로 취급하여 1 감소시킨다. 위 두개 명령어는 Atomic하기 때문에 Race-condition이 발생하지 않는다. MSET - 여러 키에 대한 값을 한번에 저장한다. MGE..

Database/NoSQL 2022.12.29

MongoDB란 무엇인가?! (기본 이해하기!)

MongoDB는 기존에 사용하던 RDB의 확장성과 신속성 문제로 개발한 Database이다. MongoDB는 NoSQL의 한 종류로, Document라는 형식의 자료구조를 사용한다. 현재 기준(2022년 12월)으로는 DB-Engines라는 사이트에서 매긴 DB 순위에서 NoSQL 중에서는 1위, 전체 DBMS 중에서도 5위를 차지했다. 산정 기준은 검색 엔진(Google, Bing) 검색 횟수, Google 트렌드 검색 빈도, SNS(Twitter, LinkedIn), IT Q&A 사이트 (Stack Overflow) 이슈 등을 활용했다. 가장 먼저 SQL과 NoSQL의 차이를 간략히 알아보자. SQL vs NoSQL 해당 포스팅은 NoSQL에 대한 글으로 해당 내용은 너무 상세히 다루지는 않는다. R..

Database/NoSQL 2022.12.28

Redis에 대해 자세히 알아보기! (+ Cache, WriteBack, Cluster, ...)

최근에 정보 공유를 하는 곳에서 Redis에 대한 얘기를 많이 들었다. Redis를 광적(?)으로 선호하고 만세를 외치시는 분들이 정말 정말 많다! 사기템, 만세, 짱짱, 충성, ... Redis에 대해 이렇게 얘기하시는 분들도 많은 것 같다. 조금 큰 규모의 회사라면 대부분 Redis 터지면 서비스가 다 죽을 것이다. Redis가 없으면 문닫을 회사도 많다(?) 뭔가 이야기를 듣다보니깐 내가 잘 모르고 있구나.. 라는 것을 느꼈다. (공감이 안됨.. ㅠ) 그래서 Redis에 대해 더 자세히 알아보자. Cxxpang Redis 사태 2019년 7월 24일에 쿠팡의 모든 판매 상품 재고가 '0'으로 표시되어 주문 및 구매를 할 수 없는 큰 장애가 일어난다. 사유는 해당 시스템이 Redis DB를 통해 데이..

Database/NoSQL 2022.11.14

SQL - OneToOne 관계일 때 주의할 점 (+ Unique Key 설정)

SQL에서 1:1 (OneToOne) 관계를 정의할 때 반드시 고려해야 하는 부분이 있다. 예시를 통해 살펴보자. 주어진 상황 아래는 내가 설계한 DB의 일부이다. 계정과 회원을 굳이 분리한 이유는 성격이 다르다고 생각해서이다. 계정은 회원 정보에 속하기 때문에 보안 등급이 더 높고, 다른 테이블에서 Join을 할 때 회원 정보는 필요하지만 계정 정보는 필요하지 않기 때문에 해당과 같이 설계하였다. 계정과 회원은 1:1 (OneToOne) 관계를 맺는다. 이때 중요한 것은 서로에 대한 참조 키에 Unieque key를 걸어줘야 한다는 점이다. Unieque key 위 DB를 기준으로, User 테이블의 account_id 컬럼에 Unique Key를 걸어줘야 비로소 1:1이 된다. Unique key 조..

Database/SQL 2022.09.08

In-memory DB 비교 (Redis vs Memcached)

In-memory DB 비교 사이드 프로젝트 진행 도중 MSA로의 확장성 등을 고려하여 Session storage로 In-memory DB를 고려하게 되었다. (이점: https://jaehoney.tistory.com/165?category=970233) 휴대 전화 인증 등도 메인 DB와 분리하여 관리하기 위해 In-memory DB에 저장할 계획을 가지고 있다. 대표적인 In-memory DB로 redis와 memcached가 있는데 어떤 차이점을 살펴보자. 공통점 1ms 이하의 응답시간을 제공한다. 문법적으로 사용하기 쉽고 개발이 편리하다. 데이터를 여러 노드에 분산하여 저장할 수 있다. Redis String, Set, Hash, List 등 복잡한 데이터 타입을 지원한다. ub / Sub 패턴..

Database/NoSQL 2022.07.10

Database - 샤딩이란 무엇인가?! (+ 샤딩의 다양한 기법, 각 기법 비교)

서비스 오픈전에 J곡선 그래프를 타면서 성장하길 바라는 마음은 모두 같을 것이다. 그런 중요한 순간에 서버가 바틀넥이 되어 발목을 잡으면 안된다. 그래서 예측 가능한 서버 확장 방안에 대해서 사전에 준비를 해둬야 한다. DB 샤딩은 데이터가 급격히 증가하게 되거나 트래픽이 특정 DB로 몰리는 상황을 대비해서 빠르고 유연하고 안전하게 DB를 증설할 수 있게 한다. 샤딩에 대해 알아보자. 샤딩 샤딩(Sharding)은 DB 트래픽을 분산할 수 있는 중요한 수단이다. 추가적으로 특정 DB의 장애가 전면 장애로 이어지지 않게 하는 역할도 한다. 샤딩은 각 DB 서버에서 데이터를 분할하여 저장하는 방식이다. 해당 데이터에 접근할 때는 샤딩키를 사용하여 동적으로 DB 서버를 매핑하는 과정이 필요하다. 샤딩과 수평적..

Database/Server 2022.07.09

Real MySQL - Replication(복제)란 무엇인가?!

데이터베이스를 사용할 때 가장 중요한 두 가지는 확장성(Scalability)과 가용성(Availability)이다. 서비스에서 발생하는 대용량 트래픽을 안정적으로 처리하기 위해서는 서버의 확장이 필수적이며, 사용자가 언제든지 안정적인 서비스를 이용할 수 있게 하려면 DBMS 서버를 포함한 하위 시스템들의 가용성이 반드시 뒷받침되어야 한다. 이 두 요소를 위해 가장 일반적으로 사용하는 기술이 복제(Replication)이다. 복제 복제(Replication)는 한 서버에서 다른 서버로 데이터가 동기화 되는 것을 말한다. 원본 데이터를 가진 서버를 소스(Source) 서버, 복제된 데이터를 가지는 서버를 레플리카(Replica) 서버라고 부른다. 소스 서버에서 데이터가 변경되면 레플리카 서버에서는 변경 내..

Database/SQL 2022.07.07

MySQL - 비트마스크 컬럼을 사용하지 않아도 되는 이유 (+ SET Type)

MySQL에서 동일한 여러가지 플래그를 만들 일이 생긴다. 다음 그림은 내가 신입때 만든 프로젝트의 ERD 일부이다. 해당 테이블을 설계하면서 고려했던 방식은 두 가지이다. 비트마스크로 부모 테이블안에 1개 컬럼으로 저장하는 방식 테이블 1개로 추출해서 저장하는 방식 비트마스크로 처리하면 가독성을 망치고 구현이 힘들어진다. 그리고 DBMS에서 컬럼마다 데이터 크기를 정의할 수 있다. 그래서 두 번째 방식으로 테이블을 설계하게 되었다. (발표 때 아무도 태클 걸어 주지 않으셨다.) SET TYPE MySQL 데이터 타입 레퍼런스를 보던 중 SET이라는 것이 눈에 들어왔다. SET은 ENUM처럼 문자열 값을 MySQL 내부적으로 정수 값으로 매핑해서 저장하는 방식의 타입이다. 하지만 SET은 ENUM과 달리..

Database/SQL 2022.06.30