NoSQL

4 분 소요


0. 들어가면서

이번 진행하는 프로젝트에서 NoSQL 적용을 하자는 의견이 나왔습니다. 새로운 기술 스택을 도입하려다 보니 걱정이 먼저 앞서게 됩니다. 어떤 기술 스택이던지 장단점이 존재하기에 이를 파악하고 적재적소에 적용하는 것이 개발자의 역량이라고 생각합니다. NoSQL 개념에 대해 포스트로 정리 후 팀원들과 공유하여 이번 프로젝트의 NoSQL 도입 여부에 대해 논의해봐야겠습니다.

1. NoSQL(Not Only SQL) 등장 배경

전통적인 관계형 데이터베이스(RDB, Relational Database) 시장을 지배하던 시절과 다른 형태를 가지는 데이터의 양이 늘어나게 되면서 NoSQL이 각광받기 시작하였습니다. 일단 형태에 따른 데이터 종류가 무엇이 있는지 알아보겠습니다.

1.1. 형태에 따른 데이터 종류

  • 정형 데이터 - 형태가 정해져 있는 데이터. 관계형 데이터베이스, Spread Sheet, CSV 등
  • 반정형 데이터 - 형태가 있으나 데이터 모델을 준수하지 않는 데이터. XML, Json, HTML, 로그 등
  • 비정형 데이터 - 데이터의 형태가 없으며, 연산이 불가능한 데이터. 영상, 이미지, 음성, 텍스트 등

이전에는 정형 데이터가 주를 이루었습니다. 비즈니스 요건 사항에 맞도록 데이터 형태과 규칙을 지정하고 그에 맞도록 저장하고 사용하였습니다. 예를 들어, 성별을 저장할 Gender 컬럼에 남, 여를 표현하는 male, female을 저장하는 것을 의미합니다. 정형 데이터는 규칙을 정하고 규칙적인 값들이 들어가며, 수치만으로 의미를 파악하기 쉬운 형태의 데이터입니다.

2000년 후반부터 인터넷이 활성화되고 SNS, 유튜브 같은 서비스들의 사용자가 늘어나면서 비정형 데이터의 양이 대폭 늘어나게 되었습니다. 데이터 형태는 단순했으나 정해진 형태가 없었고, 세계적인 서비스의 경우에는 데이터 규모가 이전과는 비교할 수 없을 정도가 되었습니다. 데이터의 패러다임이 한정된 규모의 복잡성이 높은 데이터에서 단순한 대량의 데이터로 변한 것입니다. 기존에 주를 이루었던 정형 데이터를 다루는 관계형 데이터베이스로는 해결할 수 없는 한계에 도달하였습니다.

정형 데이터를 관리하는 대표적인 방법인 관계형 데이터베이스.
관계형 데이터베이스를 효과적으로 사용하기 위한 대표적인 방법인 SQL.

그렇기에 관계형 데이터베이스와 다른 방식으로 데이터를 다루는 방법을 NoSQL(Not Only SQL)이라 부르게 된 것 같습니다. NoSQL이라는 용어는 1998년 Carlo Strozzi에 의해 처음 사용되었으나 데이터 사이에 관계가 존재하였기에 지금의 개념과는 조금 달랐습니다. 2009년 초 Johan Oskarsson에 의해 “오픈 소스 분산, 비 관계형 데이터베이스”를 논의하기 위한 이벤트를 조직하면서 다시 소개되었습니다.

2. NoSQL 특징

NoSQL은 관계형 데이터베이스가 아닌 다른 형태의 데이터 저장 기술을 총칭하는데 사용됩니다. 그렇기 때문에 제품에 따라서 특성이 매우 다르기에 하나의 제품군으로 설명하기에는 무리가 있습니다.

일단 NoSQL에 대한 특징들을 정리해보았습니다.

  • RDBMS와 다르게 데이터의 관계를 정의하지 않습니다.
  • 하나의 고성능 머신에 데이터를 저장하지 않고, 여러 대의 서버에 분산하여 데이터를 저장합니다.
  • 여러 대 서버에 분산하여 저장하기 때문에 RDBMS에 비해 더 많은 양의 데이터를 저장할 수 있습니다.
  • ID를 제외한 다른 필드에는 어떤 종류에 데이터가 저장되어도 괜찮습니다. 테이블 스키마가 유동적입니다.
  • 분산 환경에서 트랜잭션 ACID 특성을 만족하기 어려우므로 Eventual Consistency(결과적 일관성)를 허용합니다.
  • 데이터 모델이 다양합니다. Key-Value, Wide-Column, Graph, Document 등이 존재합니다.
  • 데이터를 질의하는 API가 다양합니다. 제품마다 질의가 다르며, UnQL(Unstructured Query Language)라고 합니다.
  • 복잡한 질의를 하기 어렵습니다. 주로 저수준의 질의를 사용합니다.
  • 데이터베이스 중단 없이 서비스가 가능하며 자동 복구 기능이 지원됩니다.
  • 분산형 컴퓨팅을 효과적으로 지원할 수 있도록 설계되었습니다. 수평적 확장(Horizontal Scaling)이 용이합니다.
  • 대부분이 오픈 소스 형태로 제공되고 있습니다.
  • 시장이 성숙하지 않았기에 전문가가 부족하고 상당한 러닝 커브가 존재합니다.

3. NoSQL 데이터 모델

많은 유형의 NoSQL들이 존재하지만 대부분의 포스트에서 대표적으로 언급하는 4가지 유형에 대해서만 정리해보았습니다. 각 유형별 특징과 대표하는 제품도 함께 소개하겠습니다.

대표적인 NoSQL 데이터 모델

이미지 출처, https://docs.microsoft.com/en-us/dotnet/architecture/cloud-native/relational-vs-nosql-data


