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
운영게시판
최근게시물
자유게시판 자유게시판 5499 게시물 읽기
 
No. 5499
DSN 바이너리 자료 저장에 대한 초안
작성자
김상기(ioseph)
작성일
2006-12-12 00:44
조회수
9,214

바이너리 자료 저장 이야기를 메신져로 하다가, 

초안 이야기를 게시판에 적는게 나을 것 같아서 

기록으로 남겨둡니다. 



1. upload 루틴은 그대로 하고, 일단 db에 파일 정보만 저장하고 웹 루틴은 끝낸다.


2. 웹서버가 돌아가는 시스템에서 binary file saver 데몬 하나를 만들고, 그놈은 주기적으로 새로 올라온 binary file 이 있는지 살펴보아, 있으면, 그것을 db에 있는 uploadfiles 테이블의 binary 칼럼에 update 하고, md5sum 값을 웹 쪽 시스템과, db 쪽에 같이 보관해 둔다.

- table insert 작업이 꽤 오래 걸리는 경우, 웹서버에 영향을 주지 말아야하는 것이 첫번째 원칙입니다.


3. 사용자 download 요청이 있으면 기존 루틴에서 md5sum 체크 루틴을 추가하고, 일단 다운로드 디렉토리에 있는 파일과, db에 기록된 그것의 md5sum 값이 같은지 비교하고, 같다면, 그것을 기존 방식대로 download 작업을 하고, 그렇지 않다면, 다시 db에서 select 해서 binary 파일로 만들어둔다. 

download count update 때 table lock이 될지 안될지는 테스트를 해봐야겠네요. 

(조금 신경 써야할 부분 같습니다)

- binary 자료 select 작업에서 웹서버쪽의 영향이 최소화 되어야함이 첫번째 원칙입니다.


4. binary file 수정 작업은 기존 대로 삭제 뒤 새로 upload 하는 방식을 택한다. 


-------------


이런 방식이라면, 이번 사태와 같은 사태가 발생했을 때, 문제를 최소화 할 수 있고, db는 db대로 성능을 최대화 할 수 있을 것같네요.


누가 작업할지는 모르겠지만, - 꼭 누구라고 말은 안함 ^^

한번 멋지게 만들어보시길. 


(제가 보기에는 그냥 고가 스토리지 쓰면 그냥 풀려버리는 문제를 -.-)

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

누군지 짐작이 간다는...


단점은 반드시 그놈의 데몬이 따라 다녀야 한다는 것이 문제로군요.

그 데몬 프로그램이 유실되어 버리면 그로서 이 디비 구조는 기능의 일부를 잃을수도 있겠네요.


대안으로 그놈의 데몬만 pgsql DB 내에 저장시켜 두면 되겠네요 ^^

정재익(advance)님이 2006-12-12 00:51에 작성한 댓글입니다.
사용자 입력 체크도 해줘야 할꺼 같아요. :)

NUll Point를 강제로 밀어넣으면.. DB는 비정상 작동할테니까요

누가 그러냐구요?

저 같은 이상한 사람들이 꽤 많이 있답니다.. :)

개발할때의 원칙...

" 자기가 만드는 프로그램은 항상 바보만 쓴다는 점"
" 개발자 생각 대로만 사용자는 쓰지 않는다는 점"
" 버그는 개발자의 머리에서 나온다는 점"
이창민(Prosper)님이 2006-12-12 02:04에 작성한 댓글입니다.
이 댓글은 2006-12-12 02:04에 마지막으로 수정되었습니다.

상호가 고생이 많겠습니다....

ㅋㅋㅋㅋ

신기배(소타)님이 2006-12-12 02:49에 작성한 댓글입니다.

그냥 다른 파티션이나 원격 서버에 rsync 하는건 어떨까요?
DB에 첨부파일 저장을 위한 large object 저장에 대해서는 회의적인 생각을 가지고 있어서;
복구할 때도 똑같이 rsync 명령 한방이니..
rsync로 꼭 원격 뿐 아니라 다음 장비 증설 시 여분의 디스크를 확보해서 바이너리 데이터와 DB 문서들을 RAID1로 미러링 해서 저장하는 것도 좋은 방법 같습니다.

