Published on

NoSQL

Authors
  • avatar
    Name
    zkrp
    Twitter

안녕하세요 이번 도서관 프로젝트에서는 빠른 위치 검색과 사용자 맞춤 데이터를 다뤄야 했습니다.

하지만 RDBMS만으로는 확장성과 유연성에 한계가 있어 NoSQL을 도입하게 되었습니다. 이번에 NoSQL 을 공부할 겸 글을 작성하려합니다.

1. NoSQL 이란

NoSQL은 Not Only SQL 혹은 Non-Relational Operational DataBase의 약자로 비관계형 데이터베이스를 뜻합니다.

1.1 Not Only SQL 의미

Not Only SQL은 관계형 DB의 한계를 보완하려고 등장했지만, SQL 을 전혀 사용하지 않는다고 보는 것보다는 SQL의 범위를  넘어선 더 다양한 데이터 구조를 지원한다는 의미입니다.

1.1 Non-Relational Operational DataBase 의미

Non-Relational Operational DataBase은 데이터를 저장하는 구조가 테이블 방식의 관계형이 아니라, Key-Value , Document, Column-Family, Graph 등 다양한 형태로 저장한다는 의미입니다.

NoSQL은 기본적으로 JSON 문서와 같은 하나의 데이터 구조 안에 데이터를 저장합니다.

이 비관계형 데이터베이스 설계에는 스키마가 필요하지 않기 때문에 빠른 확장성을 제공한다는 특징을 가지고있습니다.

2. NoSQL 유형

NoSQL 은 다양한 형태를 가지고있습니다.

2.1  Key-Value Store - (Redis, DynamoDB)

NoSQL 의 일반적인 형태입니다.

스키마가 따로 존재하지 않는 대신에  데이터는 키- 값 형식으로 구성됩니다.

  • 데이터를 읽고 쓰는 데 최적화된 데이터베이스 유형입니다.
  • 고정된 구조가 없기 때문에 키 값 데이터베이스는 CRUD 작업을 위한 쿼리 언어가 필요하지 않습니다.

2.2  Document Store - (MongoDB, CouchDB)

데이터를 문서로 저장하는 형식입니다.

반정형 데이터를 관리하는 데 도움이 될 수 있으며 , 데이터는 일반적으로 JSON, XML, BSON 형식으로 저장됩니다.

  • 애플리케이션 요구 사항이 변경됨에 따라 데이터 모델을 발전시킬 수 있는 유연한 스키마가 가능합니다.
  • 문서 데이터베이스는 분산되어 있어 수평 확장(일반적으로 수직 확장보다 저렴)과 데이터 분산이 가능합니다.
  • 문서 데이터베이스는 개발자가 데이터를 쉽게 상호 작용할 수 있도록 대량 API와 쿼리 언어를 제공합니다.

3.  Column-Family Store - (Cassandra, HBase)

대량의 정형 및 반정형 데이터를 관리하도록 설계 되어있는 형식입니다.

  • 행이 아닌 열로 데이터를 구성하여 매우 유연한 스키마를 제공합니다.
    • 각 열 패밀리는 사실상 무제한의 열을 가질 수 있으며, 동적으로 생성될 수 있습니다.
    • 열 패밀리는 키-값 저장소에 저장되는 키 수를 줄여 INSERT , UPDATE 및 작업 시 성능을 향상시킵니다

4.  Graph Database - (Neo4j, ArangoDB)

데이터를 그래프 형식 구조로 저장하는 형식입니다.

  • 그래프에서 엔티티는 노드로 표시되고, 관계는 에지로 표시됩니다.
  • 엔티티간의 복잡한 관계를 더욱 자연스럽게 표현할 수 있습니다.
    • 관계형 DB에서 복잡한 JOIN 연산으로만 표현 가능한 연결 관계를 훨씬 자연스럽게 표현할 수 있습니다. 
    • 그래프 데이터베이스의 스키마리스 구조는 데이터가 증가함에 따라 새 노드와 에지를 쉽게 추가할 수 있어 유연하고 확장 가능합니다.

