FullText 검색

LIKE 연산을 통해 검색을 하게 되면 인덱스를 통한 검색이 어려운데 이럴 때 고려해볼 수 있는 것이 Full-Text 검색으로FullText 검색은 단어 또는 구문에 대한 검색을 의미.

MyISAM은 MySQL 5.5 버전 이상부터, innoDB는 MySQL 5.6 버전 부터 지원.

실행 방법

MATCH … AGAINST

전체 텍스트 검색은 MATCH AGAINST 구문을 사용하여 수행.

MATCH (col1,col2,...) AGAINST (expr [search_modifier])

MATCH는 쉼표로 구분되며 검색할 열을 지정하며, AGAINST검색할 문자열과 수행할 검색 방식을 지정

검색 유형 :
{
       IN NATURAL LANGUAGE MODE
     | IN NATURAL LANGUAGE MODE WITH QUERY EXPANSION
     | IN BOOLEAN MODE
     | WITH QUERY EXPANSION
}

FULLTEXT INDEX

MySQL에서 에서 FULLTEXT 타입의 인덱스로 Full-Text 검색을 위해서는 인덱스 설정이 필요한데

데이터 타입이 CHAR, VARCHAR, TEXT 인 경우에만 FULLTEXT INDEX 설정이 가능함.

CREATE FULLTEXT INDEX title ON news (title);

이때, 영어는 잘 검색이 되나 한글은 잘 검색이 안되는 이슈.

이를 위해 MySQL fulltext 검색 알고리즘 중, Ngram 사용.

  • MySQL은 빌트인(내장)된 Ngram parser를 지원하며, 중국어와 일본어 그리고 한글(CJK)를 지원
CREATE FULLTEXT INDEX title ON news (title) WITH PARSER ngram;

Ngram parser

일련의 텍스트를 n개의 문자로 구성된 연속된 시퀀스로 토큰화하여 검색.

ngram 파서의 기본 ngram 토큰 크기는 2(bigram)이며, 한 글자(문자)만 검색하려면 ngram_token_size를 1로 설정이 필요.

ngram_token_size = 1

이 때, ngram 파서를 사용하는 FULLTEXT 인덱스의 경우에는 아래의 구성 옵션이 무시됨.

  • innodb_ft_min_token_size / innodb_ft_max_token_size
  • ft_min_word_len / ft_max_word_len

검색 유형

1. IN NATURAL LANGUAGE 검색

검색 문자열을 단어 단위(token_size)로 분리한 후, 해당 단어 중 하나라도 포함되는 행을 찾음.
자연어 검색은 기본 검색 타입으로 MATCH … AGAINST 구문에 별도의 옵션을 지칭하지 않으면 자연어 검색 모드로 검색됨. (혹은 AGAINST 구문에 IN NATURAL LANGUAGE MODE 입력)

SELECT
  n.seq,
  n.title
FROM 
  news AS n
WHERE 
  MATCH (n.title) AGAINST ('KBO' IN NATURAL LANGUAGE MODE);

매치율

입력된 검색어의 키워드가 얼마나 더 많이 포함되어 있는지에 따라 매치율(유사성 측정값)이 결정 되는데
전체 테이블의 50% 이상의 레코드가 검색된 키워드를 가지고 있는 경우, 그 키워드는 검색어로서 의미가 없다고 판단하고 검색 결과에서 배제됨.

이 때 매치율은 row내의 고유 단어 수, 총 단어 수, 특정 단어를 포함하는 row 수 등을 기준으로 계산되며
검색 결과는 가장 높은 관련성을 가진 결과부터 자동 정렬되는데, 아래와 같은 조건에 한해 자동 정렬.

  • ORDER BY 절이 없어야 함.
  • 검색은 테이블 검색이 아닌 FULLTEXT Index를 사용하여 수행해야 함.
  • 쿼리가 테이블을 조인하는 경우, FULLTEXT Index는 조인에서 가장 왼쪽에 있는 non-constant 테이블이어야 함.

대소문자

