대용량 파일들의 버전관리

[Jooyoung Lee]

안녕하세요.

대용량 파일버전관리하는데 문제가 있어 글을 남깁니다.

비슷한 고민이 있으셨던분들의 의견을 듣고싶습니다.

아래 링크에 비슷한 내용의 글이 있습니다.

https://groups.google.com/d/topic/xper/KkKVEqQI8jE/discussion

문제는 이렇습니다.

- 서버와 클라이언트는 용량이 얼마되지 않지만(100메가이하), 데이터는 보통 1기가 제일큰 파일이 20기가정도.

- SVN에서 관리하니 속도가 매우 늦고, 커밋이나 업데이트, 익스포트가 대부분 실패.

아래는 원하는 것입니다.

- 서버+클라이언트+데이터가 맞는버전을 유지한다.

- 커밋 및 업데이트가 빠르다.(FTP정도)

- 버전에 대한 히스토리를 확인한다.

- 무료!

다른 툴도 고려해봤지만 성능이 좋지 않았습니다.

어떤분은 퍼포스를 추천하셨지만 유료라 할수없었습니다.

많은 분들의 의견 부탁드립니다.

미리 감사드립니다.^^

[hojun song]

저도 이런 시스템이 필요해서 알아보고 있는데 궁금하네요

2012년 4월 3일 오후 12:09, Jooyoung Lee <petab...@gmail.com>님의 말:

--
studio hhjjj, http://www.hhjjj.com
Open Source Satellite Initiative, http://opensat.cc
TEL:+82-10-5269-1628

[Youngrok Pak]

꼭 무료여야 한다면 git을 쓰면 될 듯. git에서 대용량 바이너리 파일을 여러 번 써봤는데 잘 동작했고, 속도도 빨랐습니다. 20GB까지는 안해봤지만;; 다만, git 서버를 관리해야 하는데 그게 좀 귀찮을 듯.

근데 드랍박스 팀으로 쓰면 1년에 90만원 정도에 용량 무제한인데, git 서버 관리하는 인건비가 아무리 적어도 연 100만원은 넘게 나오지 않을까요? 전 이런 건 그냥 돈으로 때우는 걸 추천합니다.

2012년 4월 3일 오후 12:09, Jooyoung Lee <petab...@gmail.com>님의 말:

안녕하세요.

[최영목]

dropbox team은 속도가 좀 빠른가요?

개인적으로 dropbox free (현재 23gb)를 사용하고 있는데 평균 업로드 속도는 0.5메가 정도 되네요. 다운로드도 비슷한 것 같구요. (다운로드의 경우 타 사이트에서 10메가 이상 나오는 환경입니다.)

2012년 4월 3일 오후 12:58, Youngrok Pak <pak.yo...@gmail.com>님의 말:

[Freddie Park]

git가 대용량 파일에 문제될만한게 있나요? 파일 하나에 20GB 씩 하는걸 저장소에 넣어본적이 없어서 모르겠지만 별 문제는 없을거같고..

git 서버 관리하는건 스토리지만 큰 서버 한대 두면 될거같은데.. 사내 서버로 구축해두면 속도도 괜찮을거고 문제 없을거라고 생각합니다.

Best regards,

Freddie

2012. 4. 3. 오후 1:03 최영목 <davi...@nextree.co.kr> 작성:

[이지연]

전 dropbox free를 쓰고 있는데 

로컬에도 설치해 놓으면 좀 더 빠르게 업로드, 다운로드 할 수 있습니다.

업로드는 파일 탐색기에서 해당 위치에 복사하면 자기가 알아서 업로드 되고요

다운로드는 dropbox 에서 변경이 발생하면 체크해서 업데이트 해놓기 때문에 필요할 때 복사해다 원하는 드라이브로 옮기면 됩니다. 

처음 로컬에 설치할 때 dropbox 안에 있는 자료가 많으면 

로컬에 복사하는 시간은 좀 걸리죠..^^ 

그렇지만 dropbox 웹 사이트 내에서 업/다운 하는 것보다 월등히 빠릅니다.

2012년 4월 3일 오후 2:26, Freddie Park <sore...@gmail.com>님의 말:

[최영목]

아 제가 테스트했던 환경은 웹으로 업로드가 아니라 설치파일로 클라이언트 설치해서 속도 테스트했습니다. ^^

사진 업로드였는데 약 860여개 파일이었고, 총 크기는 4.6기가 정도였습니다. 이 때 평균 업로드 속도가 500k 내외였습니다. 다운로드는 조금 더 빨랐구요 ^^

어쨌든 git으로 대용량이 문제가 안된다면 스토리지 크기만 받쳐준다면 관리비용이 크게 발생하는지 모르겠네요. 대신 스토리지는 엄청 커야겠네요.

