우당탕탕 히온이네

네이글 알고리즘이란?

Nagle 알고리즘은 네트워크를 통해 보내야 하는 패킷 수를 줄여 TCP/IP 네트워크의 효율성을 향상시키는 수단입니다. Nagle 알고리즘은 여러개의 작은 발신 메시지를 결합하여 한 번에 보내는 방식으로 작동합니다. 승인 받지 못한 송신 packet이 있는 한 송신자는 packet 버퍼가 가득 찰 때까지 버퍼링을 유지함에 따라 결과를 한번에 모두 보낼 수 있습니다. 

TCP 의 통신 방식은 흔히 알고 있는 3-Way Handshake 방식입니다. 즉, 요청을 위한 ACK, 응답을 위한 SYN+ACK, 응답에 대한 응답을 위한 ACK 패킷이 있습니다.

가령, "Hello World" 라는 메시지를 전송해야한다고 가정해봅시다. 어플리케이션이 몇가지 이슈로 인해 H, e, l, l, o, , W, o, r, l, d 와 같이 메시지를 끊어서 보내야한다고 할 때, 이는 TCP 통신에 있어서 커다란 비효율이 됩니다.

TCP 통신을 위해 3-Way handshake 를 거쳐야 하며 이 때 발생하는 주요 문제점은 단순한 메시지의 전달에 대해서도 네트워크 비용이 막대하게 발생한다는 점입니다. 메시지 하나하나의 처리량과 반응속도는 높아질 지언정 전체 "Hello World" 메시지를 통신하기 위해서는 글자수만큼의 네트워크 비용을 소모하게 됩니다.

더군다나 매 통신 시, 컴퓨터는 메시지에 별도의 헤더 등과 같은 추가 정보들을 추가하며 이는 동일한 정보더라도 한 패킷의 사이즈가 커지는 결과를 만들어냅니다. 즉, 하나의 메시지 H 를 보내는데 메시지보다 헤더의 데이터가 더 큰 비효율이 발생할 수 있습니다.

Nagle's Document 에 따라 이러한 문제는 Small Packet Problem 으로 정의되며 Nagle 알고리즘은 이 문제를 해결하는 방법을 제시합니다. Nagle Algorithm 은 송신에 있어서 버퍼를 둔 뒤 상대방 Host 의 Window 사이즈를 고려한 후, 어느정도 길이만큼의 패킷을 한번에 전송하는 기술입니다. 

알고리즘

1. 상대방이 받을 수 있는 사이즈(window size)와 전송해야할 데이터가 MSS(최대 세그먼트 크기) 보다 크다면 문제없이 바로 전송

윈도우 사이즈 : 현재 승인되지 않고 허용되는 윈도우 (TCP가 승인없이 전달할 수 있는 사이즈)

MSS : 최대 세그먼트 크기, 연결에서 전송할 수 있는 가장 큰 세그먼트

2. 위 조건에 해당하지 않는다면 전송한 모든 패킷이 승인 될 때까지 버퍼에 모음 (Nagle On)

3. 모든 패킷이 승인되었다면 패킷을 전송

기존의 네트워크 환경에서는 데이터가 버퍼에 조금씩 쌓이게 되면, Nagle off의 그림처럼 상대방의 ACK를 기다리지 않고 바로바로 작은 패킷을 전송하게 되는 반면, 네이글은 이런 작은 패킷을 가능한 지연시키기 위하여, ACK가 올때까지 전송을 중지하고 ACK가 도착한 시점에, 지금까지 버퍼에 모인 데이터를 패킷으로 만들어서 전송합니다.

ACK를 기다리는 지연방식으로 네이글은 작은 패킷을 연속해서 보내는 네트워크의 비효율을 극복하였습니다. 하지만 이런 지연방식을 사용하면 위 그림처럼 같은 기준시간에 데이터 전송속도가 더 늦게 됩니다.

네트워크 게임에서 네이글 알고리즘