기본적으로 검색은 대소문자를 구분하지 않는 방식으로 수행.
대소문자를 구분하는 전체 텍스트 검색을 수행하려면  binary collation을 사용하면됨.

검색어 길이

길이가 기준보다 짧거나, 특정 단어(Stopword)는 풀텍스트 검색에서 무시됨.

최소 인덱싱 글자수 설정

innodb_ft_min_token_size = 1
ft_min_word_len = 1

2. BOOLEAN 검색

불린 모드 검색은 문자열을 단어 단위로 분리한 후, 추가적인 검색 규칙을 적용되어서 단어가 포함되는 행을 찾음.
불린 모드 검색은 IN BOOLEAN MODE를 직접 지정해서 검색할 수 있으며 연산자를 사용하여 검색 조건을 추가 가능함.

SELECT
  n.seq,
  n.title
FROM 
  news AS n
WHERE 
  MATCH (n.title) AGAINST ('KBO' IN BOOLEAN MODE);

연산자

+ : AND, 반드시 포함하는 단어

– : NOT, 반드시 제외하는 단어

> : 포함하며, 검색 순위를 높일 단어

  • +mysql >tutorial
    • mysql과 tutorial가 포함하는 행을 찾을 때, tutorial이 포함되면 검색 랭킹이 높아짐

< : 포함하되,검색 순위를 낮출 단어

  • +mysql <training
    • mysql과 training가 포함하는 행을 찾지만, training이 포함되면 검색 랭킹이 낮아짐

() : 하위 표현식으로 그룹화 (포함, 제외, 순위 지정 등)

  • +mysql +(>tutorial <training)
    • mysql AND tutorial, mysql AND training 이지만, tutorial의 우선순위가 더욱 높게 지정

~ : ‘-‘ 연산자와 비슷하지만 제외 시키지는 않고 검색 조건을 낮춤

* : 와일드 카드로 붙음

“” : 구문 정의

3. with Query Expansion 검색

자연어 검색을 확장한 내용으로, 2단계에 걸쳐서 검색을 수행.

첫 단계에서는 자연어 검색을 수행한 후,
첫 번째 검색의 결과에 매칭된 행을 기반으로 검색 문자열을 재구성하여 두 번째 검색을 수행함.

쿼리 확장 검색은 IN NATURAL LANGUAGE MODE WITH QUERY EXPANSION 혹은 WITH QUERY EXPANSION을 직접 지정해서 사용.

SELECT
  n.seq,
  n.title
FROM 
  news AS n
WHERE 
  MATCH (n.title) AGAINST ('KBO' IN NATURAL LANGUAGE MODE WITH QUERY EXPANSION);

SELECT
  n.seq,
  n.title
FROM 
  news AS n
WHERE 
  MATCH (n.title) AGAINST ('KBO' WITH QUERY EXPANSION);

쿼리 확장 검색은 일반적으로 검색 구문이 아주 짧을 때 유용하며
만약 쿼리 확장을 사용한다면, 두 번째 검색을 할 때 에서 오타로 추측된 단어가 포함된 내용을 찾을 수 있음.

“월드컵” 이라는 검색어가 있을 경우.

자연어 모드에서는 “월”, “드”, “컵” 용어 중 일치하는 게 있으면 출력.

불린 모드에서는 “+월 +드 +컵”로 검색되어 출력.

중지 단어

mysql에서 가지고 있는 중지 단어가 36개 정도 있는데 사용자가 별도의 테이블에 중지 단어를 추가한 후에 적용할 수도 있음.

방법

  • 중지 단어를 저장할 테이블을 만드는데, 컬럼명운 무조건 value 로 지정해야하며 타입은 VARCHAR로 지정.CREATE TABLE stop_word_table (value VARCHAR(50));
  • 그리고 중지 단어를 INSERTINSERT INTO stop_word_table VALUES ('그리고'), ('매우'), ('왜냐하면');
  • 중지 단어 테이블로 사용할 테이블 지정SET GLOBAL innodb_ft_server_stopword_table = 'contents/stop_word_table'; SHOW GLOBAL VARIABLES LIKE 'innodb_ft_server_stopword_table';

