그림파일은 보통 DB 테이블에 저장 안하지 싶은데요...

아주 특수한 경우를 제외하고 이미지를 DB로 관리하지 않는 것이 좋을 것 같습니다.

안그래도 DB 관리 비용에 신경써야 하는데, 이미지까지 관리해야 하면 관련 정책이 잘 되어 있지 않다면 점점 관리가 힘들어 질 수 있는 요인이 될 수 있을 것 같습니다.

요즘은 내부망으로만 접근 할 수 있는 파일 서버에 가상 패스를 두고 서비스 하거나
외부 중계 서버에서 인증 후 스트림으로 읽어다 퍼주는 식을 많이 쓰는 것 같습니다.

대용량 분할 설계는 몇 문장으로 간단하게 설명 할 수 있는 내용은 아닌 것 같습니다.

서비스 대상, 성격, 목적, 규모 등에 따라 테이블 단일/수직/수평 분할/파티션/복제/분산/병합 등 다양한 방법이 있습니다. 위 단서만 보고 딱 이거다, 하기는 힘들 것 같습니다.

파티션만 보면,
조건에 조직 코드나 날짜 정보 등 대용량 범위에서 균등하게 싹뚝 짤라 올 수 있는 항목으로 List 파티션 하시거나 범위로 Range 또는 복합적 파티션 하시면 될 것 같습니다. Hash는 빈번한 요청이라면 X

파티션 : http://www.gurubee.net/lecture/1906

LIST 파티션 : http://www.gurubee.net/lecture/1910

RANGE 파티션 : http://www.gurubee.net/lecture/1908

HASH 파티션 : http://www.gurubee.net/lecture/1909

복합 파티션 : List + Range, List + Hash ...

2가지 관점에서 접근해야 할듯합니다.

1. 성능문제

- 데이터 발송이 아주 빈번히 발생이 된다

=> 여러 업무중에서 특정 업무에서만 해당 이미지 파일을 사용하지 않을까 생각합니다.

하나의 테이블에 컬럼사이즈가 너무 크면 로우 체이닝이 발생하니 하나의 테이블에 이미지 컬럼을 같이 생성하는 것은 다른 업무에도 문제가 있을것 같습니다.

업무적으로 자주 사용하는 컬럼으로 테이블을 구성하시고, 이미지 컬럼과, 자주 사용하지 않는 컬럼으로 새로운 테이블을 구성하는것이 좋을 것 같습니다.

새로운 테이블 생성시 기존 테이블과 별개의 테이블 스페이스를 사용하는것이 더 좋을것 같구요.

2. 파티션 테이블

- 파티션 테이블을 사용하는 장점은 관리, 가용성 그리고 성능입니다. 성능문제는 대량의 데이터를 조회할때 필요한 파티션만 스캔하겠다는 의미이므로 해당 업무하고는 성능은 고려할 필요가 없을것 같구요.    

다만 관리 측면에서는 생각해 볼수 있을것 같습니다. 이미지 파일이 있는 테이블을 파티션 할수 있을것 같구요...  파티션을 어떻게 구성할것 인가는 성능은 문제가 없다고 본다면 고객사에서 어느정도의 기간동안 해당 데이터를 관리할것인가를 따르면 될듯합니다. 사이즈로 봐서는 월단위 정도가 적당할것으로 생각이 들구요.. Hash Partition이 빈번한 처리인 경우에는 안좋다는 의견은 반대로 설명을 해주신것 같습니다. 빈번한 경우에 블럭의 경합을 즐이기 위해 Hash Partition이 오히려 유리합니다...