게임은 반응성을 중요시합니다. 온라인 게임의 네트워크 상황에서 클라이언트의 경우 서버로 유저의 입력을 전송합니다. 이 입력신호의 경우 데이터 양 자체가 작고, 또 반복적으로 여러 입력이 요청될 수 있기 때문에, 네이글 알고리즘이 작동되기 쉽습니다. 이 입력 패킷이 크기가 작다는 이유로 지연된다면, 사용자의 반응성에 큰 영향을 미치게됩니다. 입력 패킷은 크기는 작아도 게임에 있어 그 의미는 매우 크고 어느정도의 트래픽 효율을 포기하더라도 빠른 반응성을 얻는것이 유저 입장에서도 좋은 거래가 될 것입니다. 따라서 클라이언트 네트워크의 경우에는 네이글 알고리즘을 사용하지 않는 것이 유리하다고 생각합니다.

서버의 경우는 클라이언트와 다릅니다. 서버는 클라이언트에게 현제 유저가 처한 게임 상황의 결과를 지속적으로 보내줄 것이고, 이 정보는 패킷 크기에 비해 헤더 크기가 비대해 보이지 않을 정도로 충분히 큰 양의 데이터일 것이며, 지속적으로 갱신해서 보내주는 데이터가 될 것입니다. 이러한 데이터가 네이글 알고리즘에 의해 지연되는 경우는 클라이언트의 가용 윈도우 사이즈가 충분히 크지 않은 경우가 될 것입니다. 클라이언트의 처리 능력이 원활하지 않은 경우 계속해서 데이터를 잘라서 욱여넣는것이 유저가 체감하는 반응성에 큰 영향을 미칠 것이라 생각하지 않고, 또한 동시에 여러 클라이언트가 사용하는 서버에서 트래픽이슈는 민감한 부분이기 때문에, 네이글 알고리즘을 사용했을때 얻는 이득이 더 클 수 있습니다.

프로세스 간 메시지를 전송하거나, 공유메모리를 통해 공유된 자원에 여러 개의 프로세스가 동시에 접근하면 Critical Section(여러 프로세스가 데이터를 공유하며 수행될 때, 각 프로세스에서 공유 데이터를 접근하는 프로그램 코드 블록) 문제가 발생할 수 있다. 이를 해결하기 위해 데이터를 한 번에 하나의 프로세스만 접근할 수 있도록 제한을 두는 동기화 방식을 취해야 한다. 동기화 도구에는 대표적으로 뮤텍스(Mutex)와 세마포어(Semaphore)가 있다. 이들은 모두 공유된 자원의 데이터를 여러 스레드/프로세스가 접근하는 것을 막는 역할을 한다.

Mutex 뮤텍스

: 공유된 자원의 데이터 혹은 임계영역(Critical Section) 등에 하나의 Process 혹은 Thread가 접근하는 것을 막아줌 (동기화 대상이 하나)

임계구역(Critical Section)을 가진 스레드들의 실행시간(Running Time)이 서로 겹치지 않고 각각 단독으로 실행(상호배제_Mutual Exclusion)되도록 하는 기술입니다.

한 프로세스에 의해 소유될 수 있는 Key를 기반으로 한 상호배제 기법이고 Key에 해당하는 어떤 객체(Object)가 있으며, 이 객체를 소유한 스레드/프로세스만이 공유자원에 접근할 수 있습니다.
다중 프로세스들의 공유 리소스에 대한 접근을 조율하기 위해 동기화(Synchronization) 또는 락(Lock)을 사용함으로써 뮤텍스 객체를 두 스레드가 동시에 사용할 수 없습니다.

뮤텍스는 화장실이 하나 밖에 없는 식당과 비슷합니다. 화장실을 가기 위해서는 카운터에서 열쇠를 받아 가야 하며 당신이 화장실을 가려고 하는데 카운터에 키가 있으면 화장실에 사람이 없다는 뜻이고 당신은 그 열쇠를 이용해 화장실에 들어갈 수 있다고 가정합니다.

카운터에 열쇠가 없기 때문에 화장실에 사람이 있다는 뜻이며 화장실을 사용할 수 없습니다. 여자가 나올 때 까지 기다려야 합니다.

