脫RDBMS에 관한 고민

http://dev.naver.com/projects/neptune

이런걸 써도 되지 않을까 합니다....
물론 써보지는 않았으면 관심은 항상 가지고 있는 ㅡ.ㅡ;;;;
다만, 써먹을 수 있는 날이 올까 하는 ^^;;;;

창피합니다;;
요즘 좀 큰 데이터 셋을 처리하다보니 PostgreSQL을 더이상 고수하기 힘들다는 생각을 하고 있습니다 -.-; 사실 pgsql 뿐 아니라 mysql이나 이런것도 안됨..
평균 1k 정도의 데이터를 수억건을 처리해야 하는 환경입니다. DBMS 입력, 조회, 갱신 테스트 셋이 8억건이고 1억건 정도의 데이터가 디스크 100GB를 소모합니다.
이걸 해결하기 위해서 여러 솔루션들을 고려했었는데 이런저런 이유로 실패했습니다. 조만간 다 정리되면 블로깅하려고 했는데;

보통 DB에 저장되는 데이터는 컨텐츠와 그것들을 연결하는 관계인데 컨텐츠를 저장하는데에 있어 기존의 table 기반의 DBMS에는 한계가 있지 않나 생각합니다. (보조 기억장치를 안쓸 정도로 돈이 많다면 제외;;;)

"전역 key 발급 + multi key-value DB", "대량 갱신을 하는 인덱스 DB", "mysql/pgsql 누적형 인덱스 DBMS"
지금 제가 개발한 환경은 이런 요소들로 되어 있습니다.

"multi key-value DB"의 경우에는 새로운 컨텐츠 생성을 하면 자동으로 unique id를 발급하고 데이터를 저장하고 갱신하고 그런 역할을 합니다.
"대량 갱신을 하는 인덱스 DB"는 기존의 DBMS들이 대량의 row가 변경되는 요청이 잦을 경우 성능상의 이슈들이 있는데 그런 종류만을 처리하는 DB입니다. 이건 mysql heap으로 해봐도 해결 안되더군요. 데이터가 많으니까 3개의 bigint를 가진 테이블의 극히 일부(수천 row)를 변경하는데도 수초가 걸립니다;
"mysql/pgsql 누적형 인덱스 DBMS"는 데이터가 갱신되는 구조를 최대한 피해서 누적만으로 비즈니스 로직이 잘 돌아갈 수 있도록 해서 연결 관계만을 저장합니다.

이렇게 하니까 서비스 전체가 lock free에 가깝게 lock이 작아지고 성능의 병목이 될만한 부분을 거의 없앨 수 있었습니다. 지금도 좀 남아있긴 하지만;;
문제의 인덱스 쪽도 갱신이 있는 부분은 C로 직접 짜버리고 갱신이 안되고 누적만 하는 놈들만 보통의 DBMS를 쓰니까 table/low level lock이라던지 vacuum이라던지에 영향을 전혀 받지 않게 됩니다.

문제라면.. "multi key-value DB"와 "대량 갱신을 하는 인덱스 DB"를 C로 밑바닥부터 다 만들었습니다.. 다른 DB엔진은 전혀 사용하지 않았습니다. 벤치마킹을 직접 여러 종류를 해봤는데 마땅한 게 없다능..
장비는 제한적이고 데이터는 많이 넣어야 되서 메모리가 15~72기가인 머신에서 임베디드 프로그램 하듯이 개발을 했습니다. 예를 들어 데이터 8억건에 해당하는 인덱스를 메모리에 올릴 때 인덱스 구조체 1바이트를 아끼면 파일 캐싱을 위한 메모리를 약 800MB 확보합니다. 이걸 몇 번 하면 장비 한 대를 줄일 수도 있다능;;
링크드 리스트나 트리 등을 이용해 구현할 때도 가장 고려한 것이 메모리를 얼마나 덜 쓰는가? 락이 얼마나 작은가? 두가지 입니다.
시중에 나와 있는(?) 알고리즘이나 솔루션들은 대부분 이런 환경에서 쓸 수 없어지더군요.

그런데 hadoop은 쓸만한가요? key-value 저장소를 만들기 전에 여러가지 솔루션들을 검토했었는데 hadoop은 좀 들여다 보다가 이건 못 쓰겠다 싶어서 제꼈었는데요.
야후 등에서 거대한 사이즈로 쓰고 있는 걸 보면 멀쩡한 걸 제가 걷어찬게 아닌가 생각이 듭니다.

