----
전국에 퍼져있는 약 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
초기 운영 시에는 별 문제가 안되었는데...
1~2년 운영하면서 DBA 및 시스템 운영 담당자들로부터 불만이 쏟아지더군요.
안정성 문제 때문에 일일(daily) 백업을 해야 하는데
백업 용량이 어마어마 하게 클 뿐더러,
전체 백업을 하려면 너무 시간이 오래 걸린다는 것이죠.
물리적인 용량 면에서는 DB 내부에 두는 것과 외부에 두는 것이나
큰 차이는 없지만, DB 외부에 파일을 보관하면 fetch하는 시간이 줄어들게 됩니다.
그 이후로는 BLOB는 사용자들의 프로필 이미지 같은
변경되지 않으면서 크지 않은 데이터에 한정하는 것을 원칙으로 삼고 있습니다.
> mail : kikist...@gmail.com
> 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/>