곧이어 다른 사람도 화장실에 가려고 카운터에 대기하고 있습니다. 앞사람이 화장실에서 나와 카운터에 키를 돌려놓았습니다. 이제 기다리던 사람들 중 맨 앞에 있던 사람이 키를 받아 화장실에 갈 수 있습니다.

이것이 뮤텍스가 동작하는 방식입니다. 화장실을 이용하는 사람은 프로세스 혹은 쓰레드이며 화장실은 공유자원, 화장실 키는 공유자원에 접근하기 위해 필요한 어떤 오브젝트입니다. 즉, 뮤텍스는 Key에 해당하는 어떤 오브젝트가 있으며 이 오브젝트를 소유한 (쓰레드,프로세스) 만이 공유자원에 접근할 수 있습니다.

Semaphore 세마포어

: 공유된 자원의 데이터 혹은 임계영역(Critical Section) 등에 여러 Process 혹은 Thread가 접근하는 것을 막아줌 (동기화 대상이 하나 이상)

사용하고 있는 스레드/프로세스의 수를 공통으로 관리하는 하나의 값을 이용해 상호배제를 달성합니다. 공유 자원에 접근할 수 있는 프로세스의 최대 허용치만큼 동시에 사용자가 접근할 수 있으며, 각 프로세스는 세마포어의 값을 확인하고 변경할 수 있습니다.
자원을 사용하지 않는 상태가 될 때, 대기하던 프로세스가 즉시 자원을 사용하고. 이미 다른 프로세스에 의해 사용중이라는 사실을 알게 되면, 재시도 전에 일정시간 대기해야 합니다.
일반적으로 비교적 긴 시간을 확보하는 리소스에 대해 사용하게 됩니다.

세마포어는 손님이 화장실을 좀 더 쉽게 이용할 수 있는 레스토랑입니다. 세마포어를 이용하는 레스토랑의 화장실에는 여러 개의 칸이 있고 화장실 입구에는 현재 화장실의 빈 칸 개수를 보여주는 전광판이 있다고 가정합니다.

만약 당신이 화장실에 가고 싶다면 입구에서 빈 칸의 개수를 확인하고 빈 칸이 1개 이상이라면 빈칸의 개수를 하나 뺀 다음에 화장실로 입장해야 하며 나올 때 빈 칸의 개수를 하나 더해줍니다.

모든 칸에 사람이 들어갔을 경우 빈 칸의 개수는 0이 되며 이때 화장실에 들어가고자 하는 사람이 있다면 빈 칸의 개수가 1 혹은 양수로 바뀔 때까지 기다려야 합니다.

이처럼 세마포어는 공통으로 관리하는 하나의 값을 이용해 상호배제를 달성합니다. 세마포어도 아까와 똑같이 화장실이 공유자원이며 사람들이 쓰레드, 프로세스이다. 그리고 화장실 빈칸의 개수는 현재 공유자원에 접근할 수 있는 쓰레드,프로세스의 개수를 나타냅니다.

차이점

가장 큰 차이점은 동기화 대상의 개수 즉, 위에서 예시든 화장실의 갯수 입니다.

• Mutex는 동기화 대상이 오직 1개일 때 사용하며, Semaphore는 동기화 대상이 1개 이상일 때 사용합니다.
• Mutex는 자원을 소유할 수 있고, 책임을 가지는 반면 Semaphore는 자원 소유가 불가합니다.
• Mutex는 상태가 0, 1 뿐이므로 Lock을 가질 수 있고, 소유하고 있는 스레드만이 이 Mutex를 해제할 수 있습니다. 반면 Semaphore는 Semaphore를 소유하지 않는 스레드가 Semaphore를 해제할 수 있습니다.
• Semaphore는 시스템 범위에 걸쳐 있고, 파일 시스템 상의 파일로 존재합니다. 반면, Mutex는 프로세스의 범위를 가지며 프로세스 종료될 때 자동으로 Clean up 됩니다.

뮤텍스와 세마포어는 모두 완벽한 기법은 아니므로 데이터 무결성을 보장할 수는 없으며 모든 교착상태를 해결하지는 못합니다. 하지만 상호배제를 위한 기본적인 문법이며 여기에 좀 더 복잡한 매커니즘을 적용해 개선된 성능을 가질 수 있도록 하는 것이 중요합니다.

