제가 최근에 개발했던 프로젝트에서 조그만 임베디드 데이타베이스를 사용해야 했는데 이를 위해서 SQLite를 사용했습니다. 하지만 SQLite는 DB Lock을 과도하게 거는 경향이 있고 성능이 생각만큼 좋지 않아서 문제가 자꾸 발생 했습니다. 사실 조그만 임베디드 시스템에 관계형 데이타베이스는 좀 오버인 면이 있습니다. SQLite를 대체할 다른 조그만 데이타베이스 엔진을 조사하다가 맘에 드는 놈을 발견했는데 OrientDB라는 놈입니다. 독립서버로도 실행이 가능하고 임베디드로도 실행이 가능합니다. 더 중요한 것은 NoSQL이자 GraphDB라는 점입니다. RDBMS에 익숙한 오래된 개발자들에게는 새로운 문화적 충격이 될 이 OrientDB에 대해서 몇 회에 나누어 소개드리고자 합니다.
이 글은 OrientDB Tutorial을 축약하고 정리한 것입니다.
http://www.orientechnologies.com/getting-started/
NoSQL 세계로 초대합니다.
최근 몇년간 우리는 몇몇 NoSQL 솔루션들이 폭발적으로 확산되는 것을 목격했습니다. 이런 현상은 다음과 같이 정리할 수 있습니다. 이것은 SQL을 없애자는 것이 아니라 전통적인 관계형 데이타베이스(Relational Database Management System, 이후 RDBMS라 칭함)을 극복하고 새로운 가능성에 대해 열린 마음을 가져보자는 운동이라고 말입니다.
RDBMS와는 다른 대체 솔루션들은 이동통신, 의학, CAD 등의 틈새 분야에서 오랫동안 이용되어 왔습니다. 최근들어 NoSQL솔루션들에 대한 관심이 높아지고 Google, Amazon, Facebook, Foursquare, Twitter등의 거대 웹 회사들이 NoSQL 기반의 솔루션을 채용하고 있는 건 더 이상 뉴스거리도 안됩니다.
그렇다면 왜 이런 기업들이 오랫동안 잘 사용해 왔던 RDBMS를 버리고 다른 길로 가게 되었을까요? 그것은 성능, 확장성, 작은 바이너리, 생산성, 스키마 유연성을 위해서라고 요약할 수 있습니다. 이것들은 최근의 웹 어플리케이션이 요구하는 덕목이기도 합니다. 몇년 전에는 개발자들이 수백명의 동시 접속자를 처리할 정도로 시스템을 만들었지만 요즘은 수천 아니 수백만의 동시 접속을 처리하는 것이 기본이 되었습니다.
이런 상황의 변화 때문에 성공적인 경험을 활용하고 새로운 표준을 채용하는 등의 기술적 변화가 전방위적으로 일어나고 있습니다만, 유독 데이타베이스 부분에서만은 30년이 넘도록 큰 기술적 변화가 없었습니다. RDBMS는 70년대 최초로 개발된 후 지금까지도 여전히 압도적으로 많이 쓰이고 있습니다. 방법론과 언어들이 진화해 왔지만 RDBMS의 기본 개념인 테이블, 레코드 그리고 조인(Join)은 여전히 통용되고 있는 개념입니다.
NoSQL 기반 솔루션들은 다양한 상황에서 강력하고 확장성과 유연성을 보장하며 RDBMS를 대체할 수 있습니다. 많은 수의 NoSQL 솔루션들이 있지만 대략 다음과 같이 분류할 수 있습니다.
- Key / Value 데이타베이스 : 모델을 Key와 Value로 구성되는 해쉬 테이블로 단순화 시킵니다. Key / Value 데이타베이스는 분산된 여러개의 서버에서 운용하기 좋습니다. Redis, Dynamo, Riak 등이 대표적입니다.
- 칼럼 지향 데이타베이스 : 보다 더 나은 유연성과 쉬운 집합(aggregation)을 제공하는 칼럼에 데이타를 저장합니다. Facebook의 Cassandra, Google의 BigTable, Amazon의 SimpleDB 등이 이 그룹에 속합니다.
- 도큐먼트 데이타베이스 : 여러개의 필드를 가지는 도큐먼트, 그리고 이의 집합인 컬렉션으로 모델링합니다. 보통 스키마를 정의할 필요가 없습니다. MongoDB, CouchDB, ArangoDB 등이 속합니다.
- 그래프 데이타베이스 : 정보를 가지는 버텍스(Vertex)와 관계를 나타내는 엣지(Edge)로 구성된 그래프로 데이타를 모델링합니다. OrientDB, Neo4J, Sones, InfintyGraph 등이 이 그룹에 속합니다.
이들 부류들은 각각의 특징과 제한점을 가지고 있습니다. 모든 상황을 다 만족시킬 수 있는 단일 솔루션은 없습니다. 하지만 어떤 문제를 해결하기 위해 특정 타입의 데이타베이스가 더 좋은 솔루션이 됩니다. 중요한 NoSQL의 모토 중 하나는
"당신의 문제에 맞는 최적의 도구를 찾아라"입니다.
도큐먼트와 그래프 모델
OrientDB는 앞에서 언급한 NoSQL 솔루션의 부류 중에서 도큐먼트 데이타베이스와 그래프 데이타베이스의 특징을 모두 가지고 있습니다. 그래서 활용 분야가 더 넓습니다.
도큐먼트 모델
도큐먼트 모델에서는 데이타가 도큐먼트 안에 담깁니다. 도큐먼트는 Key / Value 쌍(혹은 필드나 프러퍼티, 속성 등으로 불립니다)의 집합을 포함합니다. 여기서 Key는 Value에 접근하기 위한 역할을 합니다. Value는 기본 데이타 타입일 수도 있고, 다른 도큐먼트일 수도 있고, 다른 값들의 배열일 수도 있습니다. 도큐먼트는 스키마를 가질 필요가 없기 때문에 유연하고 쉽게 형식을 바꿀 수 있습니다. 또한 다른 형식의 도큐먼트들 일지라도 하나의 컬렉션에 포함될 수 있습니다.
OriendDB는 도큐먼트와 컬렉션이라는 개념 대신에 몇가지 잇점을 위해 클래스와 클러스터라는 개념을 사용합니다. 아래 표를 통해 도큐먼트 모델, 전통적인 RDBMS 모델, 그리고 OrientDB의 모델을 비교할 수 있습니다.
그래프 모델
그래프는 버텍스(Vertex 혹은 Node)와 이들을 연결하는 Edge(혹은 Relationship)들로 구성된 네트워크로 표현됩니다. OrientDB의 그래프 모델은 다음과 같은 속성들에 의해 정의됩니다.
- vertex - 다른 vertex들과 연결될 수 있으며 다음 속성을 가진다
- 유일한 식별자 (unique identifier)
- 들어오는 엣지들
- 나가는 엣지들
- edge - 두개의 vertex들을 연결하며 다음 속성을 가진다.
- 유일한 식별자 (unique identifier)
- 들어오는 vertex에 대한 링크 (head라고도 불림)
- 나가는 vertex에 대한 링크 (tail이라고 불림)
- 두 vertex간의 관계를 나타내는 label
이런 필수적인 속성 외에도 버텍스와 엣지들은 사용자가 정의하는 추가적인 속성을 가질 수 있습니다. 그래서 버텍스와 엣지는 도큐먼트와 비슷해 보이기도 합니다. 다음 표를 통해 그래프 모델, 전통적인 RDBMS 모델, Orient 그래프 모델을 비교할 수 있습니다.
다음 글에서는 OrientDB를 설치하고 실행하는 법에 대해 알아보겠습니다.
댓글 없음:
댓글 쓰기