3.1. Key-Value 데이터 모델

Key와 Value의 쌍으로 데이터가 저장되는 가장 단순한 형태의 데이터 모델입니다. 복잡한 조회 연산은 지원하지 않습니다. 고속 읽기와 쓰기에 최적화된 경우가 많습니다. 구현하기 쉽지만 Value의 일부분을 읽거나 업데이트하는 것이 매우 비효율적입니다.

3.1.1. Key-Value 모델 데이터 저장 방법

3.1.2. Key-Value 데이터 모델의 대표적인 제품

  • Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB, Amazon SimpleDB, Riak

3.2. Wide Column 데이터 모델

Key와 Value의 쌍으로 데이터를 저장하는 방식은 동일합니다. Row에 대한 Key가 존재하고 해당 Row에 대한 Column 이름과 Column 값이 데이터로 Value로 저장됩니다. 이 데이터 모델에서 Column Family라는 개념이 흔하게 사용되는 것 같습니다. Column Family 라는 개념에 대한 정의를 찾아보았습니다.

Wiki - Standard column family
A standard column family consists of a (unique) row key and a number of columns.

3.2.1. Wide Column 모델 데이터 저장 방법

3.2.2. Column Family 방식의 데이터 저장 방법

이미지 출처, https://studio3t.com/knowledge-base/articles/nosql-database-types/


3.2.3. Wide Column 데이터 모델의 대표적인 제품

  • HBase, Cassandra, ScyllaDB

3.3. Document 데이터 모델

Key-Value 데이터 모델의 확장된 형태로 Value에 XML, Json, Yaml 같은 Document 타입을 저장합니다. 복잡한 데이터 구조를 표현하는 것이 가능해졌습니다. Document ID 또는 속성 값을 기준으로 인덱스를 생성할 수 있습니다.

3.3.1. Document 모델 데이터 저장 방법

이미지 출처, https://www.mongodb.com/document-databases


3.3.2. Document 데이터 모델의 대표적인 제품

  • MongoDB, CoughDB

3.4. Graph 데이터 모델

노드들과 그들 사이의 관계를 기반으로 구성된 데이터베이스입니다. 노드들은 사용자 정보, 카테고리 정보 등과 같은 데이터 엔티티를 의미합니다. 관계는 두 개의 노드가 어떤 연관이 있는지, 어떻게 연결되어 있는지 표현합니다. 해당 데이터 모델은 이해가 쉽지 않았기에 대표적인 neo4j 제품의 동작을 정리해보았습니다.

3.4.1. Graph 모델 데이터 생성 방법

CREATE (a:Person { name:"Tom Hanks",  born:1956 })-[r:ACTED_IN { roles: ["Forrest"]}]->(m:Movie { title:"Forrest Gump",released:1994 })
CREATE (d:Person { name:"Robert Zemeckis", born:1951 })-[:DIRECTED]->(m)
RETURN a,d,r,m

3.4.2. Graph 모델 데이터에서 생성된 데이터

이미지 출처, https://neo4j.com/docs/pdf/neo4j-getting-started-4.2.pdf


3.4.3. Graph 모델 데이터 질의와 결과

  • 데이터 질의
MATCH (p:Person { name:"Tom Hanks" })-[r:ACTED_IN]->(m:Movie)
RETURN m.title, r.roles
  • 데이터 질의 결과
+------------------------------+
| m.title        | r.roles     |
+------------------------------+
| "Forrest Gump" | ["Forrest"] |
+------------------------------+
1 row

3.4.4. Graph 데이터 모델의 대표적인 제품

  • Neo4J, InfoGrid, Infinite Graph

CLOSING

포스트를 정리하는데 생각보다 많은 시간이 걸렸습니다. 사용해보지 않았기에 포스트에 오류가 많을 수도 있습니다.(도움을 주세요.😅)

이번 프로젝트에서 적용하기 위해 조사하는 중에 이런 내용을 발견하였습니다.

NoSQL이라는 새로운 기술과 제품군을 사용하려면, 그에 들어가는 교육과 개발 비용들이 결코 만만치 않다. 기존의 Oracle이나 MySQL과 같은 RDBMS를 사용해도 국내 대부분의 서비스는 구현이 가능하다. 데이터가 늘어나면 추가 RDBMS 클래스터를 추가해 용량을 증설하는 방법도 있다.

1억 명을 대상으로 한 서비스를 만들려고 시도할 때 NoSQL이 적합해 보이지만, NoSQL을 공부하는데 시간이 들어가고 운영하면서 수많은 장애를 겪다 보면 사용자들이 다 떨어져 나갈지도 모른다. MySQL 등 기존의 익숙한 기술을 사용하다가 MySQL로 도저히 용량 감당이 되지 않는 경우에 NoSQL로의 전환을 고려하는 것은 어떨까? MySQL로 용량이 안 된다면 그 때는 이미 사업이 성공했을 때이므로 NoSQL로 전환할 기술력이나 자금력이 충분할 것이다.

상당히 큰 규모의 시스템이지만 안정적인 운영과 시스템 개발을 위해서는 NoSQL 보다는 RDMBS가 나을 것 같다는 생각이 문뜩 들었습니다. 저희 팀이 NoSQL 이라는 기술 스택을 너무 쉽게 생각하고 섣부른 결정을 내려한 것 같습니다. 팀원들에게 해당 글을 공유하고 함께 의논하는 시간을 가져봐야겠습니다. 포스트를 작성하기 위해 많은 공부가 되었고, 쉽게 NoSQL 적용을 제안한 제 자신이 아직 부족하다는 것을 한번 더 느꼈습니다.

REFERENCE

카테고리:

업데이트: