세월이 갈수록 데이터의 양은 늘어난다. 늘어나는 책들 만큼이나 디지털화 된 데이터의 양도 늘어난다. PC통신을 하며, 정액제 전화 요금에 케텔에 접속하던 시절의 네트워크 위의 정보의 양은 '그 날 늘어난 양을 확인할 수 있는' 양이었다. 딱 15년이 흘렀다. 눈 감았다 뜨는 사이에 세상은 이미 데이터의 홍수 속에 뒤덮혀 버렸다.
세월이 다르니 데이터를 이야기하는 방법도 달라졌다. 이제는 데이터가 너무 많아 주체를 못하는 시대이다. 심지어 엘빈 토플러는 '쓰레기지식'이라는 새 말도 만들어냈다. 이젠 데이터는 '있는것' '없는 것'을 넘어'찾을 수 있는 것'과 '그렇지 못한 것' 의 단계에 와 있다. 사실 그것만으로도 모자라 '아는 데이터' 와 '모르는 데이터'의 시대로 넘어가려고 하고 있다.
기술이 발달하면 데이터의 양은 늘어난다. 휴먼 지놈 프로젝트가 시작될 때만 해도 '그 거대한 데이터를 어떻게 다루는가!' 라는 화제가 있었다. 그렇지만 프로젝트가 완료된 지금은 달랑 20여 기가바이트의 지놈 데이터로는 아무것도 알 수 없음을 알고 있다. 그 위에 단백질 구조의 생성과 접힘, 단백질간의 상호작용은 테라바이트의 저장용량을 필요로 하고 있으며, 아직도 끝이 보이지 않는다.
예를 하나 들어보자. 3주 전에 ATLAS의 ABA가 성과물을 내놓았다. 쥐의 뇌의 해부학적인 분석을 완료하였고, 앞으로는 쥐의 뇌과학은 해부학의 영역에서 이론의 영역으로 완전히 넘겨졌다는 이야기가 들리고 있다. 쥐의 뇌의 해부학적 데이터를 얻어낼 수 있을 만큼 얻어내면 얼마나 되는가? 성과물은 600 테라 바이트의 데이터와 8천만장의 사진이다. 10초에 사진을 한 장씩 보아도 열명이 평생을 바쳐야 볼 수 있을 것이다.
이러한 데이터들은 "있으나 무엇인지 모르는" 데이터들이다. 과거에도 이러한 데이터의 종류가 없었던 것은 아니다. 하지만 데이터를 알 수 없는 이유가 통찰의 부족이 아닌 양 자체가 문제가 되는 시대는 이제서야 도래하였다. 지금도 데이터는 계속 쌓여 간다.
*
그럼 이제 컴퓨터 이야기를 해보자. 데이터가 쌓이는 사회의 가운데에는 컴퓨터가 자리잡고 있다. 디지털에 기반을 둔 오류가 (거의) 없는 데이터의 보관과 그 분석을 가능하게 해준다. 분석에 대해서는 데이터 마이닝 (다른 분야들에서는 다른 이름들로 부르지만, 본질은 동일하다) 과 관련하여 다음에 series-analysis와 bioinformatics등과 관련하여 이야기 할 기회가 있을것이니 넘어가도록 하겠다. 이번에는 데이터의 '보관' 에만 집중하여 이야기해 보겠다.
어플리케이션을 위한 DBMS로는 일반적으로 MySQL, MSSQL, ORACLE등을 사용한다. (sqlite의 경우 앞으로의 이야기에 있어서 치명적인 약점이 있어 제외하였다) 어느 도구가 더 좋다고 말할 수는 없지만, 이 모든 도구들이 한계를 명확하게 지니고 있다는 것은 이야기할 수 있다.
지금부터 이야기할 VLDB(very large database를 뜻하는 용어이다) 의 기준은 일반적인 중소/대기업이 사용하는 기준보다 좀 높게 생각하자. 그냥, 지금 느끼는 기가바이트의 느낌으로 테라바이트를 바라봐주면 이후의 이야기를 받아들이고 이해하는데 도움이 될 듯 하다.
VLDB를 위해서는 위의 도구 중 어느것도 좋은 선택이 아니다. MySQL은 인덱스가 2기가를 넘어가면 효율이 굉장히 떨어지니 논의에 끼기도 힘들다. MSSQL의 경우 수십테라 정도의 데이터를 손쉽게 다룰 수 있지만, 준 페타바이트급 데이터를 보관할 경우 (백여 테라바이트) 32기가바이트 메모리 사용 제한에 걸린다. 오라클의 경우에는 꽤 괜찮은 정도로 핸들링할 수 있다. DB2의 경우에도 어느정도 커버가 가능하다.
여기서 각 DBMS가 어떻게 유리한지 정확하게 설명할 수는 없다. 이유는 100테라 바이트 이상의 VLDB의 경우에는 어떤 DBMS를 선택하느냐보다 그 DBMS를 어떻게 설정하느냐가 더 중요해지기 때문이다.
*
크기가 커지면 우선적으로 데이터 I/O를 심각하게 고려해야 한다. 크기가 작은 DB의 경우 추상화를 통하여 편리한 접근을 할 수 있으나, 크기가 굉장히 큰 경우 I/O와 하드디스크의 seek time이 중요한 의미를 가지기 시작한다. 가령, block size를 크게 잡으면 유리하지만 그 크기가 한 번에 하드디스크가 읽어오는 크기보다는 작아야 한다는 것이나, 메모리에서의 카피 시 한 operation cycle에 처리할 수 있도록 해야 한다는 세세한 점들이 굉장히 중요해진다.
1000 테라바이트의 데이터베이스에서 한 번의 쿼리를 주고 1.5 테라바이트의 결과물을 뽑아내는 경우를 상정해 보자. 이 경우 뽑아내기 위한 index가 없는 쿼리를 주면 상상할 수 없을 정도로 느린 성능이 나올 것이다. 그러나 index를 잘 정의해서 주지 않으면 인덱스가 메모리 위에 올라가지도 못한다. 또한, index가 메모리에 올라가 있다고 하더라도 플래터 상에서 데이터가 인덱스의 순차를 따라 위치하고 있도록 조정해야 한다. 성능이 중요한 경우 seek time이 최소화 되도록 사용하는 하드디스크의 특성을 분석하여 데이터를 배치하는 루틴의 작성도 필요하다.
또한 무작위 읽기/쓰기 성능을 고려할 경우 데이터베이스의 설계는 앞에서 설명한 것과 완전히 달라진다. 정말 임의의 무작위 I/O 라면 대응할 수 있는 방법이 없지만, 경향이 있다면 그 경향성을 분석하여 해당 데이터릐 일부를 캐싱해야 한다.
테라바이트 단위의 데이터를 다루기 위해서 사용하는 오라클이나 DB2 말고도 다른 도구를 선택하는 경우도 있다. 특정한 데이터 셋에 맞추어 최적화된 DBMS를 구입하는 방법이 있다. 예를 들어, Sybase의 NYSE 수정판의 경우에는 NYSE TAQ 데이터 (뉴욕 증권 거래소의 거래 데이터) 의 저장 및 분석을 위해 최적화 되어 있다. 앞으로 이런 방식의 data-specific DBMS들은 계속 많이 등장할 것이다. 데이터의 증가량은 컴퓨터의 발전속도보다 빠르기 때문이다.
*
CERN에 건설중인 LHC가 있다. 하드론을 충돌시키기 위한 가속기이다. 여기에 장치된 검출기에서 나오는 데이터의 보관 및 분석을 위하여 CERN은 관련 데이터베이스를 발주하였고, IBM이 수주하였다. 요건은 LHC의 완공년도인 2007년까지 연간 처리량 기준으로 페타바이트 단위 (예상으로는 5~6페타바이트이다) 의 데이터를 실시간으로 보관하고 처리하는 데이터베이스를 개발하는 것이다.
이러한 데이터를 처리하는 방법은 두 가지가 있다. 하나는 데이터를 몽땅 보관하고 분석하는 방법, 다른 하나는 걸러낸 데이터를 압축해서 보관하는 방법이다. 당연히 후자를 택하지 않겠느냐고 생각할 수 있지만, 실험에서 '손실되는 정보' 가 생기는 것은 가장 피해야 하는 일 중 하나이다.
이 경우 데이터베이스 자체보다 큰 문제점이 생기기도 한다. 위에서는 다루지 않았지만 '대역폭'의 문제이다. 실험데이터를 실시간으로 받아 기록할 수 있을 정도의 대역폭을 어떻게 확보할 것인가, 또는 데이터를 디스크에 기록하는 시간이 만들어낼 디스크 대역폭의 한계는 무슨 수로 돌파할 것인가 등의 문제들이다.
*
최대한 간단하게 써 보려고 했지만, 풀어쓰는 것이 힘들다는 것을 느낀다. 이 글을 읽는 분 중 누군가가 정말 VLDB (RVLDB, really very large database)를 개발할 꿈을 가졌으면 한다. 세상에 MySQL이 있으면, 아직 의미를 찾지 못한 이런 "예비 지식"들을 위한 EveryonesSQL도 있어야 하는 법이다. :)
