1 NoSQL의 개념과 사례

1.1 NoSQL 개념

원래는 non-SQL 또는 non-Relational 데이터베이스 종류를 지칭하기 위해서 생긴 용어이다. 하지만 IT 산업 전반에 걸쳐서 SQL의 활용도가 높기 때문에 NoSQL 데이터베이스인데도 오히려 SQL을 지원하는 경우가 많아지고 있다. 이 때문에 현재는 Not-only SQL의 의미로 쓰이는 경우도 있다.

RDBMS의 한계점을 NoSQL마다 저마다의 해결책을 제시하고 있어서 어떤 속성을 가져야 NoSQL이다 라고 지칭할 수 없다. NoSQL이라는 것 자체로 설명이 더 필요 없다.

1.2 NoSQL의 특징

1.2.1 RDBMS와 비교한 장점

1. 데이터 형식이 자유롭다.

   • 데이터 타입
   • 데이터의 길이/크기

2. RDBMS에서 데이터의 형식이 테이블로 정해져 있기 때문에 데이터를 Java의 객체 모델에 연결해서 표현하기 힘든 문제 (Object-Relation Impedance Mismatch)를 해결할 수 있다. (객체 매핑하기 어려워서 하이버네이트 처럼 ORM쓴다고 했는데 어떻게든 JDBC 쓰면서 하기 위해 노력을 한 것이고 기본적적으로는 데이터 형식이 테이블 형식으로 정해져 있으니까 자바의 객체 모델에 100% 연결될 수 없다.)

   • Object를 표현할 수 있는 문서의 구조를 가질 수 있다.

3. SQL 형식을 맞추지 않더라도, 전용 라이브러리나 함수등으로 쉽게 조회할 수 있다.

4. 용도나 목적에 맞는 DB를 선택하면 데이터 저장/조회 속도를 높일 수 있다.

   • RDBMS는 관계형 데이터를 범용적으로 표현할 수 있지만, 데이터가 많아지면 일정 수준이상의 속도를 내는데는 한계가 있다.

5. 빅데이터 NoSQL DB의 경우, 더 많은 데이터를 저장하면서도 빠른 데이터 접근 속도를 보장할 수 있다.

단, NoSQL 데이터베이스는 종류가 너무 많기 때문에, 여기서 쓴 장점을 모두 달성할 수 있는 NoSQL DB는 없다.
(여기 있는 장점들은 RDBMS의 단점이라는 것) RDBMS에서 할 수 없는 것 중에 여기있는 장점 중 필요한 것이 있다면, 그것을 제공할 수 있는 NoSQL DB를 선택하면 된다.

1.2.2 RDBMS와 비교한 단점

1. 기능이나 형식의 표준(예-> RDBMS는 기능 ACID 무조건 지켜야 한다, sql문은 표존 SQL문이 있다, 추가적인 기능도 붙일 수 있다 등)이 없다. 사용하는 DB별로 전용 라이브러리나 함수를 이용해 각각 구현해야 한다.

   • JDBC, ODBC 같은 클라이언트가 제공되기도 하지만, NoSQL DB는 사용 목적이나 용도가 명확하게 구분되기 때문에 RDBMS 수준의 스펙을 모두 따르며 제공하기는 어렵다.

2. 다른 데이터 집합(table/collection/index 등) 간에 Foreign Key가 없거나, 있더라도 cascading 옵션을 지원하지 않기 때문에, 서로 다른 집합 간의 관계 설정에서 정합성을 보장하기 어렵다.

3. SQL을 지원하더라도, 표준 SQL의 모든 기능을 제공하지는 않는다.

4. 트랜잭션의 ACID 특성을 모두 지원하지 않는 경우가 많으며, 일반적으로는 eventual consistency(최종적 일관성) 를 가정하고 사용해야 한다.

Eventual Consistency
Eventual consistency(결과적 일관성)는 분산 시스템에서 모든 데이터가 실시간으로 반영되지는 않지만, 일정 시간이 지나면 결국 모든 노드가 동일한 데이터를 갖게 되는 일관성 모델이다. 예를 들어, 어떤 데이터가 시스템에 입력된 후 바로 확인하면 일부 노드에는 아직 반영되지 않았을 수 있지만, 10분이나 1시간, 혹은 내일쯤 확인하면 모든 노드에 해당 데이터가 반영되어 있는 상태가 된다 — 이런 개념이 바로 eventual consistency다. 이 모델은 실시간 일관성을 희생하는 대신 시스템의 가용성과 확장성을 보장하며, 대규모 분산 환경에서 자주 사용된다. 최근에는 이 consistency가 얼마나 빨리 수렴되는지를 개선하려는 기술적 시도가 활발하게 이루어지고 있으며, 예를 들어 몇 초, 몇 밀리초(ms) 안에 일관성을 달성하도록 레이턴시 최적화나 동기화 알고리즘을 도입하는 등 다양한 방법이 연구되고 있다.

