database.sarang.net
UserID
Passwd
Database
DBMS
MySQL
PostgreSQL
Firebird
Oracle
Informix
Sybase
MS-SQL
DB2
Cache
CUBRID
LDAP
ALTIBASE
Tibero
DB 문서들
스터디
Community
공지사항
ㆍ자유게시판
구인|구직
DSN 갤러리
도움주신분들
Admin
운영게시판
최근게시물
자유게시판 자유게시판 10769 게시물 읽기
 
No. 10769
대용량 실시간 데이터 처리에 쓰일 DBMS ?
작성자
강정묵
작성일
2010-07-04 04:28ⓒ
2019-09-19 21:29ⓜ
조회수
10,526

요즘은 .. 어디에서 쓰이던지

대용량으로 실시간에 데이터를 처리해야 하는 방법을 써야되지 않을까.. 혼자 생각해봅니다.

때가 바야흐로 모바일 시대라.. 실시간으로 무언가의 데이터를 주고 받고 처리해야 함으로써. 사용자의 빠른 처리 기대에 부응할  수 있고.

그 처리하는 용량 또한 사진 파일은 물론이고 몇 백줄 되는 데이터를  많은 사용자로 부터 받아 처리를 할려면..

말 그대로 대용량 실시간 데이터 처리 입니다.

 

본론으로..

그렇다면.. 어떤것들이 있나요?

 

MySQL

PostgreSQL
Firebird
CUBRID
Tibero

 

 

6개 정도 혼자서 생각하고 있습니다만...

정말 딱 부러지게.. 정렬 비교되어 있는 표도 ..없고.. (검색능력 부족인건지..OTL)

딱 봤을대 이건 아닌데.. 라고 생각하시는거 있다면.. 제외좀 해주시길 간절히 바래봅니다..

딱 봤을때.. 이걸 한 번 써 봤는데.. 강추다!!! 라고 생각 되는 제품군이 있다면. 추천을 간절히 바랍니다.

 

 

 

이 글에 대한 댓글이 총 7건 있습니다.

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

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

 

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

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

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

 

다른 방법으로는

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

 

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

신기배(소타)님이 2010-07-04 08:14에 작성한 댓글입니다.
이 댓글은 2010-07-04 08:24에 마지막으로 수정되었습니다.

참고로 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로 만들 수 있을 정도로 기능을 제공하지만 성능은 추천할 만 하지 않습니다. 안정적입니다.

신기배(소타)님이 2010-07-04 08:22에 작성한 댓글입니다.

 

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

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

 

도쿄 케비넷은

Introduction to Tokyo Products

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

 

 

잇힝(angelolgy)님이 2010-07-04 16:46에 작성한 댓글입니다.
이 댓글은 2010-07-04 17:02에 마지막으로 수정되었습니다.

 

memcached, membase 등  캐시 솔루션
RDB 자체로 대용량 처리를 하기에는 부족함.
캐싱기술로 대용량 처리를 커버 할 수 있음.
들어온 데이터들은 같은 데이터를 접근 하는 경향이 많다는 것을 참조.
데이터를 조회ㅏ하면서 메모리에서 먼저 찾고, 메모리에 올려져 있지 않으면 그때 가서야 디스크에서 찾아서 Merge 해줌. (OS)
실시간 데이터의 경우 이처럼 최근 들어온 데이터들을 얼마나 temporal locality를 유지하게 할 수 있느냐가 중요함.
응답할 데이터가 최대한 밀집되어 있고 그로 인해 OS에서 캐싱하는 디스크 블럭이 얼마나 작으냐가 실시간 DB성능에 핵심!

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

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

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

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

잇힝(angelolgy)님이 2010-07-04 17:19에 작성한 댓글입니다.

음 ^^;

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

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

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

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

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

 

정리하면.

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

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

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

 

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

신기배(소타)님이 2010-07-05 19:18에 작성한 댓글입니다.

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

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

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

 

도움안되네요 ㅠㅠ

이창민(prosper)님이 2010-07-10 05:20에 작성한 댓글입니다.

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

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

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

문태준(taejun)님이 2010-07-12 17:57에 작성한 댓글입니다.
[Top]
No.
제목
작성자
작성일
조회
10814하기 모임을 가지고자 합니다. [9]
이상호
2010-07-22
8196
10813개발자 연봉공유 사이트 생겼네요.
화이트
2010-07-21
9341
10770파일 시스템 뭐 쓰세요? [8]
신기배
2010-07-06
9217
10769대용량 실시간 데이터 처리에 쓰일 DBMS ? [7]
강정묵
2010-07-04
10526
10768언제 함.. 쐬주마시려나. [7]
김명화
2010-07-04
7872
10764운영자님 보세요~~ [2]
지연
2010-06-25
7371
10761전문개발자들을 위한 50001.com입니다.
김상욱
2010-06-21
8793
Valid XHTML 1.0!
All about the DATABASE... Copyleft 1999-2023 DSN, All rights reserved.
작업시간: 0.050초, 이곳 서비스는
	PostgreSQL v16.1로 자료를 관리합니다