본 문서의 목적은 개발자들과 데이터 베이스 관리자들이 새로운 데이터 베이스의 중요성을 이해하고 기존 관계형 데이터 베이스와의 차이점을 이해하여 각자의 환경에서 최대한 유용하게 이용할 수 있도록 하는 것이다.
1.1. 관계형 데이터 베이스의 문제점은 무엇인가?
어떤 데이터 모델을 고려해보자. TCP/IP 인터페이스에 의해 접근 가능하고 자바와 웹 서비스 등 다양한 언어가 사용가능하다. 이 모델은 처음에는 가장 출중한 컴퓨터 싸이언티스트들에게도 이해하기 어려웠지만 점점 더 넓은 분야에 적용되면서 개념이 더 분명해졌다. 이 모델에 데이터 베이스를 사용하기위해서는 새로운 용어들을 배우고 데이터 저장소에 대한 다른 생각들이 필요했다. 하지만 이것에 의해 생산물이 많아질수록 더 많은 비즈니스와 정부 에이전시들이 이것을 더욱 빠르고 많이 사용하게 되었다. 이에 따른 세입도 매우 많아졌다.
그리고 나서 새로운 모델이 나타났다.
새로운 모델은 두가지 이유에서 위협적이었다. 첫째로, 새로운 모델은 논란을 불러일으킬 만큼 이전의 모델과는 매우 달랐다. 다르고 새로운 것을 이해한다는 것은 어렵기 때문에 위협적이었던 것이다. 토론이 잇따랐지만 기존에 사람들이 일하던 환경에서 배우던 기술들과 관점에 더욱 고착화 될 뿐이었다. 둘째로, 아마 더욱 중요한 것은 기존 모델에서 비즈니스들은 많은 투자를 하였고 이미 많은 수익을 얻고 있었기 때문에 새로운 모델은 위협이 될 수 있었다. 새로운 방식으로 바꾸는 것은 좀 우습거나 아예 불가능해 보였다.
나는 IMS (Information Management System) 에 관하여 말하고 있다. 이는 1966년 IBM에 의해 고안되었다.
IMS는 Saturn V 라는 달탐사 로켓에 사용되었다. Vern Watts 라는 사람이 이것을 설계하는데 모든 것을 바쳤다. 우리는 IBM의 데이터베이스 DB2에 익숙하다. IBM의 유명한 DB2 데이터 베이스는 IMS의 계층적인 데이터모델에 기반한 DB1의 후계자로 유명하다. IMS는 1968년 Customer Information Control System (CICS)과 다른 애플리케이션들의 성공에 기반하여 나타났다. 그리고 현재까지도 아직 이용되고 있다.
그리고 그 이듬해 나타난 것이 새롭고 위협적인 관계형 데이터베이스이다.
IBM의 Edgar F. Codd 박사는 산호세 연구소에 일하면서 관계형 데이터 모델을 논문 “다수의 공통된 데이터 열과 관계형 데이터 모델” 이라는 논문을 통해 발전시켰다. 이 논문은 http://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf 에서 볼 수 있으며 관계형 데이터베이스 관리 시스템의 기본이되고 있다.
Codd의 업적은 IMS의 계층화된 구조와 상반되는 것이었다. 관계형 데이터 베이스를 이해하고 그에 대하여 일하는 것은 IMS사용자들에게는 새로운 용어들을 배우고 매우 친숙하지 않은 것들과 익숙해져야 하는 일이었다. 그것은 이전것에 비하여 어떤 장점들을 가지고 있었다.
이 아이디어들과 애플리케이션은 이후 40년 동안 발전하면서 관계형 데이터베이스는 현재 역사상 가장 성공적인 소프트웨어 어플리케이션으로 평가받고 있다. 한 회사의 소유권있는 소프트웨어로는 Microsoft의 Access 형태로도 쓰이고 있고 그 외 정말 수 테라바이트의 데이터를 다루는 곳에도 각 나라에서 쓰이고 있다. 관계형 데이터베이스는 인보이스, 고객의 기록, 제품 카탈로그, 등등 세계전체를 저장하고 있다. 관계형 데이터베이스가 현대 기술과 비즈니스 영역에서 핵심적인 역할을 할 것이라는 것은 의심의 여지가 없다. 관계형 모델은 IMS에 대하여 각각 그 대치되는 점을 가지고 있고 각각 쓰임새가 있었다.
그래서 “관계형 데이터베이스의 문제점은 무엇인가?” 라는 질문에 대한 짧은 대답은 “없다”일것이다.
하지만 여기서 고려해보고자 하는 긴 대답은 있다. 이 대답은 모든 표면적으로는 모든 것을 변화시킨다는 점에서 좀 더 긴 관점으로 보고자 한다. 그리고 한편으로는 이러한 변화 혁명들이 구조적인 관점에서 비즈니스의 역사에서 흔한 것이라고 볼 수 있다. IMS, RDBMS, NoSQL. 말, 고양이, 비행기. 각각은 이전의 뭔가에 더해서 만들어졌고 각각의 문제점을 해결하고 있으며 각각 어떤 점에서는 장점이 있고 어떤점에서는 그렇지 못하다. 현재까지도 모두 공존하고 있다.
여기서 우리는 Codd가 사십년전에 Information Management System 에 대해 그랬던 것처럼 현재 한 번 관계형 데이터 베이스의 대체될 만한 방안을 생각해 본다면 그것으로 의미가 있을 것이다.
우리는 관계형 애플리케이션이 더 성공적이고 많이 쓰일수록 확장성 문제를 당면하게 된다. 데이터베이스가 일관성을 얻는 방법은 일정부분을 락킹함으로써 다른 클라이언트에게는 해당부분이 유휴하지 않게하는 트랜잭션을 사용함으로써이다. 여기서 락이라함은 사용자가 데이터를 읽고 쓰기등을 하기위해 차례를 기다려야하는 것을 의미하므로 큰 사용자 로드가 있있을 때는 문제가 있기는 하다.
일반적으로 그 문제점을 아래와 같이 정리한다.
메모리 추가, 프로세서 추가, 디스트 업그레이드 등의 문제에 대하여 하드웨어를 던져버려라. 이것은 vertical scaling 이라는 이름으로 알려져있다.
문제가 다시 발생했을 때 해답은 거의 비슷한 것 같다. 한 개의 데이터베이스 클러스터의 장비가 꽉 찼으니 더 추가한다. 일반적 사용이나 대체 작동의 시나리오에서 데이터 복제와 일관성의 문제가 있을 수 있다. 당신이 이전에는 가지고 있지 않던 문제이다.
이제 데이터베이스 관리시스템의 설정을 업데이트해야 한다. 기반이 되는 파일 시스템에 쓰기 동작을 하기 위한 데이터 베이스 채널을 최적화하는 것을 의미한다. 자주 유용하지 않은 로깅이나 저널링을 끈다.
데이터 베이스 시스템에 대한 것 외에 애플리케이션 쪽에도 눈을 돌려본다. 인덱스들을 더욱 개선하기 위해 노력한다. 쿼리를 최적화 한다. 이때 아마도 짐작컨대 인덱스나 쿼리 최적화에 대해서 모르지는 않는다. 그래서 데이터 접근 코드에서 세밀한 튜닝을 하기 위한 기회를 발견하는 것은 고통스런 작업이 된다. 자원이 드는 저장 프로시저의 XML 처리 등 연결을 줄이고 재조합하는 과정을 포함할 수 있다. 물론 짐작컨대 우리는 이유가 있어서 XML 을 사용할 것이고 어디선가 그것을 더 사용해야 한다면 그 문제를 다른 것들을 망치지 않고 애플리케이션 레이어에서 해결할 수 있기를 바랄것이다.
우리는 캐싱 레이어를 사용한다. 좀 더 큰 시스템에서 이는 memcached, EHCache, Oracle Coherence 나 다른 관련 제품들과 같은 분산 캐시를 포함한다. 이는 각 클러스터에서 더 악화된 캐시상의 업데이트, 데이터 베이스상의 업데이트 사이의 일관성 문제를 일으킨다.
이제 어떤 데이터들이 이 데이터들을 접근하는 어떤 쿼리들과 더 비슷하게 보이도록 하는것과 애플리케이션과 쿼리의 경로를 결정하도록 데이터 베이스에 관심을 가져보자. 비정규화라고 불리는 이 프로세스는 관계형 모델을 정의하는 다섯가지 정규 폼과 Codd의 관계형 데이터에 관한 12가지 법칙에 위배된다. 우리는 더 이상 순수하지 않더라도 우리는 어떤 이론적인 클라우드 상에 살지 않고 우리가 받아들일 만한 레벨에서 애플리케이션이 다시 응답하도록 만들기 위해 현실 세계 상에 산다는 것을 상기해야 한다.
이것은 당신에게 좀 친숙하게 들릴것이라고 예상한다. 웹 스케일 상에서 엔지니어들은 이것이 단지 더 빠른 말에 대한 Henry Ford의 문제와 비슷한 문제인지 아닌지 고민하기 시작했다. 그리고 그들은 좀 인상적이고 흥미로운 일들을 해냈다.
우리는 여기서 관계형 모델은 단지 하나의 모델이라는 것을 유념해야 한다. 어떤 문제를 해결하기 위해 세상을 바라보는 한 개의 유용한 관점일 뿐이다. 데이터를 표현하기 위한 유일한 방법인 것은 아니다. 역사를 돌리켜보면 Codd 박사의 모델도 그 시대에는 방해되는 것이었을 뿐이다. “tuples” 같은 새로운 용어를 쓰며 기존의 익숙한 용어도 새로운 방법으로 쓰였다. 관계형 모델은 의심속에서 가치를 깎아내리는 사람들에게 공격받았다. Codd 박사의 고용자인 IBM 자체도 IMS 관련하여 이미 이득을 보고 있었기 때문에 새로운 건방진 놈의 출현을 원치 않았던 것이다.
하지만 관계형 모델은 이제 주장하건대 데이터 세상에서 가장 좋은 위치를 차지하고 있다. SQL은 폭넓게 지원되고 잘 이해되고 있다. 대학교의 소개 강좌에서도 가르쳐지고 있다. 월 $4.95의 호스팅 요금만 내면 인스톨되어 사용할 수 있게 제공되는 공짜 데이터베이스도 있다. 우리가 사용한 데이터베이스는 종종 우리에게 우리 기관내의 구조적 표준에 의해 기술되어 종용된다. 그러한 표준이 없더라도 우리 기관들이 데이터베이스 플랫폼에 어떠한 것을 가지고 있는지 배우는 것이 현명한 일이다. 우리가 개발이나 인트라스트럭처에 가지고 있는 동료들도 상당히 어렵게 얻는 지식원이다.
관성이나 타성에 의하지 않더라도 우리는 몇 년이 지나면 관계형 데이터베이스가 모든 것을 해결해주는 솔루션이라는 것을 알게된다.
그러므로 우리가 진짜 질문해야 하는 질문은 “관계형 데이터가 무엇이 문제인가?” 가 아니라 “어떤 문제를 가졌는가?” 이다.
우리는 우리가 가진 문제에 대하여 적당한 솔루션을 찾았다는 사실을 확인하고 싶다.
관계형 데이터베이스가 잘 해결할수 있는 문제들이 있다. 카산드라 시스템과 같은 비교적 복잡한 시스템에서도 유연한 확장성이 문제가 되는 것은 아닐수도 있다. 어떤 카산드라의 지지자도 그동안 관계형 데이터에 대하여 배웠던 모든 것을 던져버리고 열심히 얻는 그동안의 시스템 관련 지식들을 위협에 처하게 하지는 않는다.
관계형 데이터는 모든 개발자들과 DBA를 지원한다. 그러나 웹의 폭발, 특히 소셜 네트워크의 폭발은 우리가 거기에 해당 하는 어떤 데이터 볼륨들을 다뤄야 한다는 것을 의미한다. 맨 처음 Tim Berners-Lee가 1990년에 웹을 창안할때는 물리 실험실안에서 박사들이 과학 문서를 교환하는 목적이었다. 지금은 물론 모든 사람들이 사용할만큼 웹은 유비쿼터스 해졌다. 그것은 일정부분은 방대한 양의 데이터를 지원해야한다는 것을 의미한다.
그러나 일부 인프라스트럭처는 무게를 버티지 못하기 시작한다.
1966년, IBM과 같은 회사는 사람들에게 자신들의 개혁을 듣게 하는 위치에 있었다. 그들은 문제를 가지고 있었고, 그것을 해결할 수 있는 브레인 파워를 가지고 있었다. 21세기의 두번째 10년차를 들어가는 이 시점에서 비슷한 개혁을 보기 시작했으며 그것은 Facebook, Twitter 같은 젊은 회사들에게서다.
그러므로 진짜 질문은 “어떤 문제를 가졌는가?” 가 아니라 “만약 데이터들이 문제가 아니라면 내가 무엇을 할수 있는가?”이다. 만약 여러분이 쉽게 수백 테라바이트의 데이터 선터에서 오류를 견디고 어려 데이터 센터에 이용가능 하며 일관성과 확장성을 선택한 한 가지 언어에서 가능하다고 하면, 아마 여러분은 그 정도의 확장성과 유용성은 필요없다고 할 것이다. 그리고 현재 상황에서 가장 필요로 하는 조건은 당신이 잘 알기 때문에 최선을 알 것이다.
지금 카산드라와 같은 비 관계형 데이터베이스를 당신에게 사용하도록 하려는 것은 아니다. 다만 카산드라가 어떤 일을 할수 있고 어떻게 작동하는지 등을 알려주려는 것이다. 오직 당신만이 당신의 데이터가 필요로 하는 것을 알수 있다. 지금 당신의 데이터 베이스를 재고려하라는 것은 아니다. 만약 그 데이터 잘 작동하지 않지만 않는다면. 당신의 데이터 베이스를 고려하라는 것이 아니라 당신의 조직을 고려하며 그 미래에 대한 희망과 문제들을 고려하라는 말이다. 만약 가능하다면 당신 비즈니스에 대해 더 많은 정보를 모으겠는가?
카산드라를 현재 당신의 환경에 어떻게 맞출지 묻지마라. 현재 당신이 당신이 가지고 있는 데이터 문제보다 어떤 다른 문제들을 가지고 싶은지 질문하라. 어떤 새로운 데이터들을 가지고 싶은가 질문하라. 당신의 조직에 관해서 어떤 점이 더 알고 이해하고 싶은가?
1.2. 관계형 데이터베이스의 검토
당신이 이미 익숙하다고 해도 관계형 데이터 베이스의 기본 컨셉을 생각해보자. 이렇게함으로써 우리는 웹 스케일에서 필요한 매우 큰 분산 데이터 시스템 그리고 거기에 따라 생긴 트레이드 오프들에 대한 생각들을 고려할 수 있는 기본을 갖게 된다.
1.2.1. RDBMS : 굉장한 것과 그렇지 않은 것들
지난 40년간 관계형 데이터베이스가 그렇게 인기가 많았던 많은 이유가 있다. 중요한 한가지는 기능이 많고 간단한 선언문을 사용하는 SQL이다. SQL은 1986년에 처음 공식적으로 ANSI 표준으로 채용되었다. 그 이후 Microsoft T-SQL, Oracle의 PL/SQL 과 같이 각 회사별 확장을 통해 더 많은 feature 들을 제공하였고 몇 번의 리비전이 있었다.
SQL은 여러가지 이유에서 파워풀하다. 사용자에게 insert, select, update, delete, truncate, merge 등의 데이터 명령을 사용하는 DML (Data Manipulation Language) 를 사용하여 복잡한 데이터 간의 관계도 표현할 수 있게 한다. 당신은 관계형 대수를 통하여 많은 기능도 수행할 수 있다. SQL 은 실행시 DDL(Data Definition Language)를 사용하여 문장 구조를 직접적으로 만들고 바꾸고 할 수도 있다. SQL은 또한 같은 문장을 사용하여 사용자나 사용자 그룹에게 권한을 주거나 삭제할 수도 있다.
SQL은 사용하기 쉽다. 기반 문법은 배우기 쉽고 SQL과 RDBMS는 개념적으로 볼 때 처음 시작하기 어렵지 않다. 새 개발자들도 쉽게 익힐 수 있다. 그리고 문법만이 쉬운 것이 아니라 당신의 데이터 베이스와 일할 수 있는 많은 직관적인 그래픽 툴도 제공한다.
어느 정도는 그것이 표준이라는 이유로, SQL을 통하여 많은 시스템과 RDBMS를 통합할 수 있다. 단지 원하는 애플리케이션 언어의 드라이버만 가지고 잘 동작할 수 있다. 만약 당신이 애플리케이션 언어를 바꾸기로 결정하거나 RDBMS 벤더를 바꾸기로 결심하면 비교적 쉽게 할 수 있다.
1.2.2. 트랜잭션, ACID-ity, 그리고 두가지 단계의 커밋
이미 언급된 기능들에 더하여 RDBMS와 SQL은 트랜잭션을 지원한다. 데이터베이스의 트랜잭션은 Jim Gray가 ACID 프로퍼티를 가진 “상태의 변화” 라고 했다. (http://research.microsoft.com/en-us/um/people/gray/papers/theTransactionConcept.pdf 를 보라). 트랜잭션의 핵심 기능은 수행중에 했던 모든 것을 ROLLBACK을 이용하여 되돌릴 수 있다는 점이다.
ACID 는 트랜잭션이 제대로 수행되었는지 판단 할 수 있는 요소들, Atomic, Consistent, Isolated, Durable의 약자이다.
Atomic
Atimic은 어떤 문장이 수행되었을 때 한 트랜잭션 안의 모든 업데이트는 이 트랜잭션이 성공했다고 불려지기 위해서는 성공해야 하는 것처럼, 모두 혹은 아무것도 아닌 것을 의미한다. 일부분은 성공하고 일부분은 실패하는 업데이트는 없다. 예를 들면 ATM에서 돈을 전송하는 것이있다. 이것이 성공하면 한 계좌에서 돈이 줄어들고 다른 계좌에 돈이 추가 되어야 하는 것이다. 둘 다 성공해야지 나누어 지면 안된다.
Consistent
Consistent 는 데이터가 한 올바른 상태에서 다른 올바른 상태로 이동하면서 읽는 사람은 다른 값을 보지 않는 것이다. 예를 들면 트랜잭션이 고객과 그 기록들을 지우려고 할 때 고객의 primary key를 참조하는 주문 정보를 빠뜨릴 수 없다. 그렇게하면 주문 기록을 읽으려 하는 누군가에게는 inconsistent 한 에러이다.
Isolated
Isolated 는 트랜잭션이 동시에 일어나도 다른 것과 뒤얽히지 않는 것이다. 그러므로 어떤 두 개의 트랜잭션이 동시에 같은 데이터를 수정하려고 한다면, 하나는 다른 것이 끝날 때까지 기다리게 된다.
Durable
트랜잭션이 성공하면 그 수정사항은 없어지지 않는다. 이는 또 다른 트랜잭션이 같은 데이터를 이후에 수정하면 안된다는 것은 아니다. 단지 이것은 쓰는 사람이 다음 트랜잭션을 할 때에 수정사항이 효력이 있다는 것을 장담할 뿐이다.
겉으로 보면 이 사항들은 분명히 바람직한 것들로 보인다. 아마 어느 누구도 데이터 업데이트가 일정 시간동안 다른 사람들이 읽을 수 있도록 견뎌야 하지 않는다고 하지 않을 것이다. 그러나 좀 더 정교하게 관찰한다면 이 프로퍼티를 좀 더 조정하고 컨트롤 하고 싶게 만들것이다. 그리고 무엇보다 인터넷에 공짜는 없고 트랜잭션을 하기 위해 우리가 치르는 대가를 생각한다면 대신할 무엇이 없는지 궁금해질 것이다.
트랜잭션은 로드가 커지면 좀 어려워진다. 뭔가 한곳에서 한 데이터베이스에서 일어나는 것이 아니고 여러 개의 시스템에서 일어나는 분산된 트랜잭션을 관계형 데이터베이스에서 실행하려고 하면 분산 트랜잭션이 무엇인지 설명해야 할것이다. ACID 라는 프로퍼티를 트랜잭션에서 계속 추구하려면 여러 개의 노드에서 작동하도록 트랜잭션 매니저가 필요할 것이다.
여러 개의 호스트에서 잘 작동하도록 하려면 두 단계에 나누어 커밋 (일반적으로 2PC라고 불린다.) 이 필요해진다. 그러나 2PC가 관련된 리소스를 모두 점거하기 때문에 빠른 작동이 필요하다. 일초안에 모든 분산 동작이 끝나기도 하지만 항상 그런 것은 아니다. 어떤 유즈 케이스에서는 여러분이 직접 작동시키지 않는 여러 개의 호스트간의 협업이 필요하다. 여러개의 협업이 필요한 일은 때로는 시간이 걸리기도 한다.
두 단계의 커밋은 멈춘다. 다시 말하면 클라이언트 이전의 트랜잭션이 어떤 자원을 점거하다가 동작을 다하여 반환할때까지 기다려야 하는 것을 말한다. 프로토콜은 죽더라도 노드가 대답할 때까지 기다린다. 트랜잭션 협업 노드에서 타임아웃을 셋팅하여 이것이 더 이상 대답을 안할것이라는 것을 판단할 수는 있다. 그러나 2PC에서는 아직도 무한 루프가 있을 수 있는데 그 이유는 협업 노드에게 트랜잭션을 커밋해도 좋다는 메시지를 보낼 수 있기 때문이다. 그러면 노드는 대답을 보내도록 기다린다. 만약 협업자가 다운되면 이 시나리오에서 노드는 계속 영원히 기다리게 된다.
그래서 이 단점을 해결하기 위해 데이터 베이스 세계는 compensation 이라는 아이디어를 내었다. Compensation 이란 간단히 말해서 웹 서비스에서 어떤 동작이 커밋되어 에러가 발생하면 새로운 동작이 실행되어 올바른 상태로 복귀시키는 것이다.
두 단계의 커밋에 대해 대체 될 수 있는 방법으로 고려되어야 하는 몇 가지 기본이 있다. 이는 트랜잭션이 실패했을 때 에러있는 트랜잭션을 없애고 후에 복구하기 위해 그것을 써내려가는 것을 포함한다. 다른 방법은 통보를 받고 실패한 동작을 이후에 다시 시도하는 것이다. 예약 시스템이나 주식 판매 틱커에서는 이것이 당신의 요구사항을 만족시키지는 못할 것이다. 티켓 판매나 다른 애플리케이션에서는 이것이 받아들일 만 하다.
2PC가 애플리케이션 개발자에게 일으키는 문제점은 부분적 실표시에 큰 latency와 availability의 상실이다. 둘 다 모두 바람직하지는 않다. 그래서 한 기계에서 성공을 볼 만큼 운이 좋았다면 다음으로 여러 대의 기계를 다루고 ACID 프로퍼티를 적용할 수 있도록 해보아야 한다. 당신이 10 혹은 100 혹은 1000대의 데이터베이스 기계를 가지고 있다고 해도, 일관성은 한 노드에서 일하고 있는 것처럼 필요하다. 하지만 쉬운 문제는 아니다.
1.2.3. 스키마
관계형 데이터베이스에 대해 자주 아주 좋은 평가를 받는 것이 그것이 지원하는 풍부한 스키마이다. 당신의 도메인 오브젝트를 관계형 모델로 표현할수 있다. Data Modeler 의 CA ERW 같은 비싼 도구들이 이런 노력을 도와줄 수 있다. 잘 정규화된 스키마를 만들기 위해서 도메인에 존재하지 않던 비즈니스 오브젝트의 테이블들을 만들어야 한다. 예를 들면, 대학교의 데이터베이스는 학생 테이블과 수강목록 테이블 등을 필요로 한다. 그러나 동시에 한 학생이 여러 수강을 하는것도 가능하고 한 수강과목이 여러 학생을 가지고 있을 수 있는 상황 때문에 join 테이블을 만들어야 한다. 이것은 처음에 학생과 수강목록만 가지고 있으려 했던 모델을 변하게 한다. 이 테이블들에 동시에 join 하기 위해서 더 복잡한 SQL 구문을 만들수 밖에 없다. 그래서 join 구문은 더 느려질 수 있다.
적당한 크기의 시스템에서는 이것은 큰 문제가 되지는 않는다. 그러나 복잡한 쿼리와 다수개의 join은 많은 테이블에서 많은 열을 다루다보면 좀 부담스러울 만큼 느려질 수 있다.
모든 관계형 모델이 이 스키마에 다 잘 들어 맞지는 않는다. 지난 10년 동안 좀 인기가 있었던 것은 매우 빠른 스트림에서도 상태 변화를 잘 나타낸 복잡한 이벤트 프로세싱 시스템이다. 어떤 비즈니스 결정을 가능하게 하기위해 관계된 이벤트들 끼리 맥락화 하는 것은 유용하기도 하다. 이벤트 스트림들을 관계형 데이터 베이스의 용어들로 표현할 수도 있지만 이것은 좀 불편한 동작이다.
그리고 만약 당신이 애플리케이션 개발자라면 애플리케이션 오브젝트를 관계형 모델에 매핑하는 많은 ORM 프레임워크와 익숙할 것이다. 작은 시스템에서는 ORM은 아주 유용하다. 하지만 그 자체로서 메모리 확장 필요성이나 여러 가지 매핑코드를 확장해야 하는 애플리케이션 등 그 나름대로의 문제점들은 가지고 있다. 여기 하이버네이트를 사용하여 SQL 코드를 쓰는 방안을 더 쉽게 하는 자바 코드가 있다.
@CollectionOfElements
@JoinTable(name="store_description",
joinColumns = @JoinColumn(name="store_code"))
@MapKey(columns={@Column(name="for_store",length=3)})
@Column(name="description")
private Map
return this.map;
}
//... etc.
물론, 서비스나 XML 기반 애플리케이션들의 확장문서들을 교환하는 것에 항상 관계형 데이터베이스에 매핑하는 것이 분명하지만은 않다. 이것은 문제를 악화시킨다.
1.2.4. 아무것도 공유하지 않는 구조
관계형 데이터베이스를 스케일하는 다른 방법은 당신의 구조를 조각화 하는 것이다. 다른 Web 2.0 애플리케이션과 같이 하루에 수천만 이상의 SQL 쿼리를 다루는 eBay 같은 곳에서 사용되어 좋은 효과를 보였다. 여기서 아이디어는 데이터를 쪼개서 분산시켜서 한 서버에서 모든 데이터를 다루거나 모든 데이터를 복사해서 각 시스템들에 모두 적재시키지는 않는것이다.
예를 들어 관계형 데이터베이스에서 큰 고객테이블을 생각하자. 만약 여러분이 메모리를 추가하고 더 빠른 하드드라이브를 장착하고 계속 성공적인 하여 고객들이 더 많아 졌다면 언젠가는 새 기계들을 추가하는 것을 고려해야 할것이다. 그래야 할 때 당신은 그냥 모든 데이터들을 복사하여 각 기계에 추가할 것인가? 아니면 대신 고객 테이블을 나누어 각각이 각자 자기의 데이터만 갖게 할 것인가? 그래서 클라이언트가 쿼리를 수행할 때 필요한 기계에만 로드가 걸리도록 , 즉 다른 기계에는 로드가 걸리지 않도록 한다.
이렇게 조각화 하기 위해서 당신은 기록들을 정렬하기 위해 좋은 키를 찾아야 한다. 예를 들어, 알파벳 글자에 맞추어 26대의 기계에 기록들을 나누어 담을 수 있다. 이것은 좋은 방법은 아닐 수 있다. Q, Z 와 같은 글자로 시작하는 고객 이름은 별로 없어서 J, M, S 등을 담은 기계들에 비해 그냥 놀고 있을 수 있는 것이다. 어떤 번호에 따라 즉 전화 번호, 아니면 멤버가 된 날짜, 고객이 살고 있는 주 이름 같은 것에 따라 조각화 할 수도 있다. 이것은 모두 당신이 어떤 데이터를 가지고 분산화 할 것인가에 달려있다.
여기 조각화 구조를 이루기 위한 세가지 법칙이 있다.
- 기능에 기반한 조각화
이것은 2006년 이래 eBay에서 Randy Shop에 의해 구별된 구조라는 이름으로 지원되어 점차 성숙한 접근 방법이다. 이것은 한 테이블에 있는 데이터들을 조각으로 나누는 것이 아니라, 별로 관련이 없는 것들을 별도의 데이터베이스에 들어가도록 나누는 것이다. 예를 들어, eBay에서는 고객에 관한 사항은 한 조각에 두고, 상품에 관한 것은 다른 곳에 두었다. 영화 관련 Flixster에서 영화 등급관련은 한곳에 커멘트는 다른곳에 두었다. 이 접근 방법은 깨끗하게 데이터 세그먼트를 나누기 위해 당신의 도메인을 잘 이해하는 것이 필요하다.
- 키에 기반한 조각화
이 접근 방법에서 당신은 데이터에서 그것을 바르게 분산시킬 수 있기 위하여 키를 찾아야 한다. 앞의 예제에서와 같이 한 알파벳의 관련 정보를 한 데이터 베이스에 저장하는 것이아니라 데이터 키의 해쉬를 사용해서 여러 개의 기계에 해쉬에 따라 저장을 한다. 여기서 시간 기반의 해쉬나 숫자값 기반 키를 찾아 해슁하는 것이 일반적이다.
- 룩업 테이블
이 접근 방법에서 클러스터상의 한 노드는 전화 번호부처럼 작동을 해서 내가 억세스하려는 데이터가 어느 노드에 있는지 찾아보게 된다. 이는 두 가지 단점을 가지고 있다. 첫째로 룩업 테이블을 들여다볼 때 마다 퍼포먼스 체크를 해야한다. 둘 째로, 룩업 테이블은 아예 실패하는 지점이 되거나 방해가 되는 지점이 된다는 것이다.
데이터 조각화 전략을 어떻게 사용하고 퍼포먼스도 향상시킬수 있는가 하는 것은 http://lsvp.wordpress.com/2008/06/20 을 참조한다.
조각화는 당신의 전략에 따라서 수평적으로 스케일할 수 있게 해줄 뿐 아니라 더 세밀하게 특정한 조각에 파워를 실을 수 있는 능력을 배양한다.
조각화는 일종의 “아무것도 공유하지 않는” 데이터 베이스라고 할 수도 있다. 아무것도 공하지 않는 구조는 어떤 중앙집중화된 상태가 존재하지 않고 각 노드가 여러 시스템에 분산되어 존재한다. 이 용어는 1986년 버클리 대학에서 Michel Stonebraker가 쓴 “아무것도 공유하지 않는 케이스” 라는 논문에 처음 사용되었다.
아무것도 공유하지 않는 것은 최근에 Bigtable데이터 베이스나 MapReduce에서 아무것도 공유하지 않아 거의 무한하게 확장이 가능한 구조를 사용한 Google에 의해서 발전되었다. 카산드라 데이터베이스는 중앙의 제어장치나 마스터/슬레이브 구조가 있지 않아 모든 노드가 동등한 아무것도 공유하지 않은 구조이다.
“The Case for Shared Nothing” 이라는 논문은 http://db.cs.berkeley.edu/papers/hpts85-nothing.pdf 에서 참조할 수 있다. 페이지 수가 많지는 않다. 카산드라가 사용하는 것과 같은 구조를 볼 수 있을 것이다.
MongoDB 는 또 각 노드간의 동등한 배분과 자동 조각화 능력을 제공한다. 이 비 관계형 데이터베이스들은 많은 능력을 제공한다. 자동으로 데이터 배분 등 기능을 하기 때문에 카산드라 서버를 이해하는 것이 도움이 된다.
1.2.5. 요약
마지막 요약으로 관계형 데이터 베이스는 어떤 일정한 데이터 저장 문제를 해결하는 데는 유용하다. 그러나 종종 스케일 할때는 또 자신 나름대로 문제점들을 안고 있다. 애플리케이션과 데이터베이스에서 비정규화하는 데이터 즉 데이터의 여러 개 복사본을 저장하는 문제등을 해결할 수 있어야 한다. 거기에더해, 금방 문제가 되는 분산화된 트랜잭션 관련 문제도 해결할 방법을 찾아야 한다. 이 문제는 어떤 그리고 고가의 RDBMS에서 직접적으로 해결해 주지 않는다.
그리고 더 중요하게는 RDBMS의 몇몇 약점들이 있어서 스케일링 이슈를 위해서 기능,구조들이 필요하다. 그래서 NoSQL 해결책들이 더 많은 데이터베이스들을 다룰수 있도록 덜 무섭게 보인다.
1.3. 웹 스케일
타고난 디자인 때문에 RDBMS는 스케일하기가 쉽지않으며 웹을 고려사항에 넣었을 때도 쉽지 않다. 더 많은 데이터가 이용가능 해질수록 우리의 기관들은 고객들에게 가까운 시일 내에 더 많은 결정이나 다른 좋은 능력들을 고객에게 줄 수 있기 때문에 우리가 여기서 고려해야 할 것은 웹의 구조뿐 만이 아니다.
우리 모두는 웹이 성장하고 있다는 것을 안다. 하지만 IDC 논문 “확장하는 디지털 세상” 에서 제안하는 숫자들을 고려해보자. (완전한 논문은 http://www.emc.com/collateral/analyst-reports/expanding-digital-idc-white-paper.pdf 에서 볼 수 있다.)
YouTube는 매일 1억개의 비디오를 서비스한다.
Chevron 은 매일 2TB의 데이터를 소비한다.
2006년 인터넷 상의 데이터는 대략 166 exabyte 이다. 2010년, 그 수는 1000 exabyte에 달했다. Exabyte는 1 quintillion byte 즉, 1.1 백만 terabyte이다. 이 숫자들을 좀 현실에 와닿게 보려고 다시 이야기하면, 1EB는 대략 DVD 화질 비디오를 50000 년 동안보여준 데이터양이다. 166EB 는 대략 여태까지 쓰여진 모든 책들의 정보내용에 300만 배정도 한 것이다.
월 마트의 고객 트랜잭션데이터는 2000년 현재110 테라바이트 정도 데이터베이스에 쓰여졌다고 말해진다. 이는 하루에 수천만 트랜잭션이다. 2004년까지 이는 patebyte의 반까지 성장했다.
영화 Avatar는 1PB의 저장 공간을 필요로 했다. 만약 MP3 하나가 32년간 플레이될 길이라면 이와 비슷한 용량이다.
2010년 3월, 구글은 100,000 개의 인터넷 기능을 기본으로 가지고 있는 안드로이드 폰을 생산한다.
이메일 계정은 1998년 현재, 약 2억 5천 3백만개 이다. 2010년 까지 이 숫자는 20억에 가까워 질 것이다.
당신이 볼 수 있듯이 저장되고, 처리되고, 쿼리 되어야 할 데이터의 종류는 그것을 사용하는 비즈니스 만큼이나 다양해진다. 단지 소지점등에 익숙한 고객 데이터나 디지털 비디오 등만 생각하지 말고, 디지털 텔레비전과 폭발적 성장세의 이메일, 메시징, 모바일 폰, RFID, VOIP 등을 고려해보아라. 우리는 이제 지금 영화와 음악을 스트리밍 해주는 Blu-ray 플레이어도 가지고 있다. 우리가 단지 물리적인 소비자 매체 미디어 저장 공간과 그것을 제공하는 컨텐츠 회사 그리고 서드파티 비즈니스만 생각하지 않더라도 매우 확장가능한 데이터 해결책을 필요로 한다. 일반적인 비즈니스 애플리케이션 개발자나 데이터베이스 관리자를 고려해도 우리는 관계형 데이터베이스를 어떤 세계의 중심에 놓고 생각할 것이다. 그리고 어떤 회사내에서도 80%의 데이터가 구조화 되어 있지 않다는 사실에 놀라게 될 것이다.
카산드라와 같은 NoSQL 해결책이 지원하는 스케일의 종류가 여러분에게는 해당되지 않는다고 생각할 것이다. 당신이 카산드라가 해결해 줄만한 문제점을 가지고 있지는 않을 수 있다. 지금 당신에게 카산드라로 변경하는 길을 찾고 데이터가 현재 데이터베이스에 존재하는 방법에 대해 재고려할것을 요구하는 것은 아니다. 그것은 살펴보기 어려운 대가를 가진 힘든 일일 수도 있다. 지금 당신이 가지고 있는 애플리케이션에게 지금 현재의 데이터 베이스가 딱 맞는것이라고 생각하는 것은 매우 분석적인 일이다. 그러나 현재 보다 더 많은 데이터를 다루어야 한다면 데이터베이스에서 어떤 점을 찾겠는가? 그 질문은 내구성, 확장성, 큰 저장공간, 빠른 쓰기 등이 문제가 되지 않는다면 어떤 종류의 애플리케이션을 갖기를 원하는가 하는 것이 될 것이다.
현재 웹 스케일로 동작하고 미래를 바라보는 세상에서 아파치 카산드라는 좋은 대답중 일부가 될 것이다.
1.4. 카산드라 상승 효과
할리우드의 극작가들과 소프트웨어 창업자들은 흔히 각자의 상승 효과를 가지라고 충고를 받는다. 이것은 그들의 상품이 무엇인지에 대한 명확하고 간결한 그리고 몇 분안에 배달가능한 요약이라고 할 수 있다. 카산드라는 당신이 매니저나 동료들에게 보여줄 수 있도록 흥미 진진한 이야기를 가지고 있다.
1.4.1. 카산드라를 50 단어로 말하기
“아파치 카산드라는 그 분산화 디자인을 아마존 Dynamo에 두고 그 데이터 모델은 Google의 Bigtable에 둔 오픈 소스, 분산화된, 중앙집권화 되지 않은, 유연한게 확장가능한, 매우 유용하고, 오류에 적응성이 있으며, 일관적인, 컬럼화된 데이터베이스이다. 페이스북에서 시작되어 지금은 많은 유명한 사이트에 쓰이고 있다.” 정확히 50단어이다.
물론 당신이 당신의 상사에게 이것을 엘리베이터 같은 곳에서 중얼거렸다간 이상한 시선만 받을 것같다. 그래서 아래에서 중요점을 찬찬히 살펴보자.
1.4.2. 분산화된 그리고 중앙집권적이지 않은
카산드라는 사용자에게는 통합된 하나의 환경처럼 보이면서 여러 개의 기기에 분산화 되어서 작동한다. 사실 하나의 카산드라 노드를 실행시키는 데는 한가지 주의할 점이 있다. 그것을 할 수는 있으나 여러 개의 기기들이 카산드라를 실행시키는 이점을 알아야 한다. 그 디자인과 기본 코드는 여러 개의 기기에서 동작하도록 한 것 뿐만 아니라 여러 개의 데이터 센터에서 최적화된 퍼포먼스를 낼 수 있게 되어있다. 당신이 데이터를 클러스터의 어디에 쓰더라도 카산드라는 그것을 확실히 받아들이게 되어있다.
당신이 MySQL 이나 Bigtable 같은 다른 어떤 데이터 저장소를 스케일 하기 시작하더라도 어떤 노드는 다른 슬레이브로 설정된 노드들을 잘 조직화 하기 위해서 마스터 설정이 되어야 한다. 하지만 카산드라는 중앙화 되지 않은 서버라서 모든 노드가 동일하다. 어떤 카산드라 노드도 다른 것과 달리 자신을 집중화는 중앙 기기가 되지 않는다. 그 대신 카산드라는 살이있고 죽은 노드들을 리스팅하는 peer-to-peer 프로토콜 방식을 설정한다.
카산드라가 중앙화 되지 않았다는 말은 어떤 한 지점이 실패의 원인이 되지 않는다는 것이다. 모든 카산드라 노드들은 동일하게 작동한다. 이것은 서버 대칭화 라는 말로 표현되기도 한다. 모든 것들이 같은 동작을 하기 때문에 정의에 의해서 어떤 특별한 호스트가 MySQL이나 Bigtable 등등 처럼 마스터/슬레이브 셋팅을 하면서 조직화하는 활동을 하지는 않는다.
RDBMS와 같은 분산화된 데이터 해결책에서 당신은 퍼포먼스를 향상 시키고 동시에 일어나는 동작을 수행하기 위해서 여러 개의 기기에 데이터들을 복사하여 저장할 것이다. 이 동작은 마스터/슬레이브 관계를 통해서 이루어진다. 이 말은 모든 서버가 같은 방식으로 작동하지는 않는다는 말이다. 당신은 당신의 클러스터에서 한 서버는 마스터 한 서브는 슬레이브 관계로 설정하게 된다. 마스터는 데이터의 소스 역할을 하면서 일방향으로 데이터의 복사본을 동기화해야 하는 슬레이브 노드와 작동한다. 만약 마스터 노드가 오류를 일으키면 전체 데이터 베이스가 위험해진다. 중앙화 되지 않은 디자인은 그래서 카산드라의 핵심 기능이다. RDBMS 세계에서의 마스터/슬레이브 복사 동작을 이해하면서 MongoDB와 같은 NoSQL 데이터베이스들은 마스터/슬레이브 구조를 따라한다.
비중앙집중화는 그래서 두가지 장점을 가진다. 마스터/슬레이브 작동보다 더 간단하다. 모든 노드가 동일하기 때문에 작동시키고 유지하는 것이 더 쉽다. 그래서 특별한 지식이 필요하지 않다. 한 개를 설정하는 것이 50개를 설정하는 것과 크게 다르지 않기 때문이다. 지원하기 위해서 별다른 설정이 필요하지 않다. 게다가 마스터/슬레이브 설정에서는 마스터가 실패의 원인이 될 수 있다. 이것을 피하기 위해서 종종 복잡하게 여러 개의 마스터를 설정해야 한다. 카산드라에서는 모든 복사본이 동일하기 때문에 어떤 한 개 노드의 오류가 서비스 전체를 망치지는 않는다.
요약하면 카산드라는 분산화되고 비중앙화되어 있기 때문에 어떤 한 지점이 오류의 원인이 되지는 않고 높은 유용성을 보인다.
1.4.3. 유연한 확장성
확장성은 퍼포먼스에 큰 나쁜 영향이 없이 더 많은 수의 요청을 처리할 수 있도록 구조적으로 만들어진 시스템의 성능이다. 수직적인 확장성 – 단순히 더 많은 하드웨어와 메모리를 추가하는 것 – 이 가장 쉬운 방법이다. 수평적인 확장성은 모든 요청을 한 기기 받아들일 필요가 없도록 데이터의 전부나 일부를 복사하여 추가하는 것이다. 그러나 소프트웨어는 클러스터 안의 다른 노드들과 데이터들의 싱크를 맞추기 위해 내부적인 메커니즘을 가지고 있어야 한다.
유연한 확장성은 수평적 확장성의 한 특별한 성질로 불릴 수 있다. 당신의 클러스터가 끊김없이 확장하였다가 반대로 축소될 수도 있음을 의미한다. 이것은 중요한 장애나 전체 클러스터의 재설정없이 클러스터가 새로운 노드의 추가를 데이터의 일부나 전체 복사를 받아서 시작할 수 있어야 한다. 당신의 프로세스를 재 시작할 필요가 없다. 애플리케이션 쿼리를 변화할 필요가 없다. 수동적으로 데이터의 밸런스를 다시 맞출 필요도 없다. 그냥 새로운 기기를 추가하면 카산드라가 새기기를 발견하고 작동하도록 할 것이다.
축소한다는 것은 물론 당신의 클러스터에서 어떤 프로세싱 능력을 없애는 것을 의미한다. 당신이 당신의 애플리케이션의 일부를 다른 플랫폼으로 이동시키거나 당신의 애플리케이션이 사용자를 잃고 하드웨어를 없애버리는 일을 할 때 이것을 할 필요가 있을지 모른다. 이러한 상황이 발생하지 않기를 바라자. 그러나 만약 필요해 진다면 전체를 축소하도록 다 뒤집을 필요는 없다.
1.4.4. 높은 사용성과 오류 내구성
일반적으로 구조적인 용어에서 사용성이란 어떤 시스템이 요구에 부합하도록 하는 능력을 말한다. 하지만 컴퓨터는 하드웨어 컴포넌트의 오류에서부터 네트워크 상의 오류까지 여러가지 실패를 경험할 수 있다. 어떤 컴퓨터라도 이런 오류를 겪을 수 있다. 물론 어떤 정교하고 비교적 가격이 높은 컴퓨터는 이런 내부적인 하드웨어 적체나 오류로 인한 통보로 일부 컴포넌트를 교환해야 하는 경우도 있다. 그러나 어떤 천재지변적인 일이나 누구도 이더넷 케이블을 사고로 끊어먹거나 할 수 있고 이로인해 한 데이터 센터가 망가진다. 그래서 일반적으로 유용성이 높은 시스템은 네트워크 된 컴퓨터들에 의해 작동해야 하고 그 소프트웨어도 클러스터 상에 동작하여 오류도 보고 받을 수 있는 능력과 요청을 시스템의 다른 부분에서 수행할 수 있는 능력이 있어야 한다.
카산드라는 상당히 유용하다. 한 데이터 센터가 화재, 홍수 같은 재난을 당하더라도 다운 타임이 거의 없이 다수의 데이터 센터에 데이터를 복제하고 좋은 퍼포먼스를 낼 수 있다.
1.4.5. 조정 가능한 일관성
일관성이라 핵심적으로 읽는 동작이 가장 최근에 쓰여진 것을 읽는 것을 의미한다. 두 고객이 이 커머스 사이트에서 같은 아이템을 쇼핑 카트에 추가 하는 것을 고려해보자. 만약 어떤 사람이 한 물품을 카트에 추가한 후라면 나는 더 이상 그것이 가능하지 않다고 통보를 받아야 한다. 이것은 그 물품의 상태가 모든 노드에서 일관성이 있다면 꼭 일어나야 하는 동작이다.
하지만 공짜는 없고, 이것은 이후에 보게되겠지만 축소,확장 한다는 의미는 데이터의 일관성, 노드의 유용성, 파티션의 내구성 등과 같은 트레이드 오프가 있다. 카산드라는 약간 잘못 의미가 받아들여질수 있지만 결국에는 일관성이 있다고 불려진다. 카산드라는 전체적인 유용성을 보장하기 위하여 약간의 일관성을 희생시킨다. 하지만 카산드라는 좀 더 정확하게 말하면 조정가능한 일관성있다고 말해지는데 이것은 필요한 일관성의 정도를 유용성과 균형을 맞추어 조정할 수 있다는 것을 의미한다.
최종적으로 일관성이있다는 말은 문제가 있다. 어떤 사용자들은 최종적 일관성이 있는 시스템은 사용하기를 주저한다.
최종적 일관성을 깎아내리는 사람에게는 논란은 이런식으로 진행이 된다. 최종적 일관성은 데이터가 정말 중요하지는 않은 소셜 웹 애플리케이션에게는 좋을 수도 있다. 만약 Billy가 아침에 무엇을 먹었다 하는 정보를 엄마에게 보내는 것과 같은 동작은 그렇게 크게 중요하지 않을지도 모른다. 그렇지만 내가 가지고 있는 데이터는 중요하다. 그래서 최종 일관성을 나의 모델에서 제공하기만 한다는 것은 우스울수도 있는 말이다.
Amazon, Facebook, Google, Twitter 같은 모든 유명한 웹 상의 애플리케이션이 이 모델을 사용한다는 것을 별도로 두더라도 거기에는 무언가가 있다. 아마도 이러한 데이터들도 많은 사용자들과 많은 회사들이 사용한다면 이것은 그들의 주상품이기 때문에 중요할 것이다. 보장되고 바로 당장의 완벽한 일관성을 매우 트래픽이 많은 시스템상에서 병렬적으로 운영하며 가능하다고 해도 클라이언트는 그 결과를 원할수 있기 때문에 이것은 어려운 문제이다.
이를 깎아내리는 사람들은 카산드라와 같은 Big Data 데이터베이스들은 최종적 일관성만을 지원하며 다른 분산형 시스템들은 매우 치밀하고 완벽한 일관성을 제공한다고 주장한다. 그러나 세상에 있는 많은 것처럼 이것은 흑백논리로 설명되지는 않는다. 일관성에는 그대신 어느 정도의 단계를이 있으며 진짜 세계에서는 외부 환경에 매우 종속적이다.
최종적 일관성은 여러 개의 일관성에 관한 모델중의 하나일 뿐이다. 그래서 그 트레이드 오프를 이해하기 위해서는 이들을 살펴보자.
- 엄격한 일관성
이는 때때로 순차적인 일관성이라고 불리기도 하며 일관성의 정도중에 가장 엄격한 것이다. 모든 읽기 동작은 가장 최근에 쓰여진 것을 읽는다. 이것은 가장 완벽해보이고 가장 우리가 필요로 하는 것으로 보인다. 이것을 쓰고싶다. 하지만 좀더 세밀하게 들여다보면 어떤 점이 있을까? 가장 최근에 쓰여진 값이라는 점은 좀 더 분명하게 무엇을 의미하는가? 가장 최근에 누구에게? 하나의 프로세서가 있는 기기에서 한 클럭안에 벌어지는 일이어서 별로 문제되는 것은 없어보인다. 그러나 지형적으로 각각 멀리 떨어진 데이터 센터를 운영하는 시스템에서는 이것은 좀 다르다. 이것을 하려면 글로벌한 시계가 얼마나 많은 요청이 어떤 위치에서 얼마나 많은 대답을 원하면서 일어나더라도 모든 동작에 타임스탬프를 찍어야 한다.
- 인과관계의 일관성
이것은 엄격한 일관성의 조금 약한 형태이다. 이것은 한 개의 클럭이 마법적으로 모든 동작을 싱크하고 아무 장애도 일어나지 않는 환상을 그만둔다. 타임 스탬프에
의존하는 대신 인과관계의 일관성은 의미론적인 접근 방법을 택하는데 그것은 어떤 이벤트의 원인을 결정하고 그것이 일관성의 순서를 정하는 것이다. 이것은 읽는 동작이 순서대로 일어난다는 것을 의미한다. 그래서 두 개의 전혀 상관이 없는 동작이 같은 필드에다가 쓰기를 한다면 인과관계상 관계가 없다는 것을 의미한다. 그러나 한 개의 쓰기 동작이 다른 쓰기 동작후에 일어난다면 인과관계상 관련이 있다고 본다. 인과관계의 일관성은 인과관계있는 쓰기동작은 반드시 읽기 동작도 순서대로 일어난다는 것을 의미한다.
- 약한 (최종적인) 일관성
최종적인 일관성은 표면적으로 모든 업데이트가 분산된 모든 시스템에서 퍼져나간다는 것을 의미한다. 그러나 그것이 좀 시간이 걸랄 수 있다는 것을 말한다. 최종적으로 모든 복사본은 일관성을 갖게된다.
일관성, 유용성, 파티션의 내구성을 분산 시스템에서 고려할 때 우리는 단지 두 개의 목표를 추구할 수 있다. (CAP 논리를 19페이지에서 살펴본다). 이 문제의 중심에는 데이터 업데이트의 복사가 있다. 엄격한 일관성을 보장하기 위해서 모든 업데이트는 동작이 복사본을 블락하고 락을 하며 싱크가 맞게 동작하며 각 클라이언트가 기다리게 한다. 이런 디자인의 사이드 이펙트는 오류 동안에 어떤 데이터는 완전히 접근할 수 없다는 것이다. Amazon CTO인 Werner Vogels 가 말했듯이 “대답이 확실치 않은 것을 다루는 대신 데이터는 완전한 대답을 얻을 때 까지는 접근 가능하지 않게 된다.” (Dynamo : 아마존의 매우 분산화된 핵심 가게 http://www.allthingsdistributed.com/2007/10/amazons_dynamo.html, 207).
우리는 클라이언트 동작을 망치지 않기 위해 각 복사본으로 업데이트를 점차적으로 확대시키는 긍정적인 방법을 택할 수 있다. 여기서 좀 어려운점은 우리가 모든 충돌 같은 것들을 미리 탐지하고 해결해야 한다는데 있다. 이것은 디자인 접근 방법에 의해 우리가 이 충돌을 읽기 또는 쓰기 동작시에 해결해야 하는 점을 결정해야 한다. 이것은 분산화 데이터베이스의 디자인자가 시스템을 항상 읽기가능 혹은 쓰기가능하게 만들기 위해서 택해야 하는 방법이다.
Dynamo 와 카산드라는 항상 쓰기 가능한 방법을 선택했다. 퍼포먼스에 이득을 취하기 위해 읽기 동작은 뒤로 미루어준다. 또다른 방법으로는 네트워크나 서버에 오류가 있을 동안에는 업데이트 동작을 하지 않는것이다.
카산드라에서 일관성은 모두 가능하거나 아니면 아예 모두 실행하지 않는 옵션은 아니다. 그래서 클라이언트는 업데이트를 할지 말지 그 복사본의 숫자를 결정할수 있기 때문에 좀 더 정확하게는 “조절가능한 일관성” 이라고 명명한다. 이는 일관성의 레벨을 셋팅해서 정한다.
복사본 요소는 당신이 퍼포먼스를 얼마나 희생하며 일관성을 얻을 수 있는지 결정하게 해준다. 당신은 복사본 요소를 당신의 업데이트가 전달되기 원하는 클러스터 상의 노드의 갯수만큼 셋팅을 해주게된다.
일관성의 레벨은 클라이언트가 모든 동작에 반응하는 것과 얼마나 많은 복사본이 클러스터 안에서 쓰기와 읽기에 대한 반응을 성공적이라고 인식할 수 있도록 결정할 수있게 해준다. 그것이 카산드라가 클라이언트에 대한 일관성을 결정할 수 있게 해주는 곳이다.
그래서 당신이 원한다면 당신의 일관성 레벨을 복사본 요소에 맞추어 주거나 모든 노드가 블록되어서 싱크가 맞게 기다리더라도 일관성을 더 많이 얻게 할 수도 있다. 실제로 이것이 카산드라에서 많이 수행되는 방식은 아니다. 그래서 만약 클라이언트가 일관성 레벨을 복사본 요소보다 낮게 설정했을 경우 몇 개노드가 다운되더라도 업데이트는 성공적으로 보인다.
1.4.6. Brewer의 CAP 이론
우리가 카산드라의 디자인을 이해하고 최종적 일관성있는 데이터베이스라는 개념을 이해하려면 CAP 이론을 이해할 필요가 있다. CAP 이론은 때때로 그 저자인 Eric Brewer의 이름을 따서 Brewer의 이론이라고도 불린다.
버클리 대학에서 일하면서 Eric Brewer는 2000년 분산 컴퓨팅 이론에 대한 ACM 심포지움에서 CAP 이론을 내었다. 이 이론은 많은 수의 분산화 데이터 시스템에서 거기에는 일관성, 유용성, 파티션 내구성이라는 세가지 요구 사항이 있음을 말한다.
- Consistency
모든 데이터베이스 클라이언트는 같은 쿼리의 같이 일어나는 업데이트에서도 같은 값을 읽어야 한다.
- Availability
모든 데이터베이스 클라이언트는 항상 데이터를 읽고 쓸수 있어야 한다.
- Partition Tolerance
데이터베이스는 여러 개의 기기로 나누어 질수 있다. 네트웍상 나누어져서도 그 기능을 다할 수 있어야 한다.
Brewer의 이론은 어떤 주어진 시스템에서 이 세가지 중에서 두 가지는 강하게 지원을 한다. 이것은 소프트웨어 개발에 있어서 당신이 들어봤을만한 “잘 할수있거나, 빠르게 할수 있거나, 싸게 할 수 있거나, 이중에 두가지를 골라라” 라는 말과 비슷하다고 할 수 있다.
서로 간의 의존 관계 때문에 당신은 그 중에 선택을 해야 한다. 당신이 당신의 시스템에서 더 높은 일관성을 필요로 할수록 파티션 내구성은 당신이 유용성을 어느 정도 감수하면서 더 줄어들 수밖에 없다.
CAP 이론은 MIT의 Seth Gilbert과 Nancy Lynch 에 의해 그 후 옳다고 밝혀졌다. 그러나 분산 시스템에서 당신은 네트웍 파티션을 가지고 그것은 어떤 시점에서는 오류가 있고 다른 지점들간 통신을 못하도록 할것이다. 거의 피할 수 없는 패킷 손실도 있다. 이는 우리가 분산 시스템은 네트워크 파티션에서 제대로 동작하기 위해서는 최선을 다해야 한다는 결론에 도달하게 한고 이는 오직 유용성과 일관성이라는 두 가지 옵션만 고를 수 있게 만든다.
다음 그림은 세 가지 모두가 가능한 교차점은 없다는 것을 보여준다.
그림 1 1. CAP 이론은 이 중에 오직 한 번에는 두가지만 가능하다는 것을 보여줌
CAP 스펙트럼에서 비관계형 데이터 저장소가 각각 어떻게 되어 있는지 보는 것이 유용할 수 있다. 그림 1-2는 MongoDB의 CEO이자 설립자인 Dwight Merriman의 2009년 뉴욕 강연에서 영향을 받았다. (http://bit.ly/7r6kRg에서 볼 수 있다.) 내 연구에따라서 조금 변경되었다.
그림 1-2는 여기에서 논하는 몇 가지 다른 데이터베이스들의 일반적인 중점 사항을 다루었다. 이 차트에서의 데이터베이스들의 위치는 설정에 따라서 바뀔 수 있다. Stu Hood가 지적했듯이 분산화된 MySQL 데이터베이스는 구글의 동기화 복사 팻치를 받아야만 일관성있는 시스템이라고 할 수 있다.
CAP 위치에 의한 시스템 디자인은 데이터 저장소 메커니즘의 근원에 독립적이라는 것도 흥미롭다. 예를 들면 CP 변은 그래프 데이터베이스와 문서 기반의 데이터베이스 양쪽에 기반하여 다양화 된다.
그림 1 2. 각각 다른 데이터베이스들이 CAP연속체 상에서 보여주는 모양
이 그림에서 관계형 데이터베이스는 일관성과 유용성 선의 사이에 있고 그것은 네트워크 오류가 있을 때는 실패할 수 있다는 것을 의미한다.
Neo4J 같은 그래프 데이터베이스는 그리고 MongoDB, HBase, Hypertable, Redis 같은 구글의 Bigtable 데이터베이스 디자인이 기반이 된 데이터베이스는 모두 유용성에는 조금 덜 그리고 일관성과 파티션 내구성에는 좀 더 무게를 두었다.
마지막으로 Amazon의 Dynamo의 디자인에 기반을 둔 것은 카산드라, Project Voldemort, CouchDB, Riak 이다. 이것들은 유용성과 파티션 내구성에 더 기반을 두었다. 그러나 이것은 Bigtable이 유용성을 무시했듯이 일관성을 중요하지 않게 처리한 것은 아니다. Bigtable의 관련 문서에 따르면 평균 적으로 어떤 데이터가 쓸 수 없게 되는 퍼센티지는 0.0047% 이다. 이것은 우리가 말한 대로 비교적 매우 강건한 시스템이다.
CAP 이 세가지에서 두가지만을 지원하는 것은 실제적으로 어떤 의미가 있을까?
- CA
주로 일관성과 유용성만을 지원하는 것은 분산화된 트랜잭션에서 두단계 커밋을 한다는 의미가 될 수 있다. 네트워크 파티션이 일어났을 때 시스템이 블록되는것을 의미하며 이것을 완화시키려 할 때 당신의 시스템은 한 개의 데이터 클러스터에 제한된다. 만약 당신의 애플리케이션이 이 정도의 스케일만을 원한다면 관리하기 쉽고 익숙하고 간단한 스트럭처에 의지할 수 있게 할 것이다.
- CP
주로 일관성과 파티션 내구성만을 지원하는 위해서는 당신의 아키텍처를 발전시키기 위해서 데이터 조각을 설정할 수 있다. 당신의 데이터는 일관적일 것이다. 그러나 어떤 노드가 실패하면 데이터 일부가 쓸수없게 되는 위험은 감수해야한다.
- AP
주로 유용성과 파티션 내구성을 지원하기 위해서 당신의 시스템은 가끔 정확하지 않은 데이터를 반환할 수 있다 하지만 네트워크 파티션이 일어나도 항상 시스템은 가용할 것이다. DNS 는 넓게 스케일가능하고, 유용성높고, 파티션 내구성이 있는 시스템의 예가 될 수 있다.
이 그림은 좀 더 폭넚게 이해하는데 도움을 주기 위함이므로 매우 정확하지는 않다. 예를 들어 이러한 연속체속에 구글 Bigtable이 어디에 속하는지 매우 확실하지는 않다. 구글의 논문 등에서는 Bigtable은 매우 유용성높은 것으로 묘사되지만 좀 비대한것으로 보여서 네트워크 이슈등에서는 가용하지 않게된다. 데이터 가독에 대해서는 논문에서 “우리는 같은 데이터의 많은 복사본에 대해서는 고려하지 않았다” 고 되어있다. 마지막으로 그 논문에서는 “중앙화된 컨트롤은 Bigtable의 목표는 아니다” 라고 되어있다.
1.4.7. Row-Oriented
카산드라는 흔히 “column-oriented” 한 데이터베이스라고 불려진다. 그것은 관계형적이지 않고 흔하지 않은 많은 차원의 해쉬테이블상 데이터 구조를 나타낸다. 흔하지 않다는 것은 어떤 주어진 row에 대해서 당신은 한 개나 그 이상개의 column을 가질 수 있다는 것을 의미한다. 하지만 관계형 모델처럼 모든 row가 같은 column을 가질 필요는 없다. 각 row는 고유한 key를 가지며 그것에 따라 데이터가 접근가능하게 한다. 그래서 column-oriented 되었다는 말이 카산드라에 틀리지는 않더라도 3장에서 더 자세히 보겠지만 인덱스된 row-oriented 저장소라고 생각하는 것이 도움이 된다.
카산드라는 다중 차원의 해쉬테이블과 같은 것에 데이터를 저장한다. 그것은 당신이 사전에 미리 데이터 구조가 어떻게 보일지 또 저장하기 위해 어떤 필드가 필요한지 결정하지 않아않 되는 것을 의미한다. 이것은 당신이 처음 시작하고 자주 데이터를 추가하고 바꾼다면 유용하다. 만약 당신이 애자일 개발 방법론을 사용하고 있다면 매력적으로 보일것이다. 만약 당신의 비즈니스가 변화하고 새로운 필드를 추가 또는 제거해야 한다면 카산드라가 그렇게 해줄것이다.
그것이 데이터에 대해 전혀 생각하지 않아도 된다는 것은 아니다. 반대로 카산드라는 그것에 대해 어떻게 생각하는 어떤 전환을 필요로 한다. RDBMS에서처럼 완전히 새로운 데이터 모델을 디자인하고 쿼리를 디자인하는 대신에 쿼리를 처음먼저 생각할수 있고 후에 데이터를 제공하면 된다.
1.4.8. Schema-Free
카산드라는 당신이 키스페이스라고 불리는 외부의 콘테이너를 정의하게 하고 그것은 컬럼 군을 포함하고 있다. 키스페이스는 컬럼군과 어떤 설정들을 가리키는 논리적인 공간일 뿐이다. 컬럼 군은 관련된 데이터들과 정렬방식의 이름이다. 당신은 데이터를 추가하면 되지 미리 컬럼을 정의할 필요는 없다. 비싼 데이터 모델링 툴로 데이터를 모델링하고 복잡한 쿼리를 정의하는 대신에 카산드라는 당신이 원하는 쿼리 모델을 묻고 그 데이터들을 제공할 것이다.
1.4.9. 높은 퍼포먼스
카산드라는 멀티프로세서 멀티코어 기기를 지원하고 이런 여러대의 기기에 만들어진 데이터 센터를 지원하기 위해 디자인 되어있다. 일관적이고 끊김없는 많은 테라바이트의 데이터를 다룬다. 카산드라는 큰 부하가 걸려도 잘 작동하는 것을 보여주었다. 일반적인 워크 스테이션에서도 초당 쓰기 속도의 매우 좋은 결과를 보여주었다. 당신이 더 서버를 추가할수록 퍼포먼스에 지장이 없이 더 좋은 카산드라의 성능을 즐기게 될 것이다.
1.5. 카산드라는 어떻게 생기게 되었는가?
카산드라 데이터 저장소는 아파치의 오픈 소스 프로젝트이며 http://cassandra.apache.org에서 참조할수 있다. 카산드라는 기존의 방법으로는 해결하기가 힘들었던 Facebook의 2007년 인박스 찾기에서부터 시작되었다. 특별히 팀은 메시지 복사 형태의 많은 양의 데이터를 다루고 많은 수의 무작위 읽기와 쓰기에 대한 요구사항이 있었다.
그 팀은 Jeff Hammerbacher에 의해서 Avinash Lakshman, Karthik Ranganathan 등 페이스북 엔지니어들과 검색 팀인 Prashant Malik 등 핵심 엔지니어들에 의해 리드되고 있었다. 그 코드는 구글 코드에 오픈 소스 프로젝트로 2008년 7월에 발표되었다. 처음에는 소수의 페이스북 엔지니어들에 의해서는 업데이트 되었다. 그러나 2009년 3월 아파치로 이동되었고 2010년 2월 17일 탑 레벨 프로젝트로 선정되었다.
Facebook의 Lakshman과 Malik에 의한 “비중앙화된 구조화 저장 시스템” 이라는 논문은 http://www.cs.cornell.edu/projects/ladis2009/papers/lakshman-ladis2009.pdf 에서 참조할 수 있다.
카산드라는 오늘날 어떤 일종의 역설을 나타낸다. 새롭고 급진적이지만 많은 표준과 전통적인 컴퓨터 과학과 컨셉에 의지하고 있다. 카산드라는 실현적인 종류의 데이터베이스이다. 관계형 데이터 모델을 무시하지는 않는다. 기존에 존재하던 툴들이 풀지 못하던 문제들을 해결하기 위해 창조되었다. 이전의 방법들의 제한점을 알고 더 큰 데이터들을 다루기 위해 나타났다.
카산드라라는 이름은 어떻게 생겼을까?
나는 사람들이 자주 이름이 어디서 온거냐고 묻는데 조금 놀란다. 이것은 내가 어떤 프로젝프로 들었을 때 처음으로 궁금해하던 사항은 아니다. 그러나 흥미롭다. 이 데이터베이스에서는 그것은 나름 의미가 있다.
그리스 신화에서 카산드라는 Troy의 Priam 왕과 Hecuba 여왕의 딸이다. 카산드라는 너무 아름다와서 Apollo신이 그녀에게 미래를 볼 수 있는 능력을 주었다. 하지만 그의 접근을 카산카산드 거부했을 때 신은 그녀에게 미래의 모든 것을 정확히 보더라도 아무도 그녀의 말을 믿지 않도록 저주를 내렸다. 카산드라는 트로이가 멸망하는 것을 보았으나 어쩔수가 없었다. 카산드라 분산 데이터베이스는 그녀의 이름을 땄다. 나는 추측컨대 Oracle의 Delphi도 다른 예언자의 이름을 따서 지었다고 생각한다.
1.6. 카산드라의 유즈 케이스
우리는 지금 카산드라의 장점에 대해서 이해하고 있다. 카산드라가 잘 디자인되고 기능이 많지만 모든 일에 대한 적당한 툴은 아니다. 그래서 여기서는 카산드라가 필요한 프로젝트는 어떤 것일지 알아보자.
1.6.1. 많은 디플로이먼트
당신의 드라이 크리닝을 픽업하기 위해 트럭을 몰아보지는 않았을 것이다. 트럭은 그런일에 적당하지 않다. 많은 세밀한 엔지니어링이 카산드라의 높은 유용성, 조절가능한 일관성, 프로토콜, 끊김없는 확장성 등 주요 장점에 집중했다. 이것들중 어떤 성질들도 한 개의 노드만 있는 곳에서는 의미가 없다.
그러나 한 개의 노드만 있는 관계형 데이터베이스가 우리가 필요로 하는 것인 상황도 있다. 그래서 우리가 필요로 하는 것을 미리 가늠해보자. 하지만 몇 개의 관계형 데이터베이스만 가지고도 우리가 원하는 것을 지원할 수 있다면 RDBMS가 한 개의 기기에서는 운영하기 더 좋고 더 익숙하여서 그것이 더 좋은 해결책일 수도 있는것이다.
만약 당신이 몇 개의 노드가 필요하다면 카산드라가 알맞을 것이다. 만약 애플리케이션이 많은 수의 노드를 필요로하면 카산드라는 더 좋은 방법이다.
1.6.2. 많은 쓰기와 통계, 분석
당신의 애플리케이션을 읽기 쓰기의 비율에서 생각해보자. 카산드라는 많은 쓰기에 최적화되어 만들어져 있다.
카산드라의 초기 많은 제품들은 사용자 업데이트, 소셜네트워크 사용, 추천, 애플리케이션 통계 등을 포함한다. 이것들은 카산드라의 좋은 유즈케이스이며 적은 읽기에 비해 많은 쓰기를 포함하고 있다. 사실 애플리케이션의 많은 쓰기에서 좋은 퍼포먼스를 보장하는 것은 카산드라의 주요 장점중의 하나이다.
프로젝트 wiki에 따르면 카산드라는 인덱스화 된 문서와 분산화된 업무 등에 맞는 애플리케이션을 만들기위해 사용되어왔다.
1.6.3. 지정학적인 분산
카산드라는 데이터의 지정학적인 분산를 지원한다. 많은 데이터센터에 데이터를 복사하기도 하는등 설정이 쉽다. 당신이 만약 글로벌하게 분산된 서버환경에 데이터만 사용자 가까이에 두어 많은 퍼포먼스 이득을 보고 싶다면 카산드라가 매우 잘 맞을것이다.
1.6.4. 진화하는 애플리케이션
만약 당신의 애플리케이션이 빠르게 진화하고 당신은 이제 시작하는 중이라면 카산드라는 스키마에 종속적이지 않은 데이터 모델 때문에 잘 맞을 것이다. 이것은 당신이 빠르게 디플로이하는 애플리케이션과 데이터베이스의 보조를 맞추게 해준다.
1.7. 누가 카산드라를 사용하는가?
카산드라는 이 책이 쓰여지는 시점에서 아직도 1.0 릴리즈가 나오지 않은 초기단계이다. 그래픽 툴 같은 편한 도구도 없고 많은 내부적 외부적 디자인에서도 정착되지 않은 점들이 있다. 하지만 그 편리함과 안정성등 때문에 많이 쓰이고 있다.
카산드라를 사용하고 있는 회사들의 리스트는 다음과 같다.
Twitter 는 분석을 위해서 카산드라를 사용한다. 발표된 블로그에서 (http://engineering.twitter.com/2010/07/cassandra-at-twitter-today.html) 트위터의 주 카산드라 엔지니어 Ryan King은 초기 처럼 카산드라를 tweet을 저장하는데만 사용하는 것이 아니라 실시간 분석과 데이터 마이닝등 모든 사용자 기반에 사용한다고 했다.
Mahalo 는 주요 실시간 데이터 저장에 사용한다.
Facebook 은 아직도 나름대로의 방법도 쓰지만 인박스 검색에 쓰고있다.
Digg 주요 실시간 데이터 저장에 사용한다.
Rackspace 는 클라우드 서비스, 모니터링, 로깅에 사용한다.
Reddit은 캐쉬를 위해 사용한다.
Cloudkick은 모니터링과 분석을 위해서 사용한다.
Ooyala는 저장과 거의 실시간 비디오의 분석 데이터를 위해 사용한다.
SimpleGeo는 주 데이터 저장소와 실시간 위치를 위해 사용한다.
Onespot은 주 데이터 저장소의 일부로서 사용한다.
카산드라는 또한 Cisco와 Platform64에 의해서도 사용된다. 그리고 Comcast와 bee.tv 도 개인화된 TV 스트리밍과 웹 그리고 모바일 디바이스를 위해 사용하려고 하고 있다. 많은 다양한 회사들이 카산드라의 유즈케이스가 되고 있고 잘 성공하고 있다. 이 책이 쓰여지는 시점에 가장 많이 사용하는 곳은 Facebook 이며 그들은 150TB 이상의 데이터를 100대 이상의 기기에서 사용하고 있다.
아파치 프로젝트를 설립한 Jonathan Ellis의 Riptano 같은 더 많은 회사들이 카산드라를 여러 가지 프로젝트에서 실제 제품 레벨에 사용하고 있다. 더 많은 기능이 추가되고 편리한 지원 도구들이 생기면 더 많이 사용이 되어질 것으로 보인다.
댓글 없음:
댓글 쓰기