대용량 실시간; 요즘 화두이긴 합니다만 RDB 자체로 해결하는 것이 아니라 캐싱 기술로 커버하는 경우가 많은 것 같습니다. memcached, membase 등 좋은 공개된 캐시 솔루션들이 있으니까 요즘은 이런걸로 대부분 커버하는 것 같습니다.

어떤 제품은 최근에 들어온 데이터가 최근에 요청되는 경우가 많다는 점에 착안해서 뒷단에 RDB를 두고 전면에는 메모리 기반의 캐시를 둔 제품도 있더군요. 데이터를 조회하면 메모리에서 찾고 부족하거나 없으면 디스크에서 찾아서 merge해줍니다. 개념은 좋은 것 같더라구요.

나열하신 DBMS들이 모두 좋은 것들입니다.

하지만 실시간 데이터 처리가 중요한 분야에서는 최근에 들어온 데이터들을 얼마나 temporal locality를 유지하게 할 수 있느냐가 중요한 것 같습니다. 응답할 데이터가 최대한 밀집되어 있고 그로 인해 OS에서 캐시하는 디스크 블럭이 얼마나 작으냐가 실시간 DB 성능의 핵심이 아닐까 생각합니다.

이런 점에서 WAL(write ahead log) 개념을 똘똘하게 도입한 제품들이 강하지 않나 싶네요.

다른 방법으로는

정렬, 조인이 필요한 부분만 메타데이터로 만들어서 RDB로 처리하고 본문 같은 것들은 key-value DB엔진으로 처리하는 것도 좋은 방법입니다. 큰 규모의 서비스들이 이런 방식을 많이 사용하고 있습니다. RDB의 부담은 줄이고 key-value 데이터는 캐시하기도 쉬워지지요.

개인적으로 실시간 대용량으로 mysql, sqlite는 비추입니다 -.-;

참고로 key-value DB엔진으로는

Tokyo cabinet 추천합니다. 데이터가 억단위 이하일 때는 hash table, 그 이상일 때는 b+tree table 모드 추천합니다. 멀티 쓰레드 환경에서는 락만 잘 걸어주면 별 탈 없이 좋은 성능을 내줍니다. 락 안걸어주고 삽입 경쟁이 일어나면 인덱스가 꼬여서 데이터가 유실됩니다. Tokyo Tyrant라는 memcached와 동일한 프로토콜로 동작하게 서버 형태로 된 것도 있습니다. memcached 라이브러리로 그대로 쓸 수 있습니다. 2개까지 멀티 마스터 됨.

단, 데이터가 매우 많을 경우(10억 이상) 데이터 유실 경험 있습니다.

Kyoto cabinet이라고 Tokyo의 후속 버전이 있는데 아직 영글지 않았습니다. 쓰시려면 hash table 말고 b+tree 쓰시면 됩니다. thread safe하므로 락 걱정이 없습니다. 안정성은 더 좋은 것 같습니다.

BDB(Berkely) - 기능은 많으나 비추. 이건 SQL 파싱만 할 수 있으면 RDB로 만들 수 있을 정도로 기능을 제공하지만 성능은 추천할 만 하지 않습니다. 안정적입니다.

답변 감사합니다.  캐싱 기술은 몰랐던 거네요.

검색을 해봤는데 http://www.lovelgw.com/Blog/94  이쪽에 나오는 설명대로 구현하면 되는군요..

도쿄 케비넷은

Introduction to Tokyo Products

혹시나 다른 분들의 의문 같고 검색 하실것 같아서..^

요약하면 이렇게 되겠군요. 감사합니다..

운영체제 시간에 배운것들이 다 나오네요 ㅋ

궁금한것은 현재 배포 되고 있는 (OSS 상태로 ) 제품들이 뒤 개념이 적용이 되서 나오는것인지.

아니면 일일이 개발자가 다 적용을 해야되는지 궁금합니다? 미리..적용이 되어서 릴리즈 되는 제품은 없구요?

음 ^^;

RDB 자체로 대용량 처리를 하기에는 부족하다기 보다는요.

RDBMS 머신의 성능이 scale out을 할 필요 없이 엄청나게 좋거나,(사실상 scale up으로 모두 처리가 가능하다)

RDBMS가 자체적으로 클러스터링/그리드 등 분산 처리가 잘 되거나,

RDB 사용 자체를 분산 처리되도록 어플리케이션이 짜여져있거나

하면(모두 충족할 수록 좋음) 충분히 가능합니다.

정리하면.

RDB 자체는 대용량 데이터를 처리할 수 있다. 실시간 데이터도 처리할 수 있다.

하지만 규모의 확장이 용이하지 않다. 대용량 데이터를 처리하기 위해서는 가능하면 incrementally sacle out 을 고려할 수 있어야 한다. 하지만 이게 공짜로 되는 OSS 솔루션은 적다.

최근에 사용된 데이터는 다시 사용될 확율이 매우 높기 때문에 데이터를 실시간으로 처리할 때는 캐시가 유용하다. 캐시만 있다고 대용량 데이터가 처리되는 것은 아니다.

캐싱은 캐싱만의 역할이 있는데요. 맨 위처럼 RDB로 모든것을 커버할 수 있더라도 캐싱을 해주는 것은 필요하다고 생각합니다.

뭐 결국은 기회비용을 어떤식으로 커버할 것인가? 뭐 그런 소리 같은데...

돈많으면 H/W spec을 좋게해서 때우면될꺼구요..

그렇지 않으면 다른 방법을 모색해서 삽질을.... 캐싱이나 메모리나 뭐나뭐나....

도움안되네요 ㅠㅠ

저도 이쪽에는 지식이 있는 것은 아니지만 위에서 말을 한대로 RDBMS 자체만으로 모두 처리할 수 있는 것은 아닌 듯 합니다. memcached 등도 해외에서는 많이 사용을 하는 듯 하구요.

이게 연관이 될지는 모르지만 실시간으로 사용자에게 서비스하는 부분말고 대용량의 데이터 처리 등을 위한 아파치 하둡 같은 것도 아이디어 차원에서는 도움이 될 수 있을 듯 합니다.  물론 아파치 하둡같은 것은 실시간으로 처리를 하여 고객에게 서비스를 하고자 하는 용도는 아닙니다.

위에 창민군은 HW spec 으로 때우면 될 것 같지 않냐고 했지만 절대 HW 빵빵한것만으로는 안되는 일들이 있을 거구요. 뭐 아무리 하드웨어 빵빵해도 SQL 문 하나 엉망으로 쓴 것 때문에, DB 연결하고 끊는 것 제대로 안하는 것때문에라도 시스템 맛탱이 가는 경우도 많은데요.