중지단어도 검색을 허용하게 할 경우

innodb_ft_enable_stopword = 0

인덱스 추가 후, 다음날 쿼리를 실행시에 예상했던 인덱스를 타지 않는 현상 발생

→ ANALYZE TABLE {table_name}

Reference.

https://dev.mysql.com/doc/refman/8.0/en/fulltext-search.html
https://kabkee.github.io/mysql/mysql-full-text-search/#full-text-search-%EB%8F%84%EC%9E%85-%EA%B2%B0%EC%A0%95
https://cotak.tistory.com/158
https://heowc.dev/2021/06/17/mysql-index-statistics/

DynamoDB

AWS에서 개발한 NoSQL 데이터베이스를 제공하는 서비스입니다.

(Document 모델, Key-Value 모델 모두 지원)

어떤 경우에 사용하면 될까..?

  • 읽기와 쓰기가 매우 빈번하고 처리 속도가 빨라야 하는 환경
  • 작은 용량의 데이터가 매우 많을 때
  • 고가용성(High Availability)의 분산 데이터베이스를 자체 운영하기 부담될 때

장점

  • AWS 생태계에 잘 통합이 되어 있습니다.
  • 완전 관리형 NoSQL 데이터베이스 서비스로 개발자가 분산 데이터베이스를 운영하고 크기 조정하는 데 따른 관리 부담을 줄여줍니다.
  • 용량에 맞게 테이블을 자동으로 확장/축소하는 Auto Scaling 기능을 통해 규모에 상관없이 사실상 무제한의 처리량, 저장 용량을 제공할 수 있습니다. 물론, 백업 및 복원의 기능도 제공을 합니다.

AWS에서 의미하는 완전관리형 서비스란?

AWS에서 모두 관리해주는 것을 말한다. 사용자가 DynamoDB 서비스를 이용하는데 있어서
내부적으로 서버/OS가 있지만 사용자에게는 드러나지 않아(서버리스 서비스) 관리할 서버가 필요 없고,
사용자는 설정만으로 또는 설정하지 않아도 쉽게 백업, 가용성에 대한 부분을 보장 받을 수 있습니다.

단점

  • ORM 지원 라이브러리도 없고, 있다 하더라도 메이저하지도 않아서 쓰기에 불안합니다.
  • 이런 상태에서 분량이 큰 REST API 서비스를 만드는데 있어 체계적인 API가 제공되지 않아 NoSQL쿼리 코드를 관리하는 관리 전략이 필수요소가 될겁니다.
  • 러닝커브

주요 개념

Table

DynamoDB에서도 데이터를 저장할 때 사용하는 테이블이라는 개념은 동일합니다.

Item (항목)

RDBMS(관계형 데이터베이스)에서의 row와 유사한 개념으로 테이블에 Insert, Update, Delete 하게 될 속성들의 집합을 의미합니다.

Attribute (속성)

RDBMS(관계형 데이터베이스)에서의 column과 유사한 개념으로 항목을 구성하는 각각의 데이터들을 의미합니다.

각 테이블에는 0개 이상의 항목이 들어갑니다.

Key를 제외한 테이블의 Attribute들은 미리 정의할 필요가 없습니다. (Key 내용은 아래 참고)

{
    "seq" : 1, // 기본키
    "userId" : 2,
    "userName" : "옙",
    "text" : "안녕하세요.",
    "registerDate" : "2022-05-18",
    "status" : 1,
}

// 각 항목에는 기본키가 있다. 여기서는 seq.
// 기본키(seq)를 제외하면 cheer 테이블에는 별도의 스키마가 없다.
// 이는 항목 내부의 속성이나 데이터 형식을 정할 필요가 없음을 의미하고 속성들은 얼마든지 늘어날 수 있다.
// 이 항목내 속성은 스칼라로서, 하나의 값만 가질 수 있다.

