clob을 이용한 파일관리 여러분 어떻게 생각하세요?

2,245 views
Skip to first unread message

kikistyle

unread,
Jun 30, 2009, 8:55:49 AM6/30/09
to ks...@googlegroups.com
간단히 질문한거지만 사실은 저희 회사입장에서 중요한 문제라 고수님들의 귀
한 의견을 구하고자 이렇게 띄워봅니다. 혹은 유사한 경험이 있으신 분들이
계시다면 사소한 의견이라도 좋으니 한문장 주시면 감사히 받겠습니다.

----
전국에 퍼져있는 약 8만개 정도의 클라이언트가 매일 약 1~20메가바이트 (최
대 50메가바이트) 정도의 파일을 전송합니다.(http를 사용하되 클라이언트가
웹브라우져는 아닌 별도의 데스크탑 응용프로그램입니다. 서버는 web server,
was 사용예정)

일단 중앙서버에 저장된 이 파일들은 각각의 업무처리 서버로 retrieve되어
실제 비지니스 로직을 처리하는 프로그램에 로딩되어 사용됩니다.

이 때 클라이언트가 서버로 전송할 파일을 저장해두는 스토리지 부분(중앙서
버)에서의 파일 저장방법에 대해 다음 두가지 방안이 있을 수 있으리라 생각
됩니다.

1.실제 물리적인 파일로관리하는 방법(파일의 메타데이터(파일시스템상의 경
로정보, 파일명, 발신자,크기,건수,내용에대한요약 등)는 DB로 관리)
2.실제 파일을 oracle의 clob이나 blob형태의 컬럼에 저장하는 방법

1번 방법은 많은 곳에서도 대부분 이러한 방식을 많이 쓰시리라 생각됩니다.
즉 실제 파일은 디스크의 "/data/biz1/200906/3021/3932234234/234324" 에 저
장되어 있고 해당 파일의 실제명, 사이즈 등 메타데이터는 DB로 관리하는...

2번 방법을 쓰는 곳은 많이 들어보지는 못했고 한 군데의 정부기관에서 이러
한 방식을 쓰고 있다는 정보는 들은적이 있습니다.

짧은 제 생각으로 2번방식의 장점이라면 무엇보다 관리의 편리성 있을거라 생
각되는데요. 다양한 사용자에 대한 파일접근제한 처리, 파일의 이동, 삭제,
변경, 목록조회 등의 관리, 또한 서버간 파일전송시 oracle 자체 프로토콜을
이용하므로 ftp등의 구현이 필요없다는 점 정도...? 또다른 장점이 있을수 있
겠죠.

단점이라면 무엇보다 불필요한? 시스템의 리소스를 사용한다는점. 그걸로 인
한 속도등의 성능감소.. (DB인서트시 업로드되는 파일을 일단 임시파일로 저
장후 DB에 인서트해야 되지 않을까 생각되네요..)


뭐 경험이 많지 않은 저로서는 이정도의 추측을 해볼뿐인데요. 다양한 의견이
있을수 있을것 같습니다. 아무리 하드웨어 비용이 낮아졌다고는하지만 낭비하
는건 아닌가 싶기도 하구요. 서버를 증설할때..? DBMS를 바꾸는 일이 생긴다
면..? 그래도 비용(or 성능)대비 관리용이에 대한 이득이 더 큰걸까? 머리가
터질것 같습니다.

--
mail : kiki...@gmail.com

Park, Sungchul

unread,
Jun 30, 2009, 11:20:08 AM6/30/09
to ks...@googlegroups.com
샤워하러 들어왔다가 우연히(?) 보게되어 간단히 답글을 남김니다.

전 db를 좀 아끼는 편입니다. Db가 병목이 되는 일이 많아서요. 객체지향 기
능이 들어가면서 db로 미디어 자료를 관리하기도 하지만 단순 저장이라면 별
이득이 없다고 봅니다. 오히려 백업이나 스토리지 관리의 부담만...

Jakarta vfs 같은 파일 시스템 추상화 도구를 고려해 보세요

나의 iPod에서 보냄

2009. 06. 30 오후 9:55 kikistyle <kiki...@gmail.com> 작성:

kikistyle

unread,
Jun 30, 2009, 11:31:53 AM6/30/09
to ks...@googlegroups.com
그런것도 있었군요.
파일 시스템을 추상화하면 추후 변경에 대해 안전한 부분이 있겠네요...
o/s가 바뀌거나 스토리지가 바뀌는 등...

의견 감사드립니다.


Park, Sungchul 쓴 글:

전형민

unread,
Jun 30, 2009, 7:22:02 PM6/30/09
to ks...@googlegroups.com
전 파일을 파일로
db에 저장되어야 할 자료는 DB에 저장되어야 한다고 봅니다.
 
파일 까지 DB에 넣어야 하는 이유는 없다고 봅니다.
 
예을 들어 파일을 사용자에게 다운로드 하는 경우
DB에서 파일을 바로 사용자에게 다운로드 하는 경우
db connection은 사용자가 파일 다운로드를 완료할때 까지 열려 있어야 합니다.
원거리에서 파일을 다운로드 하는 경우 connection이 상당히 오래 열려 있을 우려가 있습니다.
connection이 오래 열려 있다는 것이 문제가 아니라.
이렇게 오래 열려있다는 것은 active connection 개수가 증가한다는 것을 의미하게 되는
것으로 시스템 oralce resource를 많이 사용한다는 이야기가 됩니다.
 
