脫RDBMS에 관한 고민

hongminhee의 이미지

여기 계시는 소타 님 앞에서 말하긴 부끄럽지만 저도 PostgreSQL을 참 좋아합니다. 회사에서 Oracle을 헤비하게 사용하고 있는데, 회사 업무를 할 수록 PostgreSQL이 좋아지더군요. 회사 일과 상관 없이 취미로 서비스 하나를 만들고 있고, 이것도 PostgreSQL을 사용했습니다. PostgreSQL에만 있는 기능을 많이 쓰는 편이구요. 음 여기까지는 잡담;

RDBMS가 과연 scalable하냐는 것에는 여러가지 말들이 많겠지만, 제 생각에는 RDBMS보다는 좀더 심플한 key-value storage가 더 scale하기 쉽지 않겠냐 생각합니다. 뭐 여기 계시는 분들은 경험도 많으시고 RDBMS로 얼마든지 규모 확장하는데 어려움이 없으신 분들도 계시겠지만요. 얼마 전 훈련소에 있을 때 뒤늦게 Google의 MapReduce, Bigtable 페이퍼를 읽었어요. 원래 RDBMS에 회의적인 상태에서 읽어서인지 (그리고 읽을 것 없는 훈련소에서 열심히 읽고 또 읽고 해서일지도;;) ‘아 역시 남자라면 GFS 같은 클러스터링 파일시스템 위에서 Bigtable 같은 것도 굴려보고 해야해… 근데 받들어총 20분은 너무 힘들다…’ 이런 생각이 들더라구요. 지금 운영하는 서비스는 PostgreSQL을 pgpool-II로 이중화해서 운영중인데, Bigtable 본 다음엔 전체 데이터의 사본을 서버마다 두는 방식이 무식하게 느껴집니다. (Bigtable은 chunk 단위로 최소 몇개의 replica를 클라우드 위에 흩어놓지 않나요? 논리적으로 연관된 레코드는 물리적으로도 지역성을 보장받는 식으로 성능을 올리고… 저도 잘 몰라요;;)

몇달동안 CouchDB부터 시작해서 Amazon SimpleDB 같은 서비스도 찾아보고… 참 여러가지를 찾아봤는데 마음에 드는 것은 딱히 없고. 운영하는 서비스는 크지도 않은데, 뭐 싸이월드마냥 대박낼 수 있는 것도 아니면서 규모가변성으로 고민하는 건 김치국 마시는 것밖에 안되지 않나 하는 생각을 했어요.

횡설수설.

음 그러니까 사실 제 고민은 ‘예쁜 프로젝트 호스팅 사이트를 만들고 싶은데 데이터베이스를 어떻게 해결할까’ 뭐 이런 겁니다. 글이 쓸데없이 길어진듯… 좋은 해결책 있으면 추천해주세요. 구체적으로 어떤 DBMS가 좋더라 하는 것도 괜찮고요, PostgreSQL 쓰면서 이렇게 이렇게 하면 좋다… 이런 것도 좋구요.

hongminhee의 이미지

올리고 보니 제목도 엉뚱하고 내용도 토론을 가장한 질문인듯;

홍민희 (VLAAH, LangDev)

creativeidler의 이미지

네이버 검색의 하루 검색 건수가 대략 2억 건 가까이 됩니다. 2억건이면 하루가 86400초니까 대충 10만 치면 대략 2000 tps 정도 처리할 수 있으면 됩니다. 서버 한 대로 200 tps 정도는 별로 무리해서 튜닝하지 않아도 낼 수 있죠. 즉, 네이버 검색의 10분의 1 정도로 사용자가 밀려들지 않는다면 서버 한 대로 뭐든 대충 때려 박아서 만들어도 된다는 얘깁니다. RoR이든 Django든 자바든 PHP든 MySQL이든 SQLite든 대충 집어넣어도 성능 나옵니다.

그리고, 사용자가 정말로 네이버 검색의 10분의 1 정도를 넘어선다면? 그러면 아무 광고나 붙여도 서버 운영비는 뽑을 수 있을 겁니다. 그 때부터 성능 고민 들어가면 됩니다. 그 전까지는 bigtable도, mapreduce도 key value storage도 필요 없습니다.

물론, 현실적인 요구와 상관 없이 학문적인 호기심, 또는 연구 욕구로 인해서 공부를 해보겠다는 거라면 그건 그거 나름대로의 가치가 있겠지만요.