데이터 유형

  • Scalar type : 하나의 값만 표현합니다. 숫자, 문자열, Binary, Boolean, null
  • Document type : 트리 형태로 표현 가능한 중첩된 구조
  • Set type : 집합 (포함된 항목들은 고유해야 한다)
데이터 유형 상세

1. Scalar types

Number

최대 38자리까지 지원합니다. 이 제한을 초과할 시 예외가 발생합니다. DynamoDB에서 숫자는 가변 길이로 표현되며 0으로 시작하거나 끝나면 0은 잘립니다. (정해진 표현 범위를 벗어나는 만큼 0으로 끝나면 잘린다는 뜻으로 이해함.)
숫자형을 사용해 날짜 또는 타임스탬프를 표현할 수 있습니다. (예: 유닉스 시간)

String

문자열은 UTF-8 인코딩을 사용합니다. 문자열 길이는 0을 초과해야 하며, 다른 속성의 크기와 갯수에 따라 400KB의 최대 DynamoDB 항목 크기 제한으로 제약됩니다. 또한, 기본 키가 문자열이라면 다음과 같은 제약이 추가됩니다.
– 파티션 키의 최대 길이는 2KB
– 정렬 키의 최대 길이는 1KB
DynamoDB는 문자 코드 값의 크기로 문자열 비교를 수행합니다. “a”(0x61) 은 “A”(0x45)보다 큽니다.
문자열을 이용해도 날짜 혹은 타임스탬프를 표현할 수 있습니다. (예: ISO 8601)

Binary

실행 파일이나 압축 파일, 이미지와 같은 모든 이진 데이터를 저장하기 위한 타입입니다. 비교시에는 각 바이트를
unsigned char 로 간주한 다음 대소를 비교합니다. 크기는 문자열과 마찬가지로 0 초과, 항목 내 다른 속성의 크기에 따라 최대 400KB 제약을 갖습니다.
바이너리를 기본 키로 사용하는 경우에도 문자열과 같이 파티션 키일 경우 2KB, 정렬 키일 경우 1KB 제약을 갖습니다.
애플리케이션 상에서 바이너리 데이터를 DynamoDB로 보내기 전에는 Base64로 인코딩해야 합니다.

2. Document types

문서 타입에는 List와 Map이 있습니다. 이 둘은 서로 중첩 가능하며, 32단계까지 중첩 가능합니다. 리스트와 맵 안의 값의 갯수는 제한이 없지만 400KB의 항목 크기 제한은 초과하지 않아야 합니다.
속성 값에 빈 문자열이나 공집합은 허용되지 않지만, 빈 리스트나 빈 맵은 허용됩니다.

List

JSON 배열과 유사합니다. 순서가 지정된 값들의 모음입니다. 대괄호[…]로 묶습니다.
저장할 수 있는 데이터 형식에는 제한이 없어 한 리스트에 형식이 다른 요소도 함께 있을 수 있습니다.

Map

JSON 객체와 유사합니다. 정렬되지 않은 Key-value의 모음을 저장할 수 있으며 저장할 수 있는 데이터 형식에는 제한이 없어 한 맵에 형식이 다른 요소도 함께 있을 수 있습니다.
중괄호 {…}로 묶습니다.

3. Set types(집합)

숫자 집합, 문자열 집합, 이진수 집합을 지원합니다. 집합 내 모든 원소의 타입은 동일해야 합니다.
집합 내 값의 수에는 제한이 없지만, 400KB를 초과하지 않아야 합니다.
집합 내 원소들은 유일해야 합니다. 다만, 집합 내 값의 순서는 유지되지 않습니다.

Key (기본키)

테이블에는 항상 기본키가 있어야 합니다.
기본키 구성 방법은 크게 두가지로 나누어집니다.

  • 단일PK – 유니크한 하나의 속성을 Partition Key로 설정하여 Primary Key로 사용하는 방법으로 동일한 Partition Key를 가진 Item이 중복될 수 없음. (ex. user_id, contents_id)
  • 복합PK – 첫번째 속성은 Partition Key로 설정, 두번째 속성은 Sorting Key로 설정하여 조합해서 Primary Key로 사용하는 방법
    • 동일한 Partition Key 해시값으로 동일 영역에 같이 저장되지만 Sort Key로 분류된다.
    • 복수의 Item은 동일한 Partition Key 가능하나 Sort Key는 달라야 한다.
    • 활용: 동일한 userid를 가진 사용자가 복수의 글을 업로드 (user id + posting date)

