데이터 세상으로 떠나는 간결한 안내서 - NoSQL 왜 등장했을까?

'빅 데이터 세상으로 떠나는 간결한 안내서(NoSQL Distilled)'라는 책의 내용을 정리해두는게 좋을것 같아 블로그에 포스팅 하기로 결정하였습니다.

 

• NoSQL 왜 등장했을까?
• 어떤 상황에 어떤 NoSQL 을 사용해야하는가?

로 나누어 올리도록 하겠습니다.

 

---

 

관계형 데이터베이스가 지배하던 시절

 

오랫동안 데이터를 저장한다고 하면 당연히 관계형 데이터베이스(RDBMS)를 사용하는 게 기본이었습니다.

새 프로젝트를 시작할 때 고민이라곤 어떤 관계형 데이터베이스를 쓸지 정도였죠. 회사에 이미 계약된 벤더가 있다면 그런 고민조차 필요 없었습니다.

1990년대에 객체 데이터베이스가 잠깐 도전장을 내밀었지만, 크게 성공하지 못했습니다. 관계형 데이터베이스는 계속해서 독보적인 위치를 유지했죠.

관계형 데이터베이스가 오래 살아남은 이유

관계형 데이터베이스가 이토록 오래 지배적 위치를 차지할 수 있었던 건 분명한 가치들이 있었기 때문입니다.

1. 데이터 저장 능력

빠르지만 휘발성인 메모리의 한계를 극복하고, 디스크에 많은 양의 데이터를 영구적으로 보관할 수 있었습니다.

덕분에 애플리케이션이 정보를 빠르고 쉽게 얻을 수 있었죠.

2. 동시성 제어

여러 사용자가 동시에 같은 데이터를 보고 수정하는 기업 환경에서, 트랜잭션을 통해 데이터 접근을 통제하고 일관성을 유지했습니다.

오류가 발생하면 데이터를 롤백하여 정리하는 역할도 했죠.

3. 통합 기능

서로 다른 팀이 만든 여러 애플리케이션이 협업할 때, 통합 데이터베이스를 공유하는 방식으로 공통 데이터 저장소 역할을 했습니다.

모든 애플리케이션이 일관된 데이터 집합을 사용할 수 있었죠.

4. 표준 모델

이 모든 장점들을 표준적인 방법으로 제공했습니다.

개발자들은 관계형 모델과 SQL을 한 번 배우면 다양한 프로젝트에 적용할 수 있었고, 벤더가 달라도 핵심 메커니즘은 유사했습니다.

 

---

 

그러나 한계가 드러나기 시작했다

 

객체-관계 불일치 문제

 

애플리케이션 개발자들에게 가장 큰 불만은 관계형 모델과 메모리 내 데이터 구조 간의 차이였습니다.

관계형 모델은 테이블과 행으로 데이터를 구조화하며, 값은 단순해야 했습니다. 중첩된 레코드나 리스트를 포함할 수 없었죠.

반면 메모리 내 객체는 훨씬 복잡한 구조를 가질 수 있었습니다.

이 때문에 복잡한 메모리 내 객체를 데이터베이스에 저장하려면 관계형 표현으로 변환해야 하는 문제가 발생했습니다.

하이버네이트나 아이바티스 같은 객체-관계 매핑(ORM) 프레임워크가 이 문제를 완화했지만, 매핑 문제는 여전히 논쟁거리였습니다.

 

애플리케이션 데이터베이스로의 전환 요구

 

통합 데이터베이스를 공유하는 방식은 여러 애플리케이션을 위한 복잡한 구조를 만들었습니다.

특정 애플리케이션의 데이터 저장소를 변경하려면 다른 모든 애플리케이션과 조율이 필요했죠.

그래서 애플리케이션 데이터베이스 개념이 대두되었습니다.

• 단일 팀이 관리하는 단일 애플리케이션만 데이터베이스에 직접 접근
• 스키마 유지보수와 개선이 훨씬 쉬워짐
• 데이터 정합성 책임을 애플리케이션 코드에 부여