hongminhee의 이미지

네. 사실 저렇게 잘될 가능성은 낮겠죠. 결국 호기심이 이유인데 규모가변성은 핑계;;

홍민희 (VLAAH, LangDev)

oomymy의 이미지

말씀하신 바도 맞습니다만, 동시 접속자 수만 생각하신 것 같군요.

Bigtable과 같은 기술이 풀고자 하는 문제는 무엇보다 High availability(고가용성)와 Scalability입니다. 여기서 scalability는 동접수 뿐만 아니라, 데이터의 규모, 배치작업의 규모 확장성도 함께 포함하는 의미이지요.

만일 기획하는 서비스가 동접은 크게 많지 않을 수 있는데, 데이터가 무척 크거나, 혹은 데이터가 앞으로 계속 커질 전망이다 싶으면 처음 단계에서 부터 저장소를 잘 선택해야죠. 나중에 문제터지면 바꾸면 된다고 생각하는 건 좀 naive한 생각이라 봅니다.

monovision의 이미지

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

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

hongminhee의 이미지

사실 HDFS + HBase 같은 조합도 생각해봤는데, Java 스택이 제겐 부담스럽더라구요. 잘 모르고, 좋아하지도 않고요.

홍민희 (VLAAH, LangDev)

소타의 이미지

창피합니다;;
요즘 좀 큰 데이터 셋을 처리하다보니 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 확보합니다. 이걸 몇 번 하면 장비 한 대를 줄일 수도 있다능;;
링크드 리스트나 트리 등을 이용해 구현할 때도 가장 고려한 것이 메모리를 얼마나 덜 쓰는가? 락이 얼마나 작은가? 두가지 입니다.
시중에 나와 있는(?) 알고리즘이나 솔루션들은 대부분 이런 환경에서 쓸 수 없어지더군요.

winner의 이미지

http://www.ibm.com/developerworks/kr/interview/2009_06.html

RDB를 창안한 Edgar.F. Codd 의 논문을 보면 결국 자료관리에 대한 안전성을 이야기하는 것으로 보입니다. 복잡하게 얽혀있는 자료들을 어떤 식으로 정리해서 쉽게 다룰 것인가? 그리고 함부로 자료를 다루지 않게 하려면 어떻게 해야 하는가? 그것이 그의 고민이었던 것으로 보입니다. 결국 자료를 다루는 방법은 매우 쉽게 이루어져야 하고, 자료관리 전문가를 소수 두는 것이 적합하다는 것이 그의 주장이라고 생각합니다.
그후 질의 최적화에 대한 연구가 많이 이루어진 것으로 아는데, 현재의 대용량 처리는 과거와는 확실히 다른 느낌입니다.

DB 전공한 친구는 RDB를 상당히 신뢰하더군요. DB 모델을 설계하기 전에 적절한 서버 세팅만으로 20배 성능을 향상 시킨바가 있다고 하네요. RDB 자체의 성능에 대해서 반응속도라면 다른 이야기를 해볼 수 있지만 RDB가 throughput은 훌륭하다고 이야기하더군요.

NDB와 OODB에 대한 연구를 좀 하면 idea가 떠오르지 않을까 싶네요.

hongminhee의 이미지

성능도 문제지만, 그보다는 scale하기 쉽냐(scalability)가 문제겠죠. 대부분의 RDBMS들은 master-master replication 수준 이상의 해결책을 제시하지 못하는 것 같습니다.

홍민희 (VLAAH, LangDev)

winner의 이미지

규모가변성? 하여간 규모가변성으로 용어를 통일해서 규모가변성이라고 한다면 저는 일단 떠오르는게 성능이라... replication이라면 가용성을 말씀하시고 싶으신 건가요?

제가 각 용어의 연관관계를 정확히 파악하지 못하겠네요.

기존 RDB들의 분산환경지원은 가용성에 초점을 맞추는 것으로 알고 있습니다. Oracle 10g, 11g 처럼 g자 붙은 녀석들이 그렇죠.

친구의 주장에 의하면 하드웨어 시스템과 운영인력을 고려해서 Active-Standby 를 염두해야 하는데 우리나라에서는 Active-Active 만 생각하는 경향이 크다는 이야기를 했죠.

Replication도 Active-Active 상황에서 이야기하는 것 같은데요.

Software가 아닌 System Engineering에서 해결책을 제시하고 있는 것이 아닌가 싶어요.