Partition Key (파티션 키)

테이블을 생성할 때 필수적으로 설정을 해야하는 기본 키입니다.
하나의 Attribute로 구성되며 스칼라 데이터 형식만 가능합니다.
일치(Equal) 방식 검색만 지원합니다.(검색시, 정확히 일치하는 것만 조회)

Sorting Key (정렬 키)

테이블을 생성할 때 선택적으로 설정할 수 있는 기본 키입니다.
정렬 키는 동일한 파티션 키를 가진 데이터를 정렬할 때 쓰입니다.
범위를 지정할 수 있는 검색을 지원하는데 즉, between, >, <등 연산자를 사용하는 범위 쿼리를 사용하여 관련 항목의 필요한 그룹을 검색가능합니다.

파티션 키와 정렬 키는 기본 키임으로 생략할 수 없고, 또한 변경을 할 수 없어 주의가 필요합니다.

Secondary Index (보조 인덱스)

테이블에서 하나 이상의 보조 인덱스를 생성할 수 있습니다.

기본키에 대한 쿼리 및 대체키를 사용하여 데이터에 대한 쿼리를 실행할 수 있으며 보조 인덱스를 생성한 후에는 인덱스로 데이터를 읽을 수 있습니다.

하나의 key만으로는 다양한 어플리케이션의 요구사항을 만족시키기 어렵기 때문에 대부분 secondary index를 생성하여 사용합니다. (key는 string, number, binary중 하나여야합니다.)

Local Secondary Index (로컬 보조 인덱스)

  • 베이스 테이블과 동일한 파티션 키를 사용하지만 다른 정렬 키를 사용합니다.
  • 베이스 테이블 생성 시 지정. 이후에 추가, 삭제, 변경 불가능합니다.
  • 테이블당 최대 5개의 로컬 보조 인덱스 설정 가능하며, 하나의 파티션키 당 Index된 데이터는 10GB 미만이어야 합니다.

Global Secondary Index (글로벌 보조 인덱스)

  • 파티션키와 정렬키가 베이스 테이블의 key들과 달라도 됩니다.
  • 테이블 생성 시 지정. 이후에도 언제든지 생성, 삭제 가능합니다.
  • 테이블당 최대 20개까지 생성 가능하며, 하나의 파티션키 당 Index된 데이터는 제한이 없습니다.

Auto Scaling

실제 트래픽 패턴에 따라 사용자 대신 동적으로 조정합니다. 따라서 테이블 또는 글로벌 보조 인덱스에 따라 할당된 읽기 및 쓰기 용량을 늘려 병목 현상 없이 갑작스러운 트래픽 증가를 처리할 수 있습니다.
워크로드가 감소할 경우 사용하지 않는 용량에 대한 요금을 지불하지 않도록 처리량을 줄일 수 있습니다.

  • 테이블 생성시, Auto Scaling 활성화 여부에 대한 설정이 가능합니다.
  • 이미 생성된 테이블이라면, AWS Management Console을 사용하여 수정가능합니다.

Auto Scaling 프로세스

  1. 사용자가 DynamoDB 테이블에 대한 Application Auto Scaling 정책을 설정합니다.
  2. DynamoDB는 Amazon CloudWatch에 소비된 용량 지표를 게시합니다.
  3. 테이블에서 사용한 용량이 특정 기간의 목표 사용률을 초과하는 경우(또는 목표에 미달하는 경우), Amazon CloudWatch는 경보를 트리거합니다. 콘솔에서 이 경보를 확인하고 Amazon Simple Notification Service(Amazon SNS)를 사용하여 알림을 받을 수 있습니다.
  4. CloudWatch 경보를 받으면 크기 조정 정책을 평가하기 위해 Application Auto Scaling이 호출됩니다.
  5. Application Auto Scaling은 UpdateTable 요청을 실행하여 테이블의 할당된 처리량을 조정합니다.
  6. DynamoDB는 UpdateTable 요청을 처리하고 해당 테이블의 할당된 처리 용량을 동적으로 늘리거나 줄임으로써 목표 사용률에 근접하게 합니다.