자극을 받아 저도 몇글자 남김니다.
(에고~ 쓰다 보니 길어졌네요. 쯥~ 점심 시간에 한숨 자야 하는데...)

데이터베이스는
"대용량으로 정렬된 인덱스들의 구성과 관리"에 대해서
잘 이해하고 있는 것이 중요합니다.

1970년도에 보잉사의 연구원 이었던,
Bayer와 McCreight가 위의 주제를 가지고 논문을 발표하며,
(논문원제:Organization and Maintenance of Large Ordered Indexes)
수학적인 수식으로 이론을 잘 정립했는데, 이것이 BTree입니다.

이 논문에서
인덱스 검색시간(검색회수) == log (k) I 로 계산됩니다.
여기서, k는 밑수, I는 인덱스수(크기)

k는 저장장치에 의존하며, 하드웨어와 엔지니어의 선택사항입니다만,
log를 수작업으로 계산하기 쉽게 그냥 10으로 생각하면,

인덱스수가 천개이면 10의3승이고 검색시간(회수)는 log 10의3승 == 3.
인덱스수가 백만개이면 10의6승이고 검색시간(회수)는 log 10의6승 == 6.
인덱스수가 십억개이면 10의9승이고 검색시간(회수)는 log 10의9승 == 9.
인덱스수가 일조개이면 10의12승이고 검색시간(회수)는 log 10의12승 == 12.
.... 됩니다.

즉, 자료구조를 BTree로 구현하면, 검색시간(회수)를 log 대수적으로
줄일 수 있다는 것입니다.

그런데, 문제는 k안에 들어가는 자료의 크기입니다.
일상에서, 사람의 정보를 검색할때, 주민번호로 빠르게 검색할 수 있지만,
우리가 원하는 데이터는 주민번호 뿐만 아니라,
주소,전화번호,직업,직장주소.. 심지어.. 가족관계... 이런것입니다.

인덱스로 빨리 찾을수는 있지만,
그 다음은 기억장치와 CPU간의 데이터 교환시간이 중요해집니다.
데이터배치, 파일구조, 입출력 I/O 블럭크기...
이런것을 보통 파라미터 최적화라고 하고, (하드웨어 튜닝)
또한, 쿼리를 어떻게 최적화하는가도 중요합니다. (소프트웨어, SQL튜닝)

그래서, 위의 이론을 상업적인 모델로 제품화 한것이 RDBMS이고,
오라클이 선도적인 역할을 하고 있고,
대용량이고 신뢰성있는 데이터를 처리하고자 할때,
오라클을 선택하는 경향이 있습니다. (물론, 돈이 많아야 합니다. 쯥~)

우리의 토론에서 "소타"님이 언급하신, 아래의 내용은

"전역 key 발급 + multi key-value DB", "대량 갱신을 하는 인덱스 DB",
"mysql/pgsql 누적형 인덱스 DBMS"
...
문제라면.. "multi key-value DB"와 "대량 갱신을 하는 인덱스 DB"를
C로 밑바닥부터 다 만들었습니다..
(엄청 기술적인 부분이고, 많은 노력이 들어간듯 합니다)

근데, 아주 특수한 사업모델인듯 합니다.
제가 느낀 바로는 검색엔진 데이터 처리라 느껴지는데요.
검색엔진은 인덱스로 파일을 찾아서, 파일 I/O를 빨리하여,
파일안에 있는 데이터를 빨리 표시해 주면 되리라 봅니다.
문제는, 파일안에 들어 있는 데이터들을 관련짓고, 데이터 마이닝등을 하려면,
RDBMS 방식으로 접근해야 하는데, 이것을 구현하는 것이 만만치 않습니다.

그래서, 그냥 돈좀 투자해서, RDBMS를 사는 것이고,
우리나라는 이곳에 돈을 많이 소비하고 있습니다.

20000할까 합니다.
암튼 DBMS연구가 활발히 이루어져서, 오라클을 능가하는 것도 나왔으면 좋겠습니다.
위와 관련하여, 다양한 의견으로 토론하는 것도 좋네요~