소타의 이미지

master-master repl은 보통 multi master라고도 하는데 이건 그냥 간단히 말하면 DB서버 farm에 서버를 갖다 붙이면 붙이는 족족 거대한 DBMS 덩어리가 되게 하는 건데요. 이게 된다고 하는 놈들이 있습니다. 이건 이중화 측면의 active-active 라기 보다는 클러스터입니다.
DBMS쪽에서 사실 클러스터라고 해봤자 "리플리케이터들 - 노드들 - 로드 밸런서들" 구조가 대부분입니다. (노드를 늘려서 규모를 확장하고 로드 밸런싱을 통해서 가용성을 확보하고 뭐 그런건데 이것도 결국 한계가 있다능..)
그리고.. 자원의 많은 부분을 이런 체제 유지에 까먹고 있는거고.. 소프트웨어도 비싼데 장비에 들어가는 돈도 아까울 뿐이고~

소타의 이미지

저도 RDB를 신뢰하고 있습니다. 결국 사이즈가 커지다 보면 여러가지 시스템을 엮어서 거대한 RDB같은 모양을 만들게 되는 것 같습니다.
key-value DB 가 저장 레이어, RDB가 분산된 인덱스, 전역 lock 서버가 트랜젝션을 처리하는 구조가 되는 것 처럼요.
보통의 RDBMS는 해당 장비/소프트웨어가 처리할 수 있는 한계를 넘어서면 그 데이터 구조를 버리지 않고서는 더 큰 규모로의 확장이 쉽게 이루어지기 힘들다고 생각합니다.

소타의 이미지

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

hongminhee의 이미지

저도 사실 그런 이야기들이 궁금해서 글을 썼는데요. 궁금합니다 저도.

홍민희 (VLAAH, LangDev)

소타의 이미지

댓글 쓰기 버튼 누르고 나서 고민했습니다... hadoop가지고 또 쌈나는거 아닌가? ㅎㄷㄷㄷㄷㄷㄷㄷ

죠커의 이미지

일단 개념적으로는 되는데 실제로는 성능상의 문제로 부적당한 경우들이 종종 있는 듯 합니다. 특히 map reduce와 같은 기능들은 좀 많이 느리더군요.

- 죠커's blog / HanIRC:#CN

rgbi3307의 이미지


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

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

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/) 내용물들을 만들고 있음.
*((공부해서 남을 주려면 남보다 더많이 연구해야함.))

