NoSQL

말 그대로 No SQL, 즉 'SQL을 안 쓴다'는 뜻으로 해석할 수 있다. SQL을 활용할 수도 있다는 뜻으로 'Not Only SQL'을 뜻한다고 주장하기도 하지만, 사실 NoSQL 데이터베이스들이 SQL 기반의 관계형 데이터베이스와는 한참 동떨어져 있다 보니, 이런 데이터베이스를 쓰다 보면 SQL을 뭐하러 쓰지? 싶은 생각이 든다.

빅데이터 시대가 되면서 특히 NoSQL이 주목 받고 있다. 빅데이터는 데이터의 양도 엄청나지만 데이터의 형태가 정형화되어 있지 않고 워낙에 변화무쌍한 것들이 많아서 데이터 구조의 일관성을 중시하는 관계형 데이터베이스에서는 까다로운 부분이 많다. 반면 NoSQL은 일관성을 크게 강제하지 않기 때문에 들어오는 대로 일단 막 집어넣고 볼 수 있다.

데이터의 일관성은 관계형 데이터베이스가 가진 데이터의 무결성과 같은 장점을 보장하지만, 어떤 때에는 데이터의 처리를 까다롭게 만들고 경직되게 만드는 원인이기도 하다. 주소를 예로 들어 보자. 우리나라의 과거 형태 주소, 즉 지번 기반 주소를 외국의 도로명 기준 주소와 비교하면 다음과 같다.

• 지번 주소 : 시/도, 구, 동, 번지, 세부주소
• 외국의 도로명 주소 : 주, 시, 도로명, 건물번호, 세부주소

이게 다가 아닐 것이다. 어떤 나라는 또 다른 요소로 구성된 주소를 쓸 수도 있다. 만약 국제적인 쇼핑몰이라면 어떤 식으로 된 주소든 다 받아줘야 하는데, 나라마다 주소 체계가 제각각일 때 이를 받아주려면 테이블에 이들 모든 요소가 다 속성으로 정의되어 있는 테이블을 짜고, 각 튜플마다 필요 없는 속성은 비우는 식으로 처리해야 한다. 위의 주소 예라면,

	주	시/도	구	동	도로명	번지/건물번호	세부주소
지번 주소	—	서울시	영등포구	여의도동	—	1-1	내위키아파트 101호
도로명 주소	Victoria	Melbourne	—	—	Bourke Street	1	1F

국제적으로 주소를 저장하려면 나라 이름도 저장해야 할 텐데? 넘어갑시다.

그런데 한국은 아파트를 무지 좋아하는데, 아파트 이름을 그냥 세부주소에 다 퉁쳐서 저장하는 것은 나중에 검색이나 분류를 할 때 좋지 않다. 그래서 아파트는 따로 분리하는 게 좋을 것 같다. 이렇게 각국의 특성에 맞춰서 주소 스키마를 짜려면 밑도 끝도 없다.

반면 NoSQL은 미리 스키마를 짜놓고 딱 그에 맞게 데이터를 넣는 게 아니라, 데이터를 넣다가 분명 이 범주에 들어가야 할 데이터인데 구성 요소가 다르다면 그냥 그에 맞는 새 속성(필드)을 정의해서 새로 밀어넣을 수 있다. 그렇다고 기존 데이터에 새로운 필드가 추가되지도 않는다. 즉 데이터 구조의 일관성을 강제하지 않는다.

가장 큰 문제라면 SQL처럼 뭔가 일관된 인터페이스가 없다 보니, 데이터베이스 제품별로 데이터를 넣고 빼고 가져오는 방법이 제각각이라는 것. 물론 SQL 기반 데이터베이스들도 자체 기능을 사용하기 위해서 표준에서 벗어난 구문들이 종종 추가되지만 그래도 SQL이라는 뼈대 위에 추가되는 형태인데 반해, NoSQL은 정말 제각각이다. 게다가 일관된 스키마를 강제하지도 않다 보니, 어떤 제품을 쓰다가 다른 제품으로 전환해야 할 때에는 특히나 마이그레이션 과정이 관계형 데이터베이스와는 비교도 할 수 없이 돌아버릴 수 있다.

관계형 데이터베이스에 익숙해 있던 사람들이 가장 돌아버리는 것은 무결성 문제로, 이를테면 NoSQL은 외래 키 개념이 없다. 예를 들어 관계형 데이터베이스는 테이블 b를 정의할 때 특정 속성이 테이블 a의 키값이 되도록 정의할 수 있으며, 만약 이 속성에 a의 키값이 아닌 다른 값이 들어 있는 데이터를 테이블 b에 집어넣으려고 하면 거부한다. NoSQL은 이런 거 없다. 그냥 다 받아준다. 또한 관계형 데이터베이스는 테이블 b에서 키값으로 쓰이고 있는 테이블 a의 어떤 튜플을 삭제하려고 하면 이 역시 거부한다. 먼저 테이블 b에서 해당 튜플을 지워야 한다. NoSQL은 이런 없다. 그렇기 때문에 무결성이 중요한 데이터라면 NoSQL이 오히려 지옥이 될 수 있다.

종류

• 문서 기반 : 몽고DB, 카우치베이스