업로드, 다운로드 루틴을 바꾼다는 것은 그것에 어떤 문제가 있어야 하지 않을까요? 문제 없는것 같은데 ㅎㅎ
데이터의 이중화라면 방법이 많지 않을까요?

그리고 다시 이런 사태가 온다면 그때는 웹서버보다는 디비서버에 장애가 먼저 오지 않을까요? 이번 웹서버놈은 사양도 좋고 젊은 놈이니까요
이번 사태를 보면서 다음 장애가 DB서버에서 온다면.. 이라는 아찔한 생각도 해봅니다;

신기배(소타)님이 2006-12-12 03:00에 작성한 댓글입니다.

개발은 언제 될지가 모르니 당장은 백업을 더 신경써서 하자에 1표! 이런 준비가 되고 개발할 여력이 있으면 개발!

문태준(taejun)님이 2006-12-12 09:26에 작성한 댓글입니다.

흠 어려운 문제 난제중의 난제

풀기 어렵겠지만 풀어보려 노력할 수는 있겠네요. 오호호
기배 -_ㅡ+ 넌 빠져나갈 수 있으리라 생각한거냐 ㅡㅡ;

다음에 DB가 뻗어도 일이 없도록 앞으로 정기적으로 백업을 받아야 할 듯 합니다.
가능하면 일부 데이터는 소실되더라도 말입니다.

largeobject 다루는 일이 힘들까요? 그것도 난제군요. 케케

이상호(search5)님이 2006-12-12 09:54에 작성한 댓글입니다.

LO 는 7.0 시절에도 조금 다뤄 봤었는데, 별로 이점이 없어.
백업도 다이렉트로 안되어서... 그것도 문제고...

여하튼 LO 에 넣는 건 반대...
만약  DB crashing 시엔 그마저 다 나가고 또한 백업시에 엄청난 시간과 노력이 요구된다는 사실이 별로 내키지 않게 만드네.

만약 데몬 프로그램으로 구성할 생각이라면 데몬 프로그램은 LO 로 넣어 주는게 나을 것 같고, 그리고 rsync 를 사용하던 무엇이던 정기적으로 따로 백업을 하면 될듯...

정재익(advance)님이 2006-12-12 16:45에 작성한 댓글입니다.

rsync 놈이 더 낫겠네요.


왜 그생각을 못했지, 우째 모든 것을 DB로만 해결하려고하는 이 굳어버린 사고.

김상기(ioseph)님이 2006-12-12 17:24에 작성한 댓글입니다.
이 댓글은 2006-12-12 17:24에 마지막으로 수정되었습니다.

혹시 디스크 여유분이 있다면, mirrordir도 좋겠습니다.


http://www.geocities.com/scottlhenderson/mirrordir_4_OS_recovery.html


장애 시, 부팅만 다른 디스크로 부팅시키면 되서,  장애 복구가 빠르더군요.

허정수(wertyu)님이 2006-12-12 18:19에 작성한 댓글입니다.
[Top]
No.
제목
작성자
작성일
조회
5503돌아다니다가.. [3]
이상호
2006-12-15
8770
5501큐브리드 튜토리얼 및 기술문서 공모
백정한
2006-12-13
8816
5500리눅스 온라인 강좌 추천해주세요
최문희
2006-12-12
7899
5499DSN 바이너리 자료 저장에 대한 초안 [9]
김상기
2006-12-12
9214
5498대화형 작업의 번역 문제에 대한 잡생각 [4]
김상기
2006-12-12
8331
5497답답할 때는 사진을 보곤 합니다. ^^ [1]
정재익
2006-12-11
8243
5495하드 복구 관련하여 의견을 들어보려 합니다. [7]
신기배
2006-12-11
8368
Valid XHTML 1.0!
All about the DATABASE... Copyleft 1999-2024 DSN, All rights reserved.
작업시간: 0.017초, 이곳 서비스는
	PostgreSQL v16.2로 자료를 관리합니다