TTL

데이터 유효기간을 의미하며 테이블 설정시 간단하게 설정 가능합니다.
데이터 삭제를 위한 연산 비용은 없으나 TTL 사용을 위해 부가적으로 사용된 데이터 저장 공간 비용은 청구됩니다.
TTL 시간은 최대 5년을 넘길 수 없습니다.

사용 방법

TTL을 표기할 Attribute(속성) 이름을 정의하고, 아이템 저장 시 해당 Attribute(속성)에 만료 기간을 함께 저장하면 됩니다.
TTL Attribute(속성)는 Number타입이어야 하며, 초 단위의 유닉스-타임(Unix-time)으로 만료 기간을 표시해야 한다.

동작 방식

DynamoDB는 TTL을 위해 파티션 별 2개의 백그라운드-프로세스를 운영한다.
첫번째 프로세스는 테이블을 스캔하며 현재 시간과 만료 기간 비교하여, 만료된 아이템을 표시한다.
두번째 프로세스는 테이블을 스캔하며 첫번째 프로세스가 표시한 만료된 아이템을 찾아 삭제한다.

다만, 유의할 점이 있다!!

  • TTL 만료 데이터 삭제 시점
    위에 동작 방식으로, 유저가 정의한 TTL 설정 시간과 실제 데이터가 삭제되는 시간 사이에는 간격이 발생할 수 있다.
    그리고 이러한 간격은 테이블 파티션의 크기와 파티션에서 사용한 연산양에 비례하여 커질 것이다. (TTL도 파티션에 할당된 제한된 자원을 사용하여 동작하기 때문)
    이러한 시간 간격은 최대 48시간까지 발생할 수 있다고 AWS는 정의하고 있다.
  • 만료된 아이템의 읽기 쓰기
    만료된 데이터는 최대 48시간까지 지연되어 삭제될 수 있는데 이 뜻은 유저가 만료된 데이터에 여전히 읽기, 쓰기 연산을 적용할 수 있음을 의미한다.
    즉, TTL만 믿으면 안되고 올바른 데이터 조회 및 처리를 위해서는 반드시 현재 시간 기준으로 만료된 시간을 계산하고 필터 조건을 포함하여야 한다.
    필터가 없다면 데이터 조회 시 만료된 데이터가 함께 조회되는 낭패를 볼 수 있다.
    또한, 이미 만료된 데이터에 TTL 어트리뷰트를 업데이트하여 연장하거나 TTL 어트리뷰트를 삭제하여 TTL을 비활성화 할 수도 있다.

테이블 구조 설계 간단하게, 클라이언트 툴, 읽기 모드에 대한 상황 판단

Reference

RDBMS vs NoSQL

RDBMS (관계형 데이터베이스 관리 시스템)

– 테이블 마다 스키마를 정의해야 함.
– 데이터 타입과 제약을 통해서 데이터의 정확성을 보장함.
– 데이터를 Column 과 Row 형태로 저장.
– SQL이라는 RDBMS의 데이터를 관리하기 위해 설계된 프로그래밍 언어를 사용한 질의문을 통해
데이터를 다룰 수 있음.
– 데이터의 update가 빠름.
– 데이터 처리에 대한 부하 발생시, 처리가 어려움.
– 성능을 높이려면 하드웨어를 고성능으로 교체해야 함.
(고성능 하드웨어는 가격이 비싸, RDBMS의 성능을 높이거나 확장하기 어려움)
– 하나의 정보를 만들기 위해 여러 테이블로 쿼리를 사용하게 되며 그렇기 때문에 트랜잭션 처리를 중요시 함.

