1. 대부분의 RDBMS 에서 select 속도는 거의 비슷비슷합니다. 

테이블 전체를 읽어야 하는 쿼리라면, 결국 그 양만큼 디스크를 읽어야 하기 때문입니다. 

mysql 을 쓰든, mongodb를 쓰든 별반 차이는 없습니다. 

차이가 있다면, 첫번째 쿼리가 아니라, 똑 같은 쿼리에 똑같은 결과를 보여주는 작업이 반복되었을 경우, 그 반복되는 작업에 대한 캐쉬 처리를 어떻게 하느냐에 달렸는데, 이 부분도 요즘은 대부분 비슷비슷한 속도를 보장합니다. 

즉, 데이터가 많으면 느려지는 것은 어쩔 수 없다가 결론입니다. 

많은 자료를 select 하는 경우에 대해서는 미리 집계 해서 집계성 테이블 자료를 주기적으로 갱신하는 방법이 제일 일반적입니다. 

2. 파티션 테이블을 사용하는 것이 일반적입니다. 

'커질대로 커져버린' 이라는 표현을 쓸 때, 살펴보면, 대부분 로그성 insert only 테이블들인데, 이 테이블의 사용을 가만히 보면, 굳이 이런 자료를 DB 안에 넣어야 하나하는 생각을 가끔합니다. 

mp3 파일을 db에 넣어 두고 서비스 하는 것과 비슷하다는 생각을 합니다. 

서비스에 대한 요구사항을 분석하면서 데이터 모델링에서 '모든 자료는 RDBMS에 넣어야 한다'는 강박관념만 버리면 길을 여러가지일 것 같습니다. 

그럼에도 불구하고, facebook 같이 무지막지한 자료가 쌓이고, 그 자료 모두가 로그성 자료가 아니고, 무지막지하게 select 되어야 한다면, 이런 부분은 요즘 이야기하는 빅데이터로 기법으로 푸는게 맞을 듯합니다. 

거기까지 안간다면,  

절충안으로 하나의 RDBMS에 각 미들웨어와 함께 있는 캐시 서버와 캐시 서버간 동기화로 전체 구조를 다시 설계하는 방식을 사용합니다. 

PostgreSQL - jBoss (인피니스팬 활용) - apache 

이런 형태로 전체서비스의 품질이 떨어지면, 미들웨어쪽 병렬로 늘리는 방법을 사용하는 것이 일반적입니다.

상기님 조언 감사드립니다.

select 효과가 비슷하다는건 ... 절망적이군요. ㅠ_ㅠ

몇년전에 db별로 insert 하는것에 대한 처리는 확실히 속도 체감을 했었는데

캐쉬처리에 대한 부분도 기대할만큼 다르지 않다니 허허 - *

모든 자료는 RDBMS에 넣어야 한다는 강박은 ...

고객이니 ㅠ_ㅠ 어쩌지 못하고 있는 상황이긴 합니다만 ㅎㅎ

아무쪼록 의견에 영감을 얻어갑니다.

언제나 답변 감사드립니다.

Mongo DB 같은 경우에는, Sharding 구성이 가능하기 때문에, Select 조회시 상당한 속도 향상을 볼 수 있습니다. 

단만, MongoDB 의 경우, 기본 구성 시, ACID 구성 중 Consistency 구성이 안되어 있기 때문에,

Replica Set의 값이 서로 다른 경우가 많이 있습니다. 

일반적으로, Write Scalability의 경우, Casandra 쪽을 선호하고, Select Scalability의 경우

MongoDB 쪽을 선호하는 편입니다.

감사합니다 ^ ^ 가오리님

몽고DB도 이용해봐야겠네요 ^ ^