IPC란?

Inter Process Communication 의 약자로 프로세스간 통신을 말합니다.

위 그림처럼 프로세스는 완전히 독립된 실행객체로써 다른 프로세스의 영향을 받지 않습니다. 독립되어 있는 만큼 별도의 설비가 없이 서로간의 통신이 어려워, 커널 영역에서 IPC라는 내부 프로세스 간 통신을 제공하여 프로세스는 커널이 제공하는 IPC설비를 이용해서 프로세스 간 통신을 가능하게 합니다. 

IPC 설비들

상황에 맞는 IPC의 선택은, 특히 fork()를 이용해서 만들어진 멀티 프로세스의 프로그램에 있어서 중요합니다. 잘못된 IPC 설비의 선택은 코딩과정을 어렵게 만들거나 프로그램의 작동을 효율적이지 못하게 만들 수 있습니다. 이러한 설비 종류로는 PIPE, Named PIPE, Message Queue, Shared Memory, Memory Map, Socket 등이 있습니다. 

1. PIPE

익명의 PIPE를 통해서 동일한 부모 프로세스를 가진 프로세스들 간에 단방향 통신을 지원합니다.

FIFO 구조이며 생성된 PIPE에 대하여 Write 또는 Read 만 가능하게 됩니다.

부모-자식 프로세스간 통신할 때 사용하게 됩니다.

쌍방통신을 위해서는 Write용 PIPE하나 Read PIPE하나를 따로 만들어야 합니다. read()와 write()가 기본적으로 block 모드로 작동하기 때문에 프로세스가 read가 대기중이라면 read가 끝나기 전에는 write를 할 수가 없게 됩니다.

2. Named PIPE

이름을 가진 PIPE를 통해서 프로세스들 간에 단방향 통신을 지원하며 서로 다른 프로세스들이 PIPE 이름만 알면 통신이 가능합니다.

익명의 PIPE와 마찬가지로 FIFO 구조이며 생성된 PIPE에 대하여 Write 또는 Read 만 가능하게 됩니다.

전혀 다른 모든 프로세스들 사이에서 통신이 가능한데 그 이유는 프로세스 통신을 위해 이름이 있는 파일을 사용하기 때문입니다. Named PIPE의 생성은 mkfifo를 통해 이뤄지는데, mkfifo가 성공하면 명명된 파일이 생성됩니다.

마찬가지로 쌍방 통신을 위해서는 Write용 PIPE하나 Read PIPE 하나를 따로 만들어야 합니다. read()와 write()가 기본적으로 block 모드로 작동하기 때문에 프로세스가 read대기중이라면 read가 끝나기 전에는 write를 할수가 없게 됩니다.

3. Message Queue

파이프가 아닌 어디에서나 물건을 꺼낼 수 있는 컨베이너 벨트와 유사하며 컨베이너 벨트에 올라올 물건에 라벨을 붙이면 동시에 다양한 물건을 다룰 수 있는 것과 같이 큐에 쓸 데이터에 번호를 붙임으로써 여러 개의 프로세스가 동시에 데이터를 쉽게 다룰 수 있습니다.

입출력 방식으로는 익명 PIPE와 동일하지만, 커널에서 관리하며 메모리를 사용한 PIPE 입니다. 구조체 기반으로 통신을 합니다.

FIFO 구조이며, msgtype에 따라 다른 구조체를 가져올 수 있습니다.

프로세스간 다양한 통신을 할 때 사용할 수 있습니다.

커널에서 제공하는 Message queue 이기 때문에 EnQueue 하는데 제한이 존재합니다.

4. Shared Memory

위 설비들과는 다르게 공유메모리가 데이터 자체를 공유하도록 지원하는 설비입니다. 