NoSQL 은 이러한 다양한 특징과 장점을 가지고 있지만 단점도 있습니다.

3. NoSQL 단점

NoSQL은  다음과 같은 단점이 있습니다.

3.1 데이터의 일관성 보장 어려움

  • NoSQL은 가용성과 분산 시스템 확장성을 우선시하다 보니, 강한 일관성을 지원하지 않는 경우가 많습니다.
    • 동일한 데이터가 여러 서버에 분산 저장될 때, 모든 서버에 동시에 동일 데이터로 동기화하는 것이 보장되지 않습니다.
      즉, 모든 읽기 요청에 가장 최신 데이터를 보장할 수 없습니다.

3.2 트랜잭션 처리의 한계

  • 관계형 데이터베이스(SQL)에서는 여러 테이블에 걸친 복잡한 트랜잭션(ACID)을 원자적으로 처리할 수 있지만,
    NoSQL 은 한 개의 행(record) 단위로만 트랜잭션이 지원됩니다.
    • 여러 행이나 여러 컬렉션, 여러 저장소에 걸친 복합 트랜잭션(atomic multi-record/transaction)은 대부분 지원하지 않거나,
      일부 제품만 부분적으로 지원합니다.

3.3 복잡한 쿼리 처리의 어려움

  • RDBMS에서는 JOIN, GROUP BY, ORDER BY 같은 복잡한 관계 연산을 SQL 하나로 쉽게 처리할 수 있습니다.
    • 하지만 대부분의 NoSQL은 조인 연산이 제한적이고, 데이터를 여러 컬렉션/테이블에 나눠두면 직접 애플리케이션 레벨에서 연산을 구현해야 합니다.

저는 이러한 NoSQL의 특징을 인지해서 프로젝트안에 어떤 부분에서 NoSQL이 필요하다고 판단이 되었는지 설명하겠습니다.

4.  프로젝트에 적용할 부분 

저는 이번 프로젝트에서 Redis와 MongoDB를 조합하여, 위치 기반 검색과 사용자 맞춤형 데이터 저장을 구현할 예정입니다.

4.1 Redis GEO를 활용한 위치 기반 검색

도서관 서비스의 핵심은 사용자 근처 도서관을 빠르게 찾는 것입니다.
이를 위해 Redis의 GEO 기능을 사용했습니다.

Redis 특징

  • 인메모리 기반 → 밀리초(ms) 단위 응답
  • GEOADD, GEOSEARCH 명령어로 손쉽게 반경 검색 가능
  • 거리순 정렬, 좌표 기반 필터링 지원

예를 들어, 사용자 위치를 가져와 사용자 기준으로 반경 20km 이내의 도서관을 검색할 수 있습니다.

GEOSEARCH lib:geo FROMLONLAT 126.97 37.40 BYRADIUS 20 km WITHDIST ASC

4.2 MongoDB를 활용한 사용자/도서관 데이터 관리

MongoDB는 문서(Document) 지향 DB로, 스키마의 유연성이 뛰어나고 수평 확장이 쉬워 프로젝트에서 다음과 같은 용도로 활용했습니다.

{
  "_id": "usr_9f3a2",
  "username": "minjune",
  "email": "[email protected]",
  "interests": ["컴퓨터공학", "알고리즘", "데이터베이스"]
}

4.3 도서관 특징 정보 (libraries 컬렉션)

도서관의 메타데이터와 편의시설, 주제 분야 등을 저장합니다.

{
  _id: ObjectId('68a7f7ebace8a4c168374b45'),
  libCode: 1110922137,
  libName: '도서관',
  address: '강서로45다길 71',
  tel: '0000',
  fax: '0-0002',
  latitude: 33,
  longitude: 12.51,
  homepage: 'http://localhost:8080/',
  closed: '매주 휴관',
  operatingTime: '평일 09:00 ~ 18:00(야간22:00) / 토 09:00 ~ 18:00(야간22:00) /일 09:00~18:00',
  BookCount: 88578
}

이런 식으로 NoSQL 장점을 이용해서 프로젝트의 생산성을 더 높였습니다.

읽어주셔서 감사합니다!

• View on GitHub