HTTP를 통한 웹 서비스가 활성화되면서 XML이나 JSON 같은 복잡한 데이터 구조를 교환할 수 있게 됐고, 이는 공유 데이터베이스에서 SQL을 사용하는 방식에 새로운 도전이 됐습니다.

무엇보다 애플리케이션 데이터베이스 방식은 개발자에게 비관계형 데이터베이스를 고려할 자유를 줬습니다.

 

---

 

클러스터 환경과 관계형 데이터베이스의 결정적 한계

 

2000년대는 웹의 규모가 극적으로 성장한 시기였습니다.

• 사용자 활동 추적
• 소셜 네트워크
• 활동 로그
• 매핑 데이터

이런 대규모 데이터 집합이 나타났고, 사용자 수 증가와 함께 데이터 양도 폭발적으로 커졌습니다.

확장 방법의 선택

이런 규모의 성장을 처리하기 위해 기업들은 두 가지 확장 방법 중에서 선택해야 했습니다.

 

수직 확장 (Scale-up)

더 큰 장비에 더 많은 프로세서, 디스크 스토리지, 메모리를 장착하는 방법입니다.

 

문제점:

• 실질적인 한계가 존재
• 비용이 엄청나게 비싸짐

 

수평 확장 (Scale-out)

작고 값싼 장비를 많이 모아 클러스터를 구성하는 방법입니다.

장점:

• 저가 하드웨어로 구축 가능
• 비용이 훨씬 적게 듦
• 장비 하나가 실패해도 클러스터 전체는 중단 없이 서비스
• 높은 가용성 제공

 

문제는 관계형 데이터베이스가 클러스터에서 동작하도록 설계되지 않았다는 점

 

 오라클 RAC나 마이크로소프트 SQL 서버 같은 클러스터 관계형 데이터베이스는 공유 디스크 개념을 사용했는데, 이는 클러스터 디스크 서브시스템이 단일 고장점이 될 수 있음을 의미했습니다.

관계형 데이터베이스에서도 데이터를 분리하고 각 데이터 집합을 별도 서버에서 처리하도록 샤딩(Sharding)할 수 있었지만:

• 애플리케이션에서 모든 샤딩을 제어해야 함
• 여러 샤드에 걸치는 쿼리가 어려움
• 참조 정합성 유지가 복잡
• 트랜잭션과 일관성 제어가 어려움

흔히 "부자연스럽다"고 표현되었습니다.

상용 관계형 데이터베이스의 라이선싱 비용 또한 단일 서버를 가정해 책정되므로, 클러스터에서 실행하면 비용이 크게 올라갔습니다.

 

---

 

구글과 아마존이 길을 열다

 

 이러한 관계형 데이터베이스와 클러스터 간의 부조화로 인해 일부 조직은 다른 데이터 저장 대안을 고려하기 시작했습니다.

특히 구글과 아마존은 대규모 클러스터 운영의 선두에 서서 자신들의 노력을 논문으로 발표했습니다.

• 구글의 빅테이블(Bigtable)
• 아마존의 다이나모(Dynamo)

 이 논문들은 클러스터 세상에 맞는 데이터베이스를 만들려는 탐구를 촉발시켰습니다.

구글과 아마존의 규모는 대다수 조직과는 달랐지만, 점점 더 많은 조직이 더 많은 데이터를 수집하고 처리하면서 똑같은 문제를 경험하기 시작했죠.

이는 관계형 데이터베이스에 대한 클러스터의 위협이 심각하다는 인식을 퍼뜨리는 계기가 됐습니다.

 

---

 

NoSQL의 출현과 새로운 관점

 

 NoSQL이라는 용어는 1990년대 후반 카를로 스트로치가 만든 비관계형 데이터베이스 이름에서 우연히 유래했지만, 실제로 우리가 인식하는 NoSQL 용어 사용의 기원은 다릅니다.

2009년 6월 11일 샌프란시스코에서 조핸 오스카슨이 조직한 비공식 모임

 

빅테이블과 다이나모의 사례가 대안 데이터 저장소를 실험하는 여러 프로젝트에 영감을 줬고, 조핸은 이 새로운 종류의 데이터베이스에 대해 더 많이 알고 싶어 모임을 주관했습니다.

 