From:
*알지비 (메신저: rgbi3307(at)nate.com)
*학창시절 마이크로마우스를 만들었고, 10년동안 IT관련 개발자로 일하고 있음.
*틈틈히 커널연구회(http://www.kernel.kr/) 내용물들을 만들고 있음.
*((공부해서 남을 주려면 남보다 더많이 연구해야함.))

학계에서도 최근 다양해 지는 요구들(페타 바이트 스케일의 대용량 데이터 또는 스트림데이터등의 저장 및 처리)에 대한 RDBMS의 부적합함을 지적하고 다양한 대안을 내놓고 있는 것 같습니다.

“One Size Fits All”: An Idea Whose Time Has Come and Gone
www.cs.brown.edu/~ugur/fits_all.pdf

The End of an Architectural Era (It's Time for a Complete Rewrite)
http://db.cs.yale.edu/vldb07hstore.pdf

(글을 다 쓴 다음에 윗분 링크를 따라가 봤는데 제가 드린 링크의 논문들이
윗분이 링크한 글의 토픽이 시작되는 논문들입니다.)

처리하고자 하는 데이터셋 자체의 성격을 구분해야 할 것으로 보입니다. 기존의 "비즈니스" 수요에서는 RDBMS 튜닝만으로 충분한 성능을 낼 수 있지만, twitter 같은 곳에선 이미 RDBMS만으로는 성능의 한계에 도달했을 겁니다. 자체적으로 메모리에 바로 캐시하는 레이어를 여러 개 두고 있다고 알고 있습니다.

그리고 여기서 scalability라는 것은 "구조의 변경 없이 규모가 확장될 수 있는 특성"을 뜻합니다. RDBMS의 경우는 아무래도 추가적인 튜닝과 여러 설계 기법들이 계속해서 적용되어야 합니다. 처음부터 100% scalable한 table 구조를 만들기는 힘들지 않을까요?

Scalability도 자세히 들어가면 vertical/horizontal로 구분하는데 전자는 하드웨어의 성능을 올리거나 소프트웨어를 최적화하는 것으로 얻는 걸 말하고, 후자는 구글이 취하는 방식처럼 기존의 구조 변경 없이 병렬적으로 하드웨어를 추가하여(새 머신을 사서 연결만 하면 되는 식) 얻는 방식을 말합니다. 위에서 replication 이야기가 나온 것은 후자의 방식을 RDBMS에 적용했을 때 그 유연함에 한계가 있다는 뜻인 것 같습니다.

여기서 생각할 것은 전세계를 대상으로 하는 웹서비스를 구축할 때 RDBMS가 과연 scalable하냐는 문제입니다. 그리고 query의 복잡도나 table 설계 같은 이슈보다 data 자체의 양이 월등히 많아지는 경우를 이야기하는 것 같습니다. 분명한 건, 검색엔진과 같은 특수한 분야만 이러한 scalability를 요구하는 것이 아니라 일반적으로 생각할 수 있는 웹서비스에서도 그런 특성이 필요해지기 시작했다는 점입니다.

ps. Hadoop을 회사에서 써보고 있는데, map-reduce 프로그래밍 모델도 언뜻 간단해보이지만 실제 코드로 구현하려면 적응 시간이 좀 필요합니다. 보통 한번의 MR만으로는 실제적인 응용을 하기 힘들고 여러 개의 MR을 chaining해서 사용합니다. 성능을 올리는 데 가장 중요한 문제는 data locality인데 분산 처리할 때 데이터를 각 노드로 뿌리는 것 자체가 비용이 높기 때문에 이 문제를 어떻게 해결할 것인가가 열쇠입니다. Hadoop 같은 시스템은 데이터 자체를 64MB나 그보다 큰 단위의 block으로 쪼개어 여러 곳에 중복·분산 저장해놓고 해당 데이터를 사용하는 연산 알고리즘을 해당 block이 존재하는 노드에서 돌아가도록 하는 방식을 취하고 있죠.

하지만 이것을 서비스로 구현할 경우 엄청나게 큰 데이터를 어떻게 네트워크를 통해 그런 서비스에 업로드/다운로드할 것이냐는 문제가 있는데, Amazon EC2/ElasticMR의 경우 아예 DVD를 굽거나 하드디스크 통째로 Fedex로 받아 클라우드에 올려주는 서비스를 제공하고 있습니다. -_-;

처음엔 제한적인 장비를 준다고 해서 기껏 DBMS 두종류랑 하이브리드 세션 풀러까지 맹거 놓으니
듀얼 옥타코어, 메모리 72기가 장비를 3대 줍니다. 그 중 한대는 RAID0로 묶인 1TB SSD군요.....

ㅅㅂ 고생은 고생대로 하고 ㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠ
그래도 좋다능 -.-;