NoSQL

– RDB의 확장성 이슈를 해결하기 위해 나온 데이터베이스 모델임.
– 분산 컴퓨팅 활용이 목적으로 비교적 저렴한 가격에 DB 성능을 높일 수 있음.
– 데이터간의 관계를 정의하지 않으며, join이 불필요.
– 테이블에 스키마가 정해져 있지 않아 데이터 저장이 비교적 자유로우며
데이터의 구조가 같지 않아도 영향을 미치지 않음.
– key-value 방식으로 데이터를 관리하며, SQL을 사용하지 않음.
– 많은 양의 데이터를 저장, 처리 할 수 있음.
– 스키마가 정해져 있지 않아 구조 변경이 용이하고 데이터 형식이 다양하며 바꾸기 쉬워
정확성보다는 데이터 양이 중요한 빅데이터에 주로 사용함.
– 데이터의 update가 비교적 느림.
– 데이터 모델로는 도큐먼트 모델, 그래프 모델, 키/값 모델, 와이드 컬럼 모델이 있음.

In-Memory DB

NoSQL 방식에 속하는 데이터베이스로 key-value 방식을 사용하고 있음.

– Memory의 가격이 용량 대비, 충분히 낮아지면서 빠른 데이터베이스 성능을 위해서 등장함.
– 디스트(Disk) 대신 메모리(Memory)를 사용함으로써, I/O(input/output)의 성능을 높여줌.
– 대표적으로 Redis가 있음.

RDB vs NoSQL

– RDB는 관계형으로 데이터를 저장하지만, NoSQL은 그렇지 않다.
– RDB는 스키마가 정적이지만, NoSQL은 유연한 스키마 구조를 갖는다.
– RDB는 수직 확장이 용이하고, NoSQL은 수평 확장이 용이하다.
(즉, RDB는 서버 용량을 늘리는 게 쉽고, NoSQL은 서버를 여러 대 늘리는 게 쉽다)
– 위와 관련해서, RDB는 확장 시 다운타임이 있을 수 있지만, NoSQL은 거의 없다.
– RDB는 복잡한 쿼리와 Join 연산이 가능하다. NoSQL은 구조화된 쿼리 언어가 없는 경우도 많고, 일반적으로 Join이 없다.
– RDB는 OLTP에 적합하고, NoSQL은 OLAP에 적합하다.
(즉, RDB는 트랜잭션 처리에 용이하고, NoSQL은 분석 처리에 용이하다)

* OLTP
직역하면 온라인 트랜잭션 처리를 의미.
복잡하게 말하면 복수의 사용자 PC에서 발생되는 트랜잭션(Transaction)을 DB서버가 처리하고, 그 결과를 요청한 사용자PC에 결과값을 되돌려주는 과정을 뜻함.

즉, 1개의 트랜잭션에서 발생되는 INSERT, UPDATE, DELETE의 과정을 무결성을 보장하여 처리하고 그 결과를 SELECT 하는 과정을 말함.

* OLAP
데이터웨어하우스(DW), 쉽게 말해 DB에 저장되어 있는 데이터를 분석하고, 데이터 분석을 통해 사용자에게 유의미한 정보를 제공해주는 처리방법을 의미.

즉, 기존에 저장되어 있는 데이터를 사용자의 요구와 목적에 맞게 분석하여 정보를 제공하는 개념을 의미.

* OLTP vs OLAP
OLTP는 현재의 데이터 처리가 얼마나 정확하고, 무결한지가 중요.
그렇기 때문에 주로 데이터의 저장, 삭제, 수정 등의 실질적인 데이터를 수정하는 작업을 의미하는 용어.

OLAP는 이미 저장된 데이터를 바탕으로 어떤 정보를 제공하는지가 중요.
따라서 OLAP는 데이터가 무결하고, 정확하다는 전재를 바탕으로 고객 또는 사용자가 원하는 정보를 어떤식으로 표현하고 제공하는지를 의미하는 용어.