트위터 해시태그로 짧고 기억하기 쉬운 '#NoSQL'을 선택했는데, 당시에는 기술 동향 전체를 나타내는 이름으로 유행하리라고는 예상하지 못했습니다.

 

NoSQL 데이터베이스의 공통 특징

 

명확하게 정의된 용어는 아니지만, NoSQL 데이터베이스는 몇 가지 공통 특징을 가집니다.

특징	설명
비관계형 모델	관계형 모델을 사용하지 않음
클러스터 친화적	처음부터 클러스터에서 잘 동작하도록 설계
오픈 소스	카산드라, 몽고DB, 네오4J, 리악 등 대부분 오픈 소스
21세기형	웹 환경의 필요에 기초하여 구축
스키마 프리	데이터베이스 레코드에 자유롭게 필드 추가 가능
유연한 일관성	ACID 대신 다양한 일관성 옵션 제공

 

물론 애플리케이션 코드에는 '암묵적 스키마'가 존재하긴 합니다.

 

NoSQL을 고려해야 하는 두 가지 중요한 이유

 

1. 애플리케이션 개발 생산성 향상

많은 애플리케이션 개발 노력이 메모리 내 데이터 구조를 관계형 데이터베이스에 매핑하는 데 소모됩니다.

NoSQL 데이터베이스는:

• 애플리케이션의 필요에 좀 더 적합한 데이터 모델 제공
• 상호작용을 단순화
• 작성해야 할 코드량 감소

2. 대규모 데이터 처리 능력

많은 조직이 더 많은 데이터를 수집하고 빨리 처리하는 것의 중요성을 깨달았으며, 관계형 데이터베이스로는 이런 작업이 가능하더라도 비용이 매우 많이 든다는 사실을 알게 됐습니다.

NoSQL 데이터베이스는:

• 작고 값싼 장비 여러 대로 구성된 클러스터에서 동작
• 대량의 데이터와 컴퓨팅 부하 처리
• 빅 데이터 시나리오에 더 적합

 

---

 

다중 저장소 지속성 시대의 도래

 

NoSQL의 등장은 관계형 데이터베이스가 더 이상 모든 문제를 해결할 수 있는 만능이 아니라는 인식에서 비롯됐습니다.

하지만 이는 관계형 데이터베이스의 종말을 의미하는 것이 아닙니다.

우리는 이제 다양한 지속성 도구를 사용하는 다중 저장소 지속성(Polyglot Persistence) 시대로 진입했습니다.

• 기업뿐 아니라 개인 애플리케이션에서도 여러 종류의 기술 혼용
• 데이터 관리에 다양한 도구 활용이 일반화

아키텍트와 개발자는 변화하는 필요에 따라 어떤 기술을 사용하는 것이 좋을지 평가할 수 있어야 합니다.

NoSQL 옹호자들은 이러한 데이터베이스가 성능이 뛰어나고, 쉽게 확장할 수 있으며, 프로그래밍도 쉽게 할 수 있는 시스템을 구축할 수 있다고 주장합니다.

 

 다중 저장소 지속성(Polyglot Persistence)이란?

 하나의 애플리케이션에서 여러 종류의 데이터베이스를 함께 사용하는 접근 방식입니다. 예를 들어 사용자 세션은 Redis, 상품 정보는 MongoDB, 결제 내역은 PostgreSQL처럼 각 데이터의 특성에 맞는 최적의 데이터베이스를 선택해 사용하는 것을 말합니다

 

---

 

마무리

 

결론적으로 NoSQL과 관계형 데이터베이스는 각자의 강점을 가진 도구들입니다.

이제 우리는 문제에 맞는 도구를 선택할 수 있는 시대가 됐습니다.

책에서 강조하듯이, 이제는 하나의 만능 솔루션이 아닌 각 상황에 맞는 최적의 도구를 선택하는 것이 중요해진것 같습니다.

다음 포스팅은 책에서 어떤 상황에서 어떤 NoSQL 을 사용하는게 좋다고 말하는지 분석해 공유하도록 하겠습니다.