NoSQL
- 여러 서버에 데이터 분산 저장
- 조인이 지원되지 않는 데이터베이스
- 스키마 가질 수 없는 데이터베이스
CAP 정리
CAP정리란 컴퓨터 과학 분야에서 분산 컴퓨터 시스템을 설명하는 데 사용되는 이론으로 일관성(Consistency), 가용성(Availability), 분할 허용성(Partition Tolerance)를 의미한다. 이때 두 가지 속성만을 지원하며 나머지 한 속성은 특정 조건에서만 만족한다. 먼저 분산 시스템에서 사용하는 용어를 살펴보자.
위 그림은 분산 시스템을 구성하는 개별 요소들을 나타내고 있다. 분산 시스템을 구성하는 각각의 하드웨어 또는 소프트웨어를 노드라고 부르며, 동일한 기능을 수행하는 노드들의 모음을 클러스터라고 한다. 분산 시스템은 하나 혹은 그 이상의 다중 클러스터로 구성될 수 있다. 다중의 클러스터에서 각 클러스터는 동일 지역 혹은 지역적으로 떨어진 위치에 존재할 수 있다. 이때 각 클러스터 간의 연결을 네트워크를 기반으로 한다. 이 내용을 기반으로 CAP 정리의 세가지 특성을 살펴본다.
1. 일관성(C)
일관성은 동시성 또는 동일성이라고도 하며 '다중 클라이언트에서 같은 시간에 조회하는 데이터는 항상 동일한 데이터임을 보증하는 것'을 의미한다. 관계형 데이터베이스로 설명하면 '클라이언트 A가 특정 컬럼에 저장된 데이터값 300을 500으로 변경한 직후에 다른 클라이언트 B가 조회한 해당 컬럼의 데이터값은 항상 500이어야 한다'라는 조건이다.
예를 들어 어제 블로그에 글을 등록하고 오늘 낮 1시에 수정했다고 가정한다. 여러분이 작서한 글을 오늘 1시 1분에 다른 사람이 보았을때 어제 등록된 글의 내용이 보이는 것이 정상인가? 아니면 처음 등록한 글이 보이는 것이 정상인가? 어찌 보면 매우 당연한 이야기일 수도 있지만 일관성을 지원하지 않는 NoSQL을 사용한다면 처음 등록한 글이 보일 수도 있다.
일관성은 관계형 데이터베이스가 지원하는 가장 기본적인 기능이다. 하지만 NoSQL에서는 빠른 분산 처리를 위하여 일관성을 희생하기도 한다. 위에서 설명한 이론에 따라서 가용성과 분할 허용성을 지원하는 NoSQL은 일관성이 느슨하게 처리되어 위와 같은 상황이 발생할 수 있다. 대부분 시간이 지남에 따라 수정된 내용이 다른 노드로 전파되어 반영된다. 데이터의 변경이 다른 노드로 전파되는 상황이다.
1. 클라이언트1이 노드 A에 접소하여 key1에 300이라는 값을 저장한다.
2. 노드 A에서 '데이터 변경 전파' 이벤트가 발생한다.
3. 데이터 변경 전파 이벤트에 의해 노드 B에 key1과 값 300이 복제된다.
4. 클라이언트1이 노드 A에 저장된 key1의 값을 500으로 변경한다.
5. 클라이언트2가 노드 B에 접속하여 key1의 값을 조회한다. 노드 A에 저장된 key1의 값이 변경된 이후에 데이터 변경 전파 이벤트가 발생하지 않았기 때문에 처음 복제된 값인 300이 조회됐다.
6. 데이터 변경 전파 이벤트가 발생한다.
7. 데이터 변경 전파 이벤트에 의해 노드 B의 key1의 값이 500으로 변경된다.
8. 클라이언트2에서 노드 B에서 key1의 값을 조회한다. 데이터 변경 전파 이벤트 이후에 데이터를 조회했으므로 변경된 값인 500이 조회된다.
위와 같은 방법을 사용하여 일관성을 유지하는 것을 최종 일관성(Eventual Consistency) 또는 궁극적인 일관성이라고 하며, 시간이 지나감에 따라 결과적으로 일관성이 보장되는 상황을 일컫는다. 위에서 표현한 데이터 변경 전파 이벤트는 NoSQL에서 실제로 존재하는 용어는 아니다.
각 NoSQL은 분산 노드 간의 데이터 동기화를 위해서 두가지 방법을 제공한다. 첫번째로 데이터의 저장 결과를 클라이언트로 응답하기 전에 모든 노드에 데이터를 저장하는 동기식 방법이 있다. 동기식 방법은 모든 노드의 데이터 저장이 완료되는 시간 동안 클라이언트에게 저장 결과를 돌려줄 수 없으므로 느린 응답시간을 보이지만, 강한 데이터의 정합성을 보장한다. 두번재로 메모리나 임시 파일에 기록하고 클라이언트에 먼저 응답한 다음, 특정 이벤트 또는 프로세스를 사용하여 노드로 데이터를 동기화하는 비동기식 방법이다. 비동기식 방법은 클라이언트에게 빠른 응답을 줄 수 있지만, 쓰기 노드에 장애가 발생하였을때 데이터를 잃어버릴 수 있는 단점이 있다.
NoSQL에서 엄밀한 일관성은 최종 일관성에 반대되는 개념이다. 분산 시스템에서 일관성을 유지하기 위해서는 응답시간(latency)의 희생이 따른다. 이와 같은 응답시간의 지연을 방지하기 위해서 일관성과 응답시간의 적절한 타협점을 찾기도 한다. 널리 알려진 NoSQL 중의 하나인 카산드라를 예로 들면 성능과 일관성의 적절한 타협점을 사용자가 지정할 수 있는 일관성 레벨을 지원한다. 이 값의 설정에 따라서 응답 시간을 조절할 수 있다.
많은 NoSQL 솔루션을 읽기와 쓰기의 성능 향상을 위해 데이터를 메모리에 임시로 기록한 다음 클라이언트에 응답하고 백그라운드 스레드 (혹은 프로세스)로 해당 데이터를 디스크에 기록한다. 이런 처리 방식의 장점은 빠른 응답 속도에 있으며, 데이터의 변경에 따른 수정 비용이 적게 든다는 장점이 있다. 반면 정전과 같은 하드웨어 장애 발생시에는 데이터 유실이 발생할 수 있다. 카산드라와 HBase에서는 이런 데이터의 유실을 방지하기 위하여 메모리에 저장하기 전에 커밋 로그 및 WAL(Write Ahead Log) 파일에 먼저 정보를 기록하여 데이터의 유실을 방지하는데, 레디스도 이와 유사한 기능인 AOF(Append Only File)를 사용한다.
카산드라의 일관성 레벨
가용성과 분할 허용성을 지원하는 카산드라는 최종 일관성을 지원한다. 최종 일관성이란 시간이 지남에 따라서 최종적으로 일관성이 유지되는 일관성을 말한다. 또한 카산드라는 설정값을 조절하여 강한 일관성을 지원할 수 있다. 카산드라에서 설정 가능한 주요 일관성 레벨은 다음과 같다.
- One: 하나의 노드로부터 읽기 또는 쓰기의 성공 응답을 받으면 클라이언트로 응답한다.
- Quorum: '설정된 복제 계수 / 2 + 1'개의 노드로부터 읽기 또는 쓰기 성공 응답을 받으면 클라이언트로 응답한다.
- All: '설정된 복제계수'의 노드로부터 읽기 또는 쓰기의 성공 응답을 받으면 클라이언트로 응답한다.
'설정된 복제계수'는 카산드라에서 사용되는 속성으로서 데이터 복제본을 몇개나 저장할지 결정한다. 상용 서비스에서는 복제본 3개가 권장된다. 일관성 레벨을 Quorum으로 설정하면 위의 공식에 따라서 2개의 노드에서 데이터 처리 응답을 받고 나서 클라이언트로 응답한다. 일관성 레벨이 One일때 가장 빠른 응답 시간을 가지며, 일관성 레벨이 All일 때 가장 느린 응답을 가지게 된다. 이와 같인 응답시간(=성능)을 희생하여 강한 일관성을 지원할 수 있다.
2. 가용성(A)
가용성이란 '모든 클라이언트의 읽기와 쓰기 요청에 대하여 항상 응답이 가능해야 함을 보증하는 것'이며 내고장성이라고도 한다. 내고장성을 가진 NoSQL은 클러스터 내에서 몇개의 노드가 망가지더라도 정상적인 서비스가 가능하다. 예를 들어 물리적인 3개의 데이터 저장소를 가지는 클러스터에서 하나의 데이터 저장소가 제거되더라도 전체 클러스터에 영향을 주지 않는다면 가용성을 가진다고 말할 수 있다. 이는 시스템 아키텍처 설계에서 말하는 고가용성(High Availabity)과 유사한 개념으로 볼 수 있다.
몇몇 NoSQL은 이와 같은 가용성을 보장하기 위해 데이터 복제를 사용한다. 동일한 데이터를 다중 노드에 중복 저장하여 그중 몇 대의 노드가 고장 나도 데이터가 유실되지 않도록 하는 방법이다. 가용성을 지원하는 NoSQL은 부분 노드 장애 상황에서도 데이터의 조회와 저장에 대한 처리가 가능하다. 5개의 노드로 구성된 클러스터를 표현한 그림을 살펴보자.
하나의 데이터가 세 개의 노드에 분산 저장되는 형태를 보여준다. 노드 다섯 개 중 두 개에 장애가 발생했는데도 데이터를 정상적으로 조회하고 수정할 수 있다. 즉, 노드 2와 노드 4에 장애가 발생하더라도 데이터"2"을 노드 3에서 읽을 수 있기 때문에 데이터의 유실이 발생하지 않는다. 가용성을 위한 데이터 중복 저장 방법에는 동일한 데이터를 가진 저장소를 하나더 생성하는 마스터-슬레이브 복제 방법과 데이터 단위로 중복 저장하는 피어-투-피어 복제 방법이 있다.
마스터-슬레이브 복제는 관계형 데이터베이스 시스템에서 고가용성을 지원하기 위한 솔루션으로 사용되기도 한다. 가용성을 설명하면서 빠지지 않는 단어가 단일 고장점 SPOF(Single Point Of Failure)이다. 단일 고장점이란 시스템을 구성하는 개별 요소 중에서 하나의 요소가 망가졌을때 시스템 전체를 멈추게 만드는 요소를 말한다. 단일 고장점을 가진 NoSQL은 자체적으로 가용성을 지원하지 못하기 때문에 이를 지원하기 위해 별도의 솔루션을 사용하기도 한다.
단일 고장점
단일 고장점을 가진 솔루션들은 분산 환경에서 전체 서비스가 중단되는 심각한 문제가 발생할 수 있기 때문에 기피 대상이다. 예를 들어 대표적인 컬럼 모델 NoSQL인 HBase는 단일 고장점을 가지고 있다. HBase는 하둡이 제공하는 HDFS에서 동작하는데, 하둡의 네임노드가 단일 고장점이다. 네임노드는 하둡의 데이터 노드에 저장된 파일의 위치 정보를 가지고 있다. HBase를 사용하면서 가용성을 지원하기 위해서 리눅의 HA 솔루션과 DRDB와 같은 솔루션을 적용하여 가용성을 확보하기도 한다.
3. 네트워크 분할 허용성(P)
Partition tolerance라는 용어를 흔히들 분할 허용, 분산 가능, 파티션 허용, 부분 결함 허용 등으로 번역하는데 충분해 보이지 않는다. 오픈소스 분산 파일 시스템 하둡의 창시자가 이끄는 회사인 클라우데라의 블로그에 게시된 포스팅에서 Partition tolerance를 네트워크 분할 허용성(Tolerance to Network Partitions)으로 설명하고 있다. 즉, 지역적으로 분할된 네트워크 환경에서 동작하는 시스템에서 두 지역 간의 네트워크가 단절되거나 네트워크 데이터의 유실이 일어나더라도 각 지역 내의 시스템은 정상적으로 동작해야 함을 의미한다.
CAP 정리를 구성하는 세 가지 요소인 일관성, 가용성, 분할 허용성에 관하여 알아보았다. CAP 정리와 각 NoSQL이 지원하는 특징을 한장의 그림으로 표현하면 다음과 같다.
CA 영역에 있는 RDBMS는 일관성과 가용성을 지원한다. 두가지 속성만을 지원한다는 의미는 아니다. 선택된 두 가지 속성을 지원하기 위해 나머지 한 속성에 대한 희생이 필요하다는 의미다.
일관성, 가용성, 분할 허용성 중에서 어떤 두가지 속성을 지원하는지에 따라서 NoSQL의 특징이 달라지게 된다.
NoSQL 종류
1. 키-값 모델 NoSQL
- 가장 기본적인 NoSQL의 형태로, 키 하나로 데이터 하나를 저장하고 조회할 수 있는 단일 키-값 구조를 가진다.
- 키-값 모델 NoSQL로는 레디스(C언어로 구현되어 있음), 리악, 볼드모트, 다이나모 등이 있다.
- 주로 사용자의 프로필정보, 웹서버의 클러스터를 위한 세션정보, 장바구니정보, URL단축정보저장 에 사용된다.
user:1:orderlist, user:3:orderlist에는 각 사용자의 구매 목록이 저장되어 있고, order:1, order:2, order:3은 구매목록에 대한 세부 주문 내용을 저장한다.
2. 문서 모델 NoSQL
- 문서 모델은 하나의 키에 하나의 구조화된 문서(JSON, BSON, XML등)를 저장하고 조회한다.
- 문서 모델 NoSQL의 키는 문서에 대한 ID로 표현된다. ( 문서 저장과 동시에 문서 ID에 대한 인덱스를 생성)
- B트리 인덱스를 사용하여 2차 인덱스를 생성하므로 B트리가 커질수록 데이터 입력, 삭제 성능이 떨어진다. 따라서 읽기:쓰기 비율이 7:3일때가 가장 좋은 성능을 보인다.
- 문서 모델 NoSQL로는 MongoDB(자동샤딩지원), 카우치베이스, 테라스토어, 레이븐DB 등이 있다.
- 주로 중앙 집중식 로그 저장, 타임라인 저장, 통계 정보 저장할 때 사용된다.
user:1:orderlist 키는 사용자1의 주문 목록을 저장하고 있으며, 문서 내부에 개별 주문 정보가 포함되어 있다.
만약 주문번호4,원두커피,강남구신사동으로 정보를 추가한다고 할 때는, 주문번호 4번 조회 후 없으면 추가생성 append하면 된다.
3. 컬럼 모델 NoSQL
- 컬럼 모델은 가장 복잡한 구조로 하나의 키에 여러 개의 컬럼 이름과 컬럼 값의 쌍으로 이루어진 데이터를 저장하고 조회한다. 모든 컬럼은 항상 타임스탬프(버전스탬프)값과 함께 저장되고, 키를 로우키라 부른다.
- 컬럼모델은 테이블의 모든 로우키가 사전식으로 정렬되어 저장된다. 따라서 시작키, 종료키 조건을 사용하여 범위 지정 조회가 가능하다.
- 컬럼모델로는 HBase, 카산드라, 하이퍼 테이블 등이 있다.
- 주로 채팅 내용 저장, 메일 저장소, 알림 내용 저장, 실시간 분석을 위한 데이터 저장소 등의 서비스 구현에 적합하다.
3. 그래프 모델 NoSQL
- 그래프 모델 NoSQL은 관계형데이터베이스와 가장 유사한 형태로 노드와 관계로 표현한다.
- 친구 추천과 같은 연관검색을 위한 정보를 저장하고 조회하는데 적합하다.
언제 NoSQL을 사용해야 하는가
NoSQL은 빅데이터 환경에서 분산 저장소로 RDB를 사용하는 것 보다 더 낫다. '언제 NoSQL을 사용해야 하는가?'와 같은
질문보다 더 중요한 것은 '어떤 NoSQL을 선택해야 하는가?' 이다.
이 문제가 왜 중요한지 음악 스트리밍 서비스를 예를 들어보자. 도입할 NoSQL은 카산드라(컬럼모델)로 6대 노드를 사용한다고 가정한다. 이 서비스에서는 사용자가 좋아하는 음악을 추천하기 위해서 사용자 활동을 음원 클릭 현황 테이블에 기록하고 있다. 이 테이블은 사용자가 선택한 카테고리에 대한 클릭 수와 음악의 클릭수를 저장한다.
이 테이블의 레코드는 매일 수천만 번의 변경이 발생하고 하루에 한번 조회된다.
음악 클릭 횟수를 저장하는 방법을 생각해본다. 먼저 사용자의 음악 클릭 횟수를 저장하는 컬럼을 조회한다. 조회된 값이 존재하면 기존 값에 1을 더하여 저장하고, 그렇지 않으면 값이 1인 컬럼을 저장한다. 이 구현이 정상적으로 동작할까? 이와 같은 구현방법은 잘못된 값이 저장될 가능성이다.
카산드라의 일관성 레벨과 변경 전파 이벤트에 대해서 잠시 생각해보자. 복제계수가 3으로 설정됐다고 가정하면, 논리적으로 3개의 다른 값을 가진 컬럼이 존재할 수 있다. 동시에 5명의 사용자가 동일한 MP3 파일을 클릭했다고 가정하면 최종 저장되는 값을 최소 1에서 최대 5가 될 수 있다. 물론 카산드라는 카운터라는 필드를 제공하며 99.9%의 정확도록 일관성을 제공할 수 있다. 하지만 이 값이 숫자가 아닌 문자라면? 완벽한 일관성을 제공받기 위해서는 카산드라에서 복제계수를 1로 설정하여 가용성을 포기하든지, 일관성 레벨을 All로 설정하여 성능을 희생해야 한다. 보통 이런 상황에서는 일관성 레벨을 All로 설정한다. 겨로가적으로 고나계형 데이터베이스와 비교하여 큰 차이 없는 성능을 얻게 되거나 때에 따라서는 더 느린 성능을 제공할 수도 있다.
이런 상황을 맞닥뜨리게 된다면 NoSQL 도입은 실패로 돌아가고 결국 'NoSQL은 쓸 게 못되는군'이라는 섣부른 결론을 내리게 된다. 이런 상황을 피할 방법은 없는걸까?
관계형 데이터베이스에서 NoSQL로 데이터 저장소를 변경할 때, 가장 먼저 고려해야 할 사항은 일관성 모델이다. 구현된 서비스에 강한 일관성 모델이 필요한지, 느슨한 일관성 모델을 사용해도 큰 문제가 되지 않는지에 대한 판단이 우선되어야 한다. 그렇지 않다면 위와 같은 상황을 만나게 된다. NoSQL을 선택할 때 고려할 사항은 다음과 같다.
일관성 모델
위의 예제에서 살펴본 바와 같이 제공하자고자 하는 서비스에서 어느 정도의 일관성이 필요한지 먼저 확인해야 한다. 강한 일관성이 필요한 서비스를 구현하기 위해서 궁극적 일관성을 지원하는 카산드라를 선택하는 것은 득보다 실이 클 수 있다. 일관성은 데이터 저장 모델과는 크게 상관이 없다.
데이터 모델
제공하려는 기능이 키-값 모델과 같은 간단한 데이터 모델로 처리가 가능한지 또는 문서 모델과 같이 중첩된 구조를 지원해야 하는지 판단해야 하는데, 이 부분은 실제 구현에 따라서 달라질 수 있다. 결론적으로, 선택한 NoSQL의 데이터 모델로 필요한 기능을 구현할 수 있는지에 대해 판단해야 한다.
읽기 쓰기 성능
제공할 기능의 읽기와 쓰기 비율에 따라서 선택할 NoSQL도 바뀌게 된다. 예를 들어 읽기 쓰기 모두에 빠른 응답시간이 필요하다면 인 메모리 NoSQL이 후보가 될 수 있으며, 상대적으로 읽기 비율이 높다면 B트리 인덱스 구조를 사용하는 문서 모델 NoSQL이 후보가 될 수 있다.
단일 고장점
선택한 NoSQL이 단일 고장점을 가지고 있는지 확인하여야 하며, 단일 고장점을 가지고 있더라도 쉬운 복구가 가능한지 확인해야 한다. 예를 들어 HBase는 단일 고장점을 가지고 있지만 하드웨어적인 방법을 통해서 단일 고장점을 제거할 수 있다. 또한 보조 네임 노드를 사용하고 있기 때문에 장애 상황에서 빠른 복구도 가능하다. 무정지 서비스가 중요 목표라면 단일 고장점을 가진 NoSQL 선택을 피해야 한다.
원자성 지원
선택한 NoSQL의 트랜잭션 지원 여부, 단일 연산에 대한 원자성 지원 여부와 같은 CAP 특징을 확인해야 한다. 원자성의 지원이 어느 쪽(서버, 클라이언트)에서 지원되는지 확인하여야 한다. 클라이언트에서 지원하는 단일 연산의 원자성을 코드의 복잡성을 증가시킬 수 있다.
하드웨어 구성
해당 NoSQL이 가지는 시스템 아키텍처를 확인해야 한다. 가용성을 지원하기 위해서 마스터-슬레이브 구조의 NoSQL을 선택했다면 저장되는 데이터의 최대 크기는 절대적인 저장소 크기의 절반이다. 또한 NoSQL 내부의 구성요소와 하드웨어에 대한 기본 구성 정보를 알아야 한다. 예를 들어 HBase는 최소 5대 이상의 하드웨어에서 수행되어야만 성능의 선형 증가를 얻을 수 있다.
무중단 시스템
시스템을 확장할때 시스템 중단이 필요한지 여부와 같은 시스템의 특성을 확인해야 한다. 예를 들면 MongoDB와 같이 자동 샤딩을 지원하는 NoSQL은 운영 중에 시스템을 추가할 수 있지만, 자동 샤딩 중에는 서비스 응답시간이 느려지기도 한다.
위와 같은 고려사항을 확인하여 서비스에서 필요한 부분과 필요없는 부분을 먼저 선택하고 난 뒤 그에 맞는 NoSQL을 선택해야 한다. 즉, 필요한 요구 사항을 모두 만족하는 NoSQL을 선택해야 한다. 일반적으로 NoSQL을 사용한 서비스 구현은 한 가지 NoSQL만을 사용하여 모든 서비스를 제공하도록 구성하지 않는다. 따라서 서비스를 부분으로 나누어 별도의 NoSQL을 배치하고 주 저장소는 관계형 데이터베이스를 사용하기도 한다.
만약 주 서비스에 NoSQL을 도입하는 것이 꺼려진다면 부분적인 도입으로부터 출발하는 것도 좋은 방법이다. 중요도가 낮거나 장애 시 영향도가 낮은 서비스를 대상으로 먼저 적용한다. 이러한 방법은 처음 NoSQL을 도입하는 시험 단계에서 많이 선택된다.
NoSQL에 대한 전체적인 개념과 CAP 이론, NoSQL의 분류에 대하여 살펴봤다. 또한 NoSQL에 대한 이해도를 높이고자 어떻게 실제 서비스에 응용할 수 있는지에 대한 정보를 제공하고, NoSQL에 대한 오해를 예방하기 위하여 알려진 NoSQL 솔루션들의 장단점을 알아보았다.
실제로 많은 사용자가 NoSQL에 대한 오해로 인하여 초기 도입 시에 많은 고통을 겪기도 한다. 주로 NoSQL의 장점만 보고 쉽게 도입을 결정하기 때문인데, 개발 초기에 수많은 시행착오와 생소한 저장 모델에 대한 설계 난이도의 장벽을 넘지 못하는 경우가 왕왕 발생한다. 또한 힘겹게 개발을 완료하여 실제 운영으로 들어간 이후에도 많은 장애 상황을 겪기도 한다.
기본 지식없이 무턱대고 NoSQL을 사용하여 서비스한다면, 안정화까지 매우 많은 시간과 노력이 들게 된다. 이번 장르 제대로 이해한다면 최소한 서비스에 맞지 않는 NoSQL을 선택하는 오류는 피할 수 있을 것이다.
자신의 서비스에 맞는 NoSQL을 선택할 때 비로소 NoSQL의 진가를 알수있게 된다. 많은 사용자들이 NoSQL을 자신의 서비스에 적용하려 한다. NoSQL 신봉자들은 NoSQL은 신기술이며 글로벌 서비스에서 적용된 사례도 충분하기에 다음 세대의 기술이라 생각한다. 또한 NoSQL을 적용하기만 하면 지금까지 겪었던 모든 문제들(스케일 아웃, 높은 가용성, 트래픽 처리를 위한 성능)이 한꺼번에 해결될 거라 믿는다.
하지만 NoSQL은 관계형 데이터베이스의 한계를 극복하고 모든 장점만을 모아둔 솔루션이 아니다. 기존의 관계형 데이터베이스가 제공하는 테이블 조인, 트랜잭션, SQL 문과 같은 편의성을 포기하고 스케일 아웃과 같은 NoSQL의 장점을 얻은 또다른 데이터베이스다. '얻는 것이 있으면 잃는 것도 있다.
참고링크:
https://product.kyobobook.co.kr/detail/S000001057483
이것이 레디스다 | 정경석 - 교보문고
이것이 레디스다 | 『이것이 레디스다』는 NoSQL의 분류에 관한 설명을 포함한다. 데이터 저장구조를 기준으 로 NoSQL을 분류하고 해당 개념을 간단하게나마 정리하여 NoSQL에 대한 기본지식을 익힌
product.kyobobook.co.kr
[Redis] 이것이 레디스다(1) - NoSQL
사용자 증가로 인한 서비스 중단의 원인이 DB 서버일때, 너무 많은 SQL 문 처리 요청을 받아 MySQL이 동시에 처리할 수 있는 한계치를 넘어섰고 그로 인해 응답시간이 길어질 수 있다. MySQL 서버의
12bme.tistory.com
'Redis' 카테고리의 다른 글
| [Redis] 이것이 레디스다(1, 2) - 들어가며 빨리 시작해보기 (0) | 2025.01.02 |
|---|