프로세스는 자신만의 메모리 영역을 가지고 있고 다른 프로세스가 접근해서 함부로 데이터를 읽거나 쓰지 못하도록 커널에 의해서 보호되지만 메모리 영역에 있는 데이터를 다른 프로세스도 사용할 수 있도록 해야할 경우도 필요합니다. 위 설비들과 같이 PIPE 등을 이용해서 데이터 통신을 이용하여 데이터를 전달하는 방법도 있겠지만, Thread에서 처럼 메모리 영역을 공유한다면 더 편하게 데이터를 함께 사용할 수 있습니다. 

프로세스가 공유 메모리 할당을 커널에 요청하면 커널은 해당 프로세스에 메모리 공간을 할당해줍니다. 이후 어떤 프로세스건 해당 메모리영역에 접근할 수 있습니다.

공유메모리는 중개자가 없이 곧바로 메모리에 접근할 수 있기 때문에 다른 모든 IPC들 중에서 가장 빠르게 작동할 수 있다. 단순히 공유 메모리를 point 함으로써 프로세스에서 사용되는 메모리가 증가되지 않습니다.

프로세스간의 Read, Write 를 모두 필요로 할 때 사용하게 됩니다. 

5. Memory Map

운영체제에서 파일을 다루는 방법 중 하나로써 Memory Map도 Shared Memory 공간과 마찬가지로 메모리를 공유한다는 측면에 있어서는 서로 비슷한 측면이 있습니다. 차이점은 Memory Map의 경우 열린파일을 메모리에 맵핑시켜서, 공유한다는 점입니다.  프로세스의 가상 메모리 주소 공간에 파일을 매핑한 뒤 가상 메모리 주소에 직접 접근하는 것으로 파일 읽기/쓰기를 대신합니다.

운영체제에서 페이징 기법을 사용하여 파일의 내용을 관리하며 페이지 크기에 따라 적절히 파일의 내용을 읽고 쓸 수 있습니다.

파일로 대용량 데이터를 공유할 때 사용되며, 대부분 운영 체제에서는 프로세스를 실행할 때 실행 파일의 각 세그먼트를 메모리에 사상하기 위해 메모리 맵 파일을 이용합니다. 

6. Socket

같은 도메인 내에서 연결될 수 있고 프로세스들 사이의 통신을 가능하게 합니다. 서버단에서는 bind, listen, accept를 진행해 소켓 연결을 위한 준비를 합니다. 클라이언트 단에서는 connect를 통해 서버에 요청하고 연결이 수립된 후에는 socket에 send 함으로써 데이터를 주고 받습니다. 연결이 끝난 후에는 반드시 Socket 을 close()해주어야 합니다. 

범용적인 IPC로써 양방향 통신이 가능하며 패킷 단위로 주고 받음으로 직관적으로 이해하기 쉬운 코드를 만들 수 있습니다.

요약

MongoDB의 구조 순으로 (database, collection, document) 데이터 입력에 관한 간단한 쿼리문을 정리하고 collection에서 종류에 따른 쿼리문을 정리하였습니다.

Database 쿼리문

Collection의 기본쿼리

Capped Collection 쿼리

Time Series Collection 쿼리

Document 쿼리

문제

두 가지 방법으로 풀이를 하였다

1. 배열과 scanner 쓰기

2. 배열과 BufferedReader 쓰기

풀이(1)

• int[] arr = new int[n];  -> 배열선언과 크기확장 동시에

풀이(2)

scanner로 읽어 들이는 방식이 시간이 오래걸린다 해서 BufferedReader로 읽어들여오는 코드를 짜봄

• StringTokenizer클래스로 string형식으로 문자를 읽어들임
• 개행문자가 나올 때 까지 토큰을 계속 넣어줌 이때, 읽은 토큰은 string형이기 때문에 int형으로 Integer.parseInt로 형변환 시켜줌

처음엔 방정식으로 해의 쌍으로 풀으려 했는데 경우의 수가 너무 많이 나누어짐,,

거스름돈(?) 문제랑 같은 알고리즘인거 같다

작은거를 기준으로 계속 빼주면서 큰거로 나누어지면 출력, 안나눠지면 -1 출력하기

낼 수 있는게 두가지라 간단하지만 세가지 네가지면..? 

PostgreSQL 설치방법은 구글 여러곳에 잘 나와 있다

PostgreSQL 설치오류