1.3 NoSQL의 사례

1.3.1 MongoDB

NoSQL 하면 대표적으로 떠오르는 데이터베이스다. 다양한 기능을 갖춘 범용 NoSQL 데이터베이스로, 문서(Document) 기반의 저장 방식을 사용한다.
초기에는 RDBMS의 핵심 기능인 트랜잭션(Transaction)을 지원하지 않았지만, 이후 발전을 거듭하며 단일 컬렉션 내 문서 단위로 원자성(Atomicity)과 트랜잭션 기능을 지원하게 되었다.
엄밀히 말해 빅데이터 처리를 위한 전용 데이터베이스는 아니지만, Sharding 기능을 통해 수평적 확장성을 제공한다.

Sharding 이란?
Sharding은 데이터베이스를 수평으로 분할(horizontal partitioning) 하여 여러 서버(Shard)에 나누어 저장하는 기술이다
즉, 한 테이블이나 컬렉션의 데이터를 특정 기준(예: 사용자 ID, 지역 등)에 따라 나누어 각 서버에 분산시킨다.

이 방식은 다음과 같은 목적을 가진다:

• 확장성(Scalability): 단일 서버의 저장 공간이나 처리 능력을 넘는 데이터를 여러 서버에 나누어 저장함으로써 처리량을 높임
• 성능 향상: 쿼리, 쓰기 작업을 병렬로 처리 가능하게 하여 처리 속도 개선
• 가용성 확보: 일부 샤드가 장애가 나도 전체 시스템이 멈추지 않음

예시로, 고객 ID 1~1000은 Shard A, 1001~2000은 Shard B에 저장하는 구조로 볼 수 있다.

1.3.2 Redis

In-Memory 데이터베이스의 대표주자로, 데이터를 메모리에 저장해 매우 빠른 응답 속도를 제공한다.
자료구조를 먼저 정의하고 사용하는 방식으로, 리스트, 해시, 셋 등의 다양한 자료구조를 효율적으로 처리할 수 있다.
싱글 스레드 기반으로 동작하며, 별도의 락(lock) 없이도 빠른 데이터 처리가 가능한 것이 장점이다.
다만 자료구조의 동작 원리를 이해하고, 사용 시 성능 특성에 주의해야 한다.

In-Memory Database는 뭐냐?
In-Memory Database는 말 그대로 데이터를 디스크나 파일이 아닌 컴퓨터 메모리(RAM)에 저장하는 데이터베이스를 말한다.
메모리에 저장되기 때문에 조회 속도는 매우 빠르지만, 컴퓨터나 프로세스가 꺼지면 데이터가 사라질 수 있다.
이런 특성을 알고도 사용하는 이유는 바로 속도 때문이다. 데이터 유실이 어느 정도 감당 가능한 경우, 혹은 유실을 방지할 수 있는 보완 장치(예: RDB snapshot, AOF log)를 함께 사용할 수 있는 경우 Redis 같은 In-Memory DB를 선택한다.

빠른 속도를 얻기 위해서는 미리 사용할 자료구조(리스트, 해시, 셋 등)를 잘 정해서 쓰는 것이 중요하다. 범용적으로 모든 데이터에 적합한 구조는 아니기 때문에 설계 시 고려가 필요하다.
또한 Redis는 락(lock)을 걸지 않고 동작한다. 락을 사용하면 다른 요청을 기다려야 하므로 속도가 느려질 수 있기 때문이다. 대신 싱글 스레드로 처리하면서 빠른 속도를 유지하지만, 잘못 사용하면 중요한 데이터를 날릴 수 있으니 주의가 필요하다.

1.3.3 Apache HBase

Hadoop 생태계 기반의 대표적인 빅데이터용 NoSQL 데이터베이스다.
단일 키(Row key) 로만 데이터 저장 및 조회가 가능하다는 점이 가장 큰 제약이자 장점이다.
데이터 양이 아무리 많아져도, 키 기반 조회는 일정한 속도를 유지하며 성능 저하가 거의 없다.
효율적인 사용을 위해서는 키 설계 전략을 잘 이해하고 적용하는 것이 중요하다.

1.3.4 Apache Druid

집계(Cube) 연산에 최적화된 분석용 데이터베이스다.
대용량 데이터에 대한 집계, 합산, 카운트 등의 연산을 빠르게 처리할 수 있다.
Druid는 쿼리 성능을 높이기 위해 사전에 집계 구조(Cube 모델) 를 정의해두는 것이 필요하다.
따라서 Cube 모델링 개념과 설계 방법에 대한 이해가 필수적이다.