From:
*알지비 (메일: rgbi3307(at)nate.com)
*커널연구회(http://www.kernel.bz/) 내용물들을 만들고 있음.
*((공부해서 남을 주려면 남보다 더많이 연구해야함.))

rgbi3307의 이미지

오라클 SQL 튜닝을 시작하시는 분이 있다면,
혜지원의 "오라클실무활용SQL튜닝"이라는 책을 추천합니다.
교보문고,강컴.. 등의 인터넷서점 사이트에서 위의 검색어로 찾아보시면 됩니다.
참고로, 제가 집필한 것입니다. 책홍보가 됐네요(^^)

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

From:
*알지비 (메일: rgbi3307(at)nate.com)
*커널연구회(http://www.kernel.bz/) 내용물들을 만들고 있음.
*((공부해서 남을 주려면 남보다 더많이 연구해야함.))

winner의 이미지

역사적 시간순서를 맞춰본다면 Codd가 relational model 자료관리에 대해서 논문을 쓴 것이 1~2년 앞섭니다.
제 생각에 B tree는 relational model에 한정되어서 활용하는 것은 아닌 것 같고요.
아마 Filesystem에서도 쓰죠.

달리 이야기하자면 Codd의 relational model 자료관리의 강한 지지대 역할을 한 것이 B tree 였을 거라고 추측합니다.
Codd가 IBM에서 relational model 이야기 할 때 IBM은 NDB를 판매하고 있었고, 동료들도 반대를 많이 했다더군요.
제 생각에 큰 이유 중 하나가 성능이었을텐데 그 문제를 B tree index가 많이 해소해 주었을 거라고 봅니다.

winner의 이미지

http://kldp.org/node/106673 중 wooil 님이 올리신
The End of a DBMS Era 도 흥미롭습니다.
http://langdev.net/post/305

아직까지는 여기에 대한 사업모델을 만들기는 어렵긴 합니다.
Agile DB 설계를 생각해보죠. 계속해서 자료의 구조가 바뀐다면 그것은 분명 RDB가 적합하지 않을지도 모릅니다.
그래서 DB의 agile 접근이 어렵다는 이야기가 나오니까요.

하지만 DB의 운영도 자료구조를 유지한다는 것이 쉬운 일이 아닙니다. 사업규모로 도달한다고 하더라도
자료구조는 계속 바뀌어야 하죠. 그래서 숙련된 기술관리자가 필요합니다.
이런 부분의 고민을 새로운 S/W 아키텍처로 해결해볼 실마리가 생길지가 궁금하네요.

hongminhee의 이미지

확실히 schema-free(schemaless)한 데이터베이스가 RDBMS보다 변화적응성은 더 좋은 것 같습니다.

홍민희 (VLAAH, LangDev)

소타의 이미지

전에는 pgsql에서 테이블 만들고 view 만들고 rule/trigger 붙여주고 그랬는데 테이블에 필드 하나 추가할 때마다 view도 새로 생성해야 하고.. (8.4에서는 alter view로 이젠 된다능..) 여튼 개고생 많이 했는데요.
key-value 로 바꾸고 나서는 schemaless하니까 필요한 데이터는 넣고 없으면 안넣고 너무 편합니다..
꼭 schemaless가 key-value여야만 하는건 아니지만;; >_<

rgbi3307의 이미지

헉~ 영어네요~
더구나, 글 날짜가 2009년 6월 30일이네요~
따끈따근한 정보 인듯...

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

From:
*알지비 (메일: rgbi3307(at)nate.com)
*커널연구회(http://www.kernel.bz/) 내용물들을 만들고 있음.
*((공부해서 남을 주려면 남보다 더많이 연구해야함.))

winner의 이미지

http://langdev.net/post/305

http://cacm.acm.org/blogs/blog-cacm/32212-the-end-of-a-dbms-era-might-be-upon-us/fulltext
을 보라고 할 생각이었는데...

그나저나 CACM 도 요새는 blog를 글이 올라오는군요. Tim Berners Lee 의 꿈이 이뤄지는 것인가?

c0d3h4ck의 이미지

학계에서도 최근 다양해 지는 요구들(페타 바이트 스케일의 대용량 데이터 또는 스트림데이터등의 저장 및 처리)에 대한 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

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

FIFO의 이미지

뭐 어차피 검색엔진류 개발이신듯 하니 table partition을 논해봐야 좀 헛발질인듯 합니다만
scale 문제를 논하는데 table partition부터 고려해보고 넘어가야 순서가 아닐까 싶네요

daybreaker의 이미지

처리하고자 하는 데이터셋 자체의 성격을 구분해야 할 것으로 보입니다. 기존의 "비즈니스" 수요에서는 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로 받아 클라우드에 올려주는 서비스를 제공하고 있습니다. -_-;

aero의 이미지

해외에서도 이런 고민이 좀 있는듯 하더군요.
뭐 이런 것들을 두고 여러가지 논란이 있는 것 같기는 합니다만.

참고할만한 링크들
http://blog.oskarsson.nu/2009/06/nosql-debrief.html
http://nosql.eventbrite.com/
http://natishalom.typepad.com/nati_shaloms_blog/2009/07/no-to-sql-anti-database-movement-gains-steam-my-take.html

hongminhee의 이미지

요즘 NoSQL movement 얘기를 많이 보는 것 같습니다.

홍민희 (VLAAH, LangDev)

NoBrain의 이미지

전 Hadoop 때문에 고생 좀 해봤습니다. 이게 쓸만한건지 아닌지 확인을 해야 한다며 하드웨어부터 네트워크 등등을 바꿔가며 이런저런 테스트를 해봤습니다.
결론은 스토리지로 사용하기에 그럭저럭 괜찮다는 겁니다. 복사본을 저장하려면 스토리지 쪽에서 네트워크 트래픽이 복사본 수만큼 생깁니다. 파일을 가져오는데는 노드의 수만큼 성능이 좋아집니다. 하지만 나머진 하드디스크의 IO에 영향이 크다고 생각하시면 됩니다. 문제는 하드디스크 IO가 별로라는 겁니다. 때문에 노드가 많아질 수록 스토리지의 성능은 증가하게 됩니다. 하드디스크의 IO가 분산되닌까요.
DB문제는 좀 어렵습니다. HBase라는게 있는데 완전 느립니다. 이게 뭐 특수한 상황을 위한 DB이기 때문에 속도가 늘 문제가 되는 것은 아니지만 일반적인 상황에서는 매우 심각한 문제가 있습니다.

결론은 Hadoop은 특수한 경우를 위한 솔루션입니다. 일반적인 목적은 대량의 데이터 처리입니다. 하지만 웹을 위한 스토리지라면 약간 고민을 해봐야 합니다. 이미지나 글들을 저장하기 위한 스토리지라면 괜찮다고 생각됩니다. namenode의 성능이 문제지만 괜찮은 서버를 사용하면 어느정도 쓸만할 것 같습니다. 하지만 데이터베이스 문제라면 다른걸 사용하라고 하고 싶습니다.

저도 요즘 비슷한 고민을 하고 있습니다. 제가 내링 결론은 이미 만들어진 솔루션으로 현대에 요구되는 스케일을 만족시킬 수 없다는 것입니다. 뭔가 새로운 것이 필요하다는 것입니다.
하지만 이런 요구가 모든 사이트에 필요한 것은 아니며 대부분의 사이트는 현재 존재하는 솔루션으로 모두 커버 가능합니다. 몇몇 포털이나 쇼핑몰 같은 경우가 해당 되겠지만 이런 곳은 이미 돈으로 상용 소프트웨어와 하드웨어로 어느정도 처리했습니다. 그럼에도 불구하고 네이버 같은 곳은 트레픽에 신경을 곤두세우고 자신들만의 플렛폼을 만들고 있을 것입니다. 이미 Hadoop같은 솔루션은 테스트 완료했고, 어떤 분야에서는 사용하는 곳도 있겠죠.
이런 요구에 충족하는 오픈소스 솔루션은 아직 없는 것 같습니다. 제 생각에 웹관련 플렛폼을 오픈소스로 만들어 보는 것도 좋을 것 같습니다. 개인적으로 고민은 있지만 이전 직장에서 비슷한 일을 했고, 경업금지협약서 같은걸 썼기 때문에 실천하기 위해서는 좀 시간이 필요합니다. 때를 기다리고 있습니다.

참고할 만한 사이트입니다.
http://highscalability.com/

hongminhee의 이미지

저도 highscalability.com을 구독하고 있는데, 정말 다양한 시도들이 있더군요. 도움이 많이 되는 것 같습니다.

홍민희 (VLAAH, LangDev)

죠커의 이미지

홍양은 당분간 KLDP의 마스코드가 되실듯 =3==3

- 죠커's blog / HanIRC:#CN

hongminhee의 이미지

서버/인프라를 지탱하는 기술(サ一バ/インフラを支える技術: 24時間365日)이라는 책이 번역되어 있네요. 혹시 이 책 읽어보신 분 계시나요? 내용이 어떤지 궁금합니다. 비슷한 주제의 다른 책이 더 있는지 찾아봐야겠습니다.

홍민희 (VLAAH, LangDev)

feanor의 이미지

"24시간 365일 서버 인프라를 지탱하는 기술"에 대한 이전 KLDP 글입니다.
http://kldp.org/node/105436

소타의 이미지

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

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

jachin의 이미지

일단 하드웨어 대역폭이 넓으니 좋군요.

소프트웨어에 대한 부담이 확 사라지셨을듯.
====
하나는 전부, 전부는 하나

winner의 이미지

물론 경험을 쌓는 중요한 요소이기도 합니다만...

생각해보면 Unix의 시작도 PDP-7에다가 뭘 해볼까 하다가 OS 만들었다죠... -_-.
OS 만들기 위해 적합한 언어 만들어보자고 한 것이 C...

개발자 밤늦게 야근시키고 싶으면 새 computer 사주는게 최고라는...

moreta의 이미지

야근수당 주는것보다
새 컴터 사주는게
저비용 고효율전략인것같네요

소타의 이미지

그러라고 사준 컴터가 아닐텐데??
라는 짤방이 생각나네요..;;

codepage의 이미지

RDBMS의 R은 relational을 의미하는데
그럼 PostgreSQL는 어떠한 종류의 데이타베이스인가요?

hongminhee의 이미지

PostgreSQL도 RDBMS입니다. 정확히는 ORDMBS입니다.

홍민희 (VLAAH, LangDev)

codepage의 이미지

脫RDBMS라고 되있어서 전 아닌 줄 알았습니다. ^^