대충 이런식의 오류가 계속 떴다. 홈페이지에 나와있는 모든 버전을 설치해봐도 동일한 오류가 떴다.

구글에 설치오류를 검색하고 나와있는 모든 방법을 썼지만 여전히 내 노트북은 오류발생,,,, (또 나만 왕따지,,,,,,,)

• cmd 명령어를 이용한 설치

- postgresql 설치 경로에서 --install_runtimes 0 옵션을 주어 설치하는 방법이지만 여전히 난 에러

• 다른 설치파일로 설치

다들 여기서 성공하셨다는데 , 여긴 아예 다운로드 창이 들어가지지 않았다.

해결

결국 이 사이트에서 나온 방법으로 해결할 수 있었다 ㅜㅜ !

위에 나와 있는거처럼 Administrator account를 활성화 시켜줘야 된다 뭐 이런 얘기 !

cmd 이용해서 Administrator account  활성화 시켜주기

1. 우선 cmd 창을 킨다.

2. D:\>net user administrator /active:yes   를 입력하여 administrator account를 활성화 시켜준다.

3. D:\>net user administrator *    를 입력하여 암호를 설정해준다. 두 번 입력하라고 나온다.

4. D:\>runas /user:administrator postgresql-14.0-1-windows-x64.exe        자신이 다운받은 파일명을 넣고, 위에 설정한 암호 넣어주면 끝!

이렇게 해서 성공했당 그 후엔 설치경로를 지정해 주는 단계가 있는데 기본 값 그대로 냅두면 된다.. 나는 여기서 또 만져서 헤맸당,,^^ 

뭐 설정하고 이런 다음 단계들은 구글에 검색하면 잘 나와있으므로 잘 보고 따라하면 끝 ! 

Time Series Date 시계열 데이터

: 시간에 따라 저장된 데이터

동일한 소스로부터 시간이 지남에 따라 만들어진 데이터들로 구성되므로 시간 경과에 따른 변화를 추적하는데 용이하다. 최근 2년 동안 Time Series 데이터베이스가 엄청난 속도로 증가하고 있다. TimeSeries DB에 대한 관심이 증가하는 이유는 빅데이터의 시대에 대용량의 데이터를 빠르게 처리하기에 적합하기 때문이다.

특징

1. 시간을 기반으로 하는 저장 공간

시계열 데이터베이스는 기존의 다른 데이터베이스들과 차별이 되는 핵심적인 아키텍처 디자인 특징이 있는데, 그것은 바로 time-stamp를 기반으로 하는 저장소를 가지고 있다는 것이다. 이를 통해 데이터를 압축하고 요약하는 등의 작업을 진행하여 대규모의 시간 기반 데이터들을 다룰 수 있고, 시간을 기반으로 하는 쿼리를 가능하게 한다.

2. 빠른 처리 속도

TSDB는 빠르고 효율적인 방법으로 데이터를 수집하기 위해 만들어졌다. 물론 RDB도 빠르지만 데이터의 양이 증가함에 따라 성능이 급격하게 느려지는 경향이 있다. 반면에 TSDB에서의 인덱스는 시간에 따라 축적된 데이터들에 최적화되었기 때문에, 시간이 지나도 데이터를 수집하는 속도가 느려지지 않고 빠른 처리 속도를 보여준다.

3. 다양한 자동화된 기능 제공

TSDB에는 시간에 따라 변화되는 데이터들을 저장하므로 데이터의 양이 상당히 많으며, 시간에 따른 데이터의 요약 또는 통계 등과 같은 작업이 흔히 요구된다. TSDB는 특정 주기마다 자동으로 데이터들을 처리하는 기능(InfluxDB의 Continous Query, 연속적인 쿼리)이나 오래된 데이터를 자동으로 삭제하도록 도와주는 기능(InfluxDB의 Retention Policy, 보존 정책) 등을 제공함으로써 편리성을 제공하고 있다.

NoSQL (Not Only SQL)

: 기존 관계형 DBMS가 갖고 있는 특성뿐만 아니라 다른 특성들을 부가적으로 지원함