큰 파일을 다운로드 하다가 network 등 기타 상황으로 exception이 발생하는 경우
oracle connection resource 관리에도 문제가 생길수 있지 않을까 생각이 됩니다.
 
저희 경우는 대용량의 통계정보를 생산하는 경우도 만들어진 통계정보를 server의
파일로 만들어 두고 이를 사용자가 다운로드 하게 하여
db의 connection resource에 상당히 신경을 쓰는 편이라서요..
 
어찌 되었던 저의 생각도 파일은 filesystem에 정보는 db에 두는 것이 올바르지 않을까 합니다.
 
backup 을 생각해 볼수 있는데요.
oracle에 file 정보가 들어가 있으면 backup 하는데도 시간이
많이 걸리지 않을까요?( 물론 cold backup 인 경우는 그렇지 않겠지만, )
 
table space의 관리
file이 db에 들어가게 되면 table space의 용량 증가에도
신경을 쓰고 관리해 주어야 할것 같습니다.
 
 
-----
file을 filesystem으로 관리하는 경우도 문제는 있습니다.
transaction의 문제 인데요.
db는 exception 상황에서 rollback이 가능하지만, filesystem은 이런 부분을 지원하는
것을 따로 생성해 주어야 필요하지 않은 쓰래기 파일들이 만들이 지지 않게 하는
것이 가능할 것이라 생각됩니다.
 
 
저의 생각을 정리하면
저장되어야 하는 파일이 많지 않을 경우 file을 db에 넣어 두는 것이 괜찬을
것이라 생각됩니다.
 
하지만, file이 많이 생성되는 곳이라면 file은 filesystem에 저장하는 것이
올바르지 않을까 생각됩니다.
 
도움이 되었기를 바랍니다.
------------------------------------
당신의 과거가 당신을 만든다.


2009년 7월 1일 오전 12:31, kikistyle <kiki...@gmail.com>님의 말:

써니

unread,
Jul 1, 2009, 12:12:00 AM7/1/09
to Korea Spring User Group
예전에 모 그룹웨어 시스템이 첨부 파일을
DB에 파일을 담가 버린(?) 경우가 있었습니다.
제가 만든 시스템은 아니고 ... -,-

초기 운영 시에는 별 문제가 안되었는데...
1~2년 운영하면서 DBA 및 시스템 운영 담당자들로부터 불만이 쏟아지더군요.
안정성 문제 때문에 일일(daily) 백업을 해야 하는데
백업 용량이 어마어마 하게 클 뿐더러,
전체 백업을 하려면 너무 시간이 오래 걸린다는 것이죠.

물리적인 용량 면에서는 DB 내부에 두는 것과 외부에 두는 것이나
큰 차이는 없지만, DB 외부에 파일을 보관하면 fetch하는 시간이 줄어들게 됩니다.

그 이후로는 BLOB는 사용자들의 프로필 이미지 같은
변경되지 않으면서 크지 않은 데이터에 한정하는 것을 원칙으로 삼고 있습니다.

> mail : kikist...@gmail.com

자유

unread,
Jul 2, 2009, 9:01:42 PM7/2/09
to Korea Spring User Group
그렇군요. WAS 쓰레드 뿐 아니라 DB커넥션도 트랜잭션이 끝날때까지 열려있어야 한다는 제약이 있군요. 감사합니다.

> 2009년 7월 1일 오전 12:31, kikistyle <kikist...@gmail.com>님의 말:


>
> > 그런것도 있었군요.
> > 파일 시스템을 추상화하면 추후 변경에 대해 안전한 부분이 있겠네요...
> > o/s가 바뀌거나 스토리지가 바뀌는 등...
>
> > 의견 감사드립니다.
>
> > Park, Sungchul 쓴 글:
>
> > 샤워하러 들어왔다가 우연히(?) 보게되어 간단히 답글을 남김니다.
>
> > 전 db를 좀 아끼는 편입니다. Db가 병목이 되는 일이 많아서요. 객체지향 기
> > 능이 들어가면서 db로 미디어 자료를 관리하기도 하지만 단순 저장이라면 별
> > 이득이 없다고 봅니다. 오히려 백업이나 스토리지 관리의 부담만...
>
> > Jakarta vfs 같은 파일 시스템 추상화 도구를 고려해 보세요
>
> > 나의 iPod에서 보냄
>

> > 2009. 06. 30 오후 9:55 kikistyle <kikist...@gmail.com> <kikist...@gmail.com> 작성:

> > mail : kikist...@gmail.com
>
> > --
> > mail : kikist...@gmail.com
> > site : blog.gimslab.come <http://blog.gimslab.com/>

자유

unread,
Jul 2, 2009, 9:03:49 PM7/2/09
to Korea Spring User Group
저도 백업시 부담이 클거라는 생각이 들기는 합니다. 근데 오라클은 어떤 의도로 LOB형태의 컬럼을 지원하는걸까요? 권고하는 사항
이 있을듯한데... 그것부터 함 찾아봐야겠네요.
Reply all
Reply to author
Forward
0 new messages