파일 4기가짜리 이름 2번만 바꿔도 총 12기가를 사용하겠네요. ^^;;;;

2012년 4월 3일 오후 2:56, 이지연 <ezon...@gmail.com>님의 말:

[Youngrok Pak]

아, 드랍박스가 빠르진 않습니다. 팀으로 써도 마찬가지구요. 한꺼번에 많은 수의 대용량 파일을 업로드해야 하는 경우에는 확실히 답답한 속도죠. 미국에선 빠르다고 하던데, 아마도 AWS 미국 서버만 써서 그런 듯. 아주 빠른 전송 속도가 필요하고 아시아권에서 사용한다면 드랍박스는 적합하지 않은 듯.

git는 스토리지도 문제지만 서버 어드민도 간간이 해야 하니까 github 클론 같은 거 없으면 어드민하기 좀 귀찮습니다. github 클론들도 아직 성숙도가 높다고 하긴 힘들구요. 물론 "git 서버 설치/어드민 따윈 아무 것도 아니야" 하는 분에겐 상관 없는 이야기겠죠.

스토리지 제약도 생각보다 빨리 다가올 겁니다. 최대 20G 짜리 파일을 다룬다면 다섯 번만 변경해도 100G를 먹죠. 테라 단위의 디스크를 붙여놔도 얼마나 갈지 모릅니다. 드랍박스처럼 히스토리 용량은 알아서 해주는 게 편하죠.

2012년 4월 3일 오후 3:02, 최영목 <davi...@nextree.co.kr>님의 말:

[Yi, EungJun]

git 이 생각보다 디스크 공간을 많이 먹지 않을수도 있습니다.

- 모든 파일은 zlib의 deflate로 압축되어 저장되므로, 포맷에 따라 크기가 많이 줄어들 수도 있습니다.

- 파일을 단 한 바이트만 변경해서 커밋하더라도 변경된 파일 전체를 새로 저장하는 것은 일단 사실이지만, git gc가
실행되면 delta compression을 하므로 결국은 변경한 만큼만 공간을 차지하게 됩니다. (물론 git gc가 자동으로
실행되기 전에 디스크가 차버리면 수동으로 실행해줘야 하므로 번거로울 수는 있겠습니다)

- 파일을 저장할 때는 sha1 hash값을 키로 하여 저장하므로 같은 내용의 파일은 한번만 저장됩니다.

2012년 4월 3일 오후 4:35, Youngrok Pak <pak.yo...@gmail.com>님의 말:

[Jooyoung Lee]

dropbox경우는 사내 파일서버를 사용하는것과 크게 다르지 않을까 생각합니다.

(물론 용량문제는 있겠습니다.^^ 저희 파일서버는 파일당 용량제한은 있지만 드롭박스와 비슷한 기능도 있더군요.)

파일서버를 사용안하는 이유는 버전별 태그, 브랜치를 하려면 복사에 복사를 해야해고 원천버전이 확인이 안되는 문제등 이력관리에 문제가 있어서 입니다. 용량도 문제입니다. ^^

우선 git이 성능이 좋다고 하셔서 설치해 시험을 몇개 해봐야 겠습니다.

한가지 궁금한건 git으로 했을경우에 svn의 익스포트같이 바로 버전을 가져오는 기능이 있는지요?

잘은 모르지만 git경우 저장소를 clone후 로컬에서 체크아웃 하는걸로 기억합니다.

짧은 생각에 수정하지 않을 버전1개를 가져오려고 저장소에서 개발자pc로 복사하고 체크아웃을 하게되면 절차도 많고 용량도 많이 필요하지 않을까요?

2012년 4월 3일 화요일 오후 12시 58분 32초 UTC+9, Pak Youngrok 님의 말:

꼭 무료여야 한다면 git을 쓰면 될 듯. git에서 대용량 바이너리 파일을 여러 번 써봤는데 잘 동작했고, 속도도 빨랐습니다. 20GB까지는 안해봤지만;; 다만, git 서버를 관리해야 하는데 그게 좀 귀찮을 듯.

근데 드랍박스 팀으로 쓰면 1년에 90만원 정도에 용량 무제한인데, git 서버 관리하는 인건비가 아무리 적어도 연 100만원은 넘게 나오지 않을까요? 전 이런 건 그냥 돈으로 때우는 걸 추천합니다.

2012년 4월 3일 오후 12:09, Jooyoung Lee <pe...@gmail.com>님의 말:

[Yi, EungJun]

svn export 와 같은 기능이 필요하시다면 git archive 를 사용하시면 됩니다.
git archive 는 특정 저장소의 특정 경로를 tar로 묶어서 가져옵니다.