2000년 후반으로 넘어오면서 인터넷이 활성화되고, 소셜네트워크 서비스 등이 등장하면서 관계형 데이터 또는 정형데이터가 아닌 데이터, 즉 비정형데이터라는 것을 보다 쉽게 담아서 저장하고 처리할 수 있는 구조를 가진 데이터 베이스들이 관심을 받게 되었고, 해당 기술이 점점 더 발전하게 되면서, NoSQL 데이터베이스가 각광을 받게 된 것입니다. 이러한 배경하에서 어떤 엔지니어들은 NoSQL을 Modern web-scale databases라고 정의하기도 합니다.

특징

• 기존의 관계형 데이터베이스 보다 더 융통성 있는 데이터 모델을 사용, 데이터의 저장 및 검색을 위한 특화된 매커니즘을 제공
• 관계형 모델을 사용하지 않으며 테이블간의 조인 기능 없음
• 직접 프로그래밍을 하는 등의 비SQL 인터페이스를 통한 데이터 액세스
• 대부분 여러 대의 데이터베이스 서버를 묶어서(클러스터링) 하나의 데이터베이스를 구성
• Schema-less (스키마 없이 동작), 구조에 대한 정의를 변경할 필요 없이 데이터베이스 레코드에 자유롭게 필드를 추가 가능
• 데이터베이스의 중단 없는 서비스와 자동 복구 기능 지원
• 다수가 Open Source로 제공

종류

1. Key-value
2. Document
3. Column-family
4. Graph

1. Key - value

2. Document

3. Column-Family

4. Graph

의의

NoSQL이 RDBMS를 대체할 수 있을 것이라고는 생각하지 않는다. 그러기에는 RDBMS가 가진 장점이 너무나 명확하고, 또한 많은 사람들이 RDBMS을 사용하는 데 익숙해져 있기 때문이다. 그럼에도 불구하고 NoSQL이 각광받고 있는 까닭은 NoSQL만의 장점이 뚜렷하기 때문이다.

예를 들어 구매 내역이나 게임의 로그 같은 데이터들은 매 초마다 엄청난 양이 생성되지만 한번 저장되고 난 뒤에는 수정될 일이 거의 없다. 이런 데이터들을 저장하는 데 데이터의 일관성을 보장하기 위해 ACID 트랜잭션을 지원할 필요는 없을 것이다. 거기다 생성되는 데이터의 양도 많기 때문에 장비의 성능에도 상당한 영향을 미칠 것이다. NoSQL은 이러한 데이터들을 효율적으로 저장할 수 있다. 여러 대의 장비에 빠른 속도로 저장이 가능하며, 데이터의 양이 누적되더라도 얼마든지 수평적 확장이 가능하기 때문이다.

실제로 소셜 네트워크 서비스에서는 게시글들을 저장하는 데 NoSQL 데이터베이스를 사용하고 있다. 매 초에 수백 기가~수 테라 바이트씩 생성되는 데이터들을 RDBMS를 사용해 저장한다면, 글 작성 버튼을 누른 후 글이 중앙 데이터베이스에 저장되기까지 한참을 기다려야 글을 성공적으로 게시할 수 있을 것이다. 하지만 NoSQL의 분산 데이터베이스를 사용한다면 부하가 분산되기 때문에 우리가 글쓰기 버튼을 누르고 한참을 기다릴 필요가 없게 된다.

또한 각종 검색 엔진에도 사용되는 것이 NoSQL인데, 웹 페이지 내의 텍스트들을 형태소 단위의 토큰으로 분리하여 토큰과 해당 토큰이 포함된 페이지들의 URL을 맵핑하는 Inverted Index(역 인덱스) 구조를 NoSQL을 통해 구현한다. 이런 기능을 일반적인 RDMBS로 구현했을 경우 검색 창에 단어를 입력했을 때마다 상당한 시간이 소요될 것이다.

C++, Java, Python 등 여러 언어를 사용해서 하나의 프로그램을 만들 수 있는 것처럼 데이터베이스 역시 다양한 저장소를 사용할 수 있게 되었다는 점에서 NoSQL의 의의는 크다고 볼 수 있다.