음, 제이미에게 "나쁜 소식"이네요.
스크립트가 아직 완성되지 않은 상태가 너무 심각해서, 기존 vb3 설치를 discourse로 직접 마이그레이션하기 위해 처음부터 새로 작성하기로 결정했습니다. C#을 사용하면서 몇 배나 더 빠른 성능을 낼 수 있게 되었습니다.
스크립트를 충분히 "범용적"으로 만들 수 있다면 GitHub를 공개할 예정이지만, 현재도 여전히 vb3에 머물러 있는 오래된 커뮤니티를 마이그레이션하는 데 큰 관심이 있을지는 의문입니다.
간단한 업데이트 소식입니다. 놀라운 열정을 가진 소수 팀의 노력 덕분에 거의 마무리 단계에 도달했습니다.
다음 주 월요일부터 스테이징 머신에서 몇 가지 테스트 실행을 시작할 예정이며, 현재까지의 결과는 유망합니다.
현재 확보한 총 데이터는 다음과 같습니다:
크기 측면에서, vbulletin3 형식의 DB는 약 8GB입니다.
로컬 머신에서 소스 DB에 원격으로 연결하여 테스트를 수행하는 데 약 6시간이 소요됩니다.
이 스크립트는 모든 포럼/서브포럼을 카테고리 및 서브카테고리로 변환하여 마이그레이션합니다. 저희 포럼은 다소 오래된 스타일이며, ‘클랜’ 포럼 등 매우 깊이 중첩된 구조가 많아 3단계까지의 서브카테고리가 필요합니다.
3단계를 초과하는 항목은 모두 태그로 자동 변환되며, 부모/자식 서브포럼 관계에 따른 계층 구조(태그 그룹 사용)가 유지됩니다.
사용자 정의 권한(예: 읽기 전용)이 설정되었거나, moderators/admin 전용이거나, 또는 비밀번호 접근으로 숨겨져 있던 모든 서브포럼은 '스태프만 접근 가능’으로 마이그레이션됩니다. 최종적으로 약 10여 개 정도가 될 것으로 보이며, 이후 스태프가 올바른 사용자 그룹에 대해 수동으로 재활성화할 수 있습니다.
사용자, 사용자 그룹 및 개인 메시지도 마이그레이션됩니다. 개인 메시지는 'discourse 방식’으로 마이그레이션되며, 이는 단순한 1:1 데이터베이스 마이그레이션 시 볼 수 있는 1개의 메시지를 가진 N개의 주제(솔직히 말해 멍청한 데이터베이스 구조) 대신 discourse가 사용하는 스레드 기반 조직 방식으로 변환됩니다.
이 스크립트는 프로세스를 가속화하기 위해 모든 게시물의 ‘쿠킹(cooking)’ 처리도 이미 수행합니다.
주제 및 게시물 마이그레이션은 여러 개의 병렬 연결을 사용하여 수행되며, 소스 DB가 허용하는 최대한의 연결을 항상 사용하려 시도합니다.
소형 2vcore/4GB RAM 환경에서 평균적으로 얼마나 걸릴지 지켜봐야겠지만, 현재 사용 가능한 (미완성의) 일괄 마이그레이션 스크립트보다 이미 몇 배는 더 빠릅니다.
여러 부분이 더 최적화될 수 있으며, 상당 부분이 저희 포럼에 맞게 맞춤 설계되었습니다(구조가 덜 혼란스러워지도록 포럼 구조를 재조직하기 위해 JSON 매핑을 사용하기도 했습니다). 따라서 몇 가지 조정 없이 다른 사람이 바로 사용하긴 어려울 것 같지만, 마이그레이션이 완료된 후 소스 저장소를 공개할지 내부적으로 논의해 보겠습니다.
아마도 마지막 업데이트가 될 것 같습니다.
드디어 모든 것(인프라, 코드, 사용자, 모드 등)을 정렬하고 마이그레이션을 완료했습니다. 어제 일어난 일입니다. 커뮤니티 링크를 달지 않을 건데, 허용되는지 기억이 안 나기도 하고, 어쨌든 이탈리아에서는 꽤 잘 알려진 커뮤니티이기 때문입니다.
다음은 봇을 이미 필터링한 상태에서 30일 평균 수치입니다.
물론 이 일을 맡은 자원봉사자 팀에게는 상당한 부담이 되었으며, 아직 완전히 끝난 것은 아닙니다. 커스텀 테마와 디스코urses(Discourse)의 일부 배경 설정을 다듬는 중이거든요. (아마도 도움이 필요하거나 설명이 필요한 주제를 많이 열어야 할 것 같습니다.)
우리의 스크립트는 원했던 모든 것을 마이그레이션하는 데 성공했습니다:
등등입니다. 또한 마이그레이션 프로세스 자체에 '쿠킹(cooking)'을 통합했습니다. VBulletin에는 트윗, YouTube 동영상 및 기타 항목을 임베드할 수 있는 커스터마이징 기능이 있는데, 디스코urses의 기본 쿠킹 방식으로는 잘 변환되지 않기 때문입니다.
테스트는 4vcore/8GB 환경에서 진행했으며, 전체 마이그레이션에 약 7~8시간이 걸렸습니다.
프로덕션 환경에서는 패트레온(Patreon)으로 자금을 충분히 확보하여 8 vcore / 30 GB 환경을 구성했고, 전체 작업에 4시간이 걸렸습니다.
마이그레이션을 라이브로 중계했는데, 몇 번의 실패(물론 
)와 배경 음악도 함께 있었습니다. 꽤 재미있었습니다.
스크린샷에서 토픽/게시물 수와 타이밍에 대한 세부 사항을 볼 수 있습니다.
세 가지 타이밍은: 읽기 시간, 쿠킹 시간, 쓰기 시간입니다.
지치지만 설레는 모험이었습니다. @pfaffman, 제게 도움을 요청하지 않기로 결정한 것은 정말 현명한 판단이었습니다. 믿으세요.
오늘 기준으로, 이 프로젝트에 제가 들인 시간만 대략 £25k 상당으로 추정됩니다. 
지난 2개월 동안 이 일에 매진했던 다른 세 명의 시간은 계산하지 않았습니다. 그들은 종종 늦은 밤까지 일했습니다.
현재 마이그레이션 후 스크립트를 몇 개 더 실행 중입니다. 하나는 모든 아바타를 가져오는 것이고, 다른 하나는 모든 퍼malink(영구 링크) 리다이렉트를 생성하는 것입니다. 답변 안에 여전히 구식 URL 형식으로 남아 있는 링크가 올바르게 리다이렉트되도록 하기 위해서입니다. 이 작업들이 24시간 내에 완료될 것으로 예상합니다.
수 주 내에 스크립트 저장소를 정리하여 오픈소스로 공개할 수 있을지 논의할 예정입니다. 물론 저 혼자 그 결정을 내릴 수는 없죠.
수정: 모든 사용자 아바타 + 토픽/카테고리에 대한 내부 참조의 퍼malink 마이그레이션을 추가로 완료했습니다.
주 데이터 마이그레이션 이후에 실행했습니다.
감사합니다.
그렇게 들립니다. 당신의 코드는 꽤 훌륭해 보이지만, 스크립트를 한 달 동안 실행만 시켰다면 아마도 같은 결과를 얻었을 가능성이 높습니다. 최종 가져오기는 몇 시간, 혹은 그보다 짧은 시간에 완료되었을 것입니다.
끝내 해결해 주셔서 기쁩니다! 잘 마무리하셨습니다.
그러니까, 마이그레이션을 기다리며 웹사이트를 한 달 동안 닫아두자는 게 아니었잖아요 
게다가 공식 스크립트에 결여된 부분이 있는 상태라 좀 어렵긴 하죠 
그렇게 할 필요가 없었어요. 스크립트를 실행하되 사이트는 계속 켜 두면 되거든요. 스크립트가 끝나면 다시 실행하면 되고, 이미 가져온 데이터는 건너뛰므로 훨씬 빨리 실행됩니다. 몇 번 반복해야 할 수도 있지만, 처리할 새 데이터가 거의 없으므로 결국 몇 분이나 몇 시간 안에 끝날 거예요. 그 다음에는 기존 사이트를 잠그고 마지막 실행을 하면 됩니다. 기본적으로 스크립트는 각 사용자 및 게시물을 확인하지만, IMPORT_AFTER를 설정하여 날짜를 지정하면 이전 데이터를 완전히 무시하므로 매우 짧은 시간 안에 완료됩니다.
안녕하세요! 이 프로젝트에 참여한 개발자 중 한 명입니다.
개인적으로 매우 보람 있는 배움의 경험이었고, 아직 해결해야 할 마지막 문제들이 남아 있긴 하지만, 전체 커뮤니티의 반응은 긍정적입니다: 새로운 포럼 반응 스레드가…
글쎄, 약 24시간 만에 이 정도의 게시글 수가 쌓였죠 
이런 환경에서 마이그레이션이 필요한 vB3 설치 사례가 얼마나 더 있는지 모르겠지만, 이 스레드가 앞으로 누군가에게 도움이 되길 바라면서 말씀드리자면, 불가능한 일은 아니니 너무 절망하지 마세요. 일은 많지만, 충분히 해낼 수 있습니다