예) https://domain/repo.git 저장소의 master 브랜치에서 README 파일 가져오기
git archive --remote=https://domain/repo.git master README | tar -x -

2012년 4월 3일 오후 11:56, Jooyoung Lee <petab...@gmail.com>님의 말:

[Lyle]

'원하는 것' 내용에는 없지만 데이터 그기가 크기 때문에 당면하게 될 문제를 하나 더 추가하자면 저장소의 확장성 입니다.

그리고 버젼 관리를 하시겠다고 하셨지만 변경내용 확인이 필요하지 않은 경우이므로 파일별로 revision 을 할당하는 편의성을
제외하고는 SVN 이나 git 등에서 벗어나서 생각해보시는 게 어떨지...

요즘 제가 관심 갖고 만드는 것과 비슷한 내용인 것 같아서 저는 mongodb 를 활용해서 약간의 개발로 원하시는 내용에 대한
구현을 하실 수 있을 것 같은 생각이 드네요.

gridfs 에 대해서 한 번 살펴보시죠.

On Apr 3, 12:09 pm, Jooyoung Lee <petabyt...@gmail.com> wrote:
> 안녕하세요.
>
> 대용량 파일버전관리하는데 문제가 있어 글을 남깁니다.
> 비슷한 고민이 있으셨던분들의 의견을 듣고싶습니다.
>

> 아래 링크에 비슷한 내용의 글이 있습니다.https://groups.google.com/d/topic/xper/KkKVEqQI8jE/discussion

>
> 문제는 이렇습니다.
> - 서버와 클라이언트는 용량이 얼마되지 않지만(100메가이하), 데이터는 보통 1기가 제일큰 파일이 20기가정도.

> *- SVN에서 관리하니 속도가 매우 늦고, 커밋이나 업데이트, 익스포트가 대부분 실패.*

[Sanghee Kim]

Git에 관련되어서 말씀드리면

- 대용량 파일중에 대용량 바이너리는 git 이 비효율적으로 다룹니다. 특히 로컬에서 대용량 바이너리가 들어간 커밋을 만들고 리모트에 푸쉬하면 변경사항이 좀 많아지면 상당히 느립니다. 실제 이런 문제가 git 의 단점인것을 파악했었구요, 실제 사용에서도 상당히 애를 먹었습니다. (예. 바이너리로 전달되는 라이브러리중에 업데이트가 잦은 파일은 push 할 때 항상 시간이 오래 걸렸다.) 따라서 이 부분에 대해서 인지를 해야겠구요. (1.7 초반 버전에서도 여전했습니다.)

- git 을 server - client topology로 쓰신다면 bare type 하나 만들어두면 됩니다. 여기에 permission control을 위해서 gerrit 이나 gitosis 같은 프론트엔드를 하나 달아보시는것도 좋구요. (설치도 쉽습니다. gerrit은 필요하다면 코드리뷰 기능도 켜시면 좋구요 꺼도 됩니다.) 관리는 저는 상당히 쉬웠습니다. 실제로 제가 주변 개발자들에게 두 세 시간 설명해주고 몇 번 질문을 받는것으로 큰 문제 없이 구축해서 사용하는 것을 봤습니다.

- git 서버는 스토리지 뿐만 아니라 cpu 도 많이 잡아먹습니다. 자체적으로 압축을 많이 하니까요.

- 2기가짜리 파일을 이름만 바꿔서 열 번 올리면 2.x기가의 공간만 차지합니다. 커밋 시점 각각이 스냅샷으로 남지만 실제 저장되는 것은 diff를 저장하고, 바뀐게 없다면 그냥 링크만 걸어줍니다.

더불어 전에 git과 관련된 구글 개발자에게 '대용량 바이너리 파일을 git에 올리니 push 할 때 너무 시간이 오래 걸리더라. 이런거 본 적 있냐?' 하고 메일링에 물었더니 '그렇게 큰 바이너리를 소스컨트롤에 넣는것에 대해서 다시 생각해봐라.' 라고 했었습니다. 물론 제가 일할때는 현업에서 편의와 '하던데로'때문에 그냥 가끔 문제가 생겨도 그냥 했지만 제 생각에는 정말 이러한 면도 고려해야 할 것 같습니다. 이를테면 정말 필요하면

'커밋에 텍스트 파일 하나를 넣어두고, 그 안에 파일 서버에 있는 어떤 파일의 위치를 적어두고 빌드시에 이 파일을 가져오는...'

식으로 하는것도 좋은것 같습니다.

2012년 4월 3일 화요일 오후 12시 9분 5초 UTC+9, Jooyoung Lee 님의 말: