현재 포럼 게시물, 사용자 계정 등의 주요 저장소는 PostgreSQL 데이터베이스입니다.
포럼 콘텐츠의 주요 저장 형식을 단순한 텍스트 파일로 변경하는 것은 어떨까요?
데이터베이스 문제를 수정하기가 매우 어렵기 때문에(사용자인 저에게는 더욱 그렇습니다), SQL 데이터베이스의 불투명한 바이너리 형식 때문에 모든 포럼 데이터를 잃을 위험이 높다고 생각합니다. 심각하게 손상된 데이터베이스(위와 같은 문제처럼 눈에 띄지 않는 경우)는 아무도 수정할 수 없거나, 일반 사용자 입장에서는 비용이 너무 비쌀 수 있습니다.
성능과 같은 이유로 PostgreSQL과 같은 데이터베이스를 사용하는 데에는 매우 좋은 이유가 있다는 것은 잘 알고 있습니다. 그러나 데이터베이스 백업 및 복원 기능이 손상되거나 깨진 경우를 대비하여, 비상 상황의 최후의 수단으로 투명하고 사람이 읽을 수 있는 텍스트 형식의 백업을 제안합니다.
git이 얼마나 뛰어난지 설득할 필요는 없을 것입니다. 이미 사용하고 있으니까요. 포럼 콘텐츠를 서브 폴더 안의 수많은 텍스트 파일로 저장할 수 있습니다. 이렇게 하면 전체 폴더를 git 버전 관리 하에 둘 수 있습니다. 버그가 도입되면 어떤 커밋이 원인이었는지 추적하기가 훨씬 쉬워집니다.
데이터베이스(신뢰할 수 없고 복잡한)가 여전히 필요할 가능성이 높으므로, 이러한 텍스트 파일(단순하고 신뢰할 수 있는)은 데이터베이스를 “소스에서” 재생성하는 데 사용되는 템플릿 역할을 할 수 있습니다. 실시간으로 텍스트 파일에 새 게시물을 저장하는 것이 너무 느리다면, 텍스트 파일 백업 옵션을 온디맨드 방식으로 설정하거나 시스템이 유휴 상태일 때 실행하도록 할 수 있습니다. (지연 쓰기 / 쓰기 캐시.)
공개 데이터(공개 포럼 게시물)는 개인 사용자 데이터(해시된 비밀번호 등)와 다른 폴더에 저장됩니다. 추가적인 장점은 공개 부분(게시물)이 유용하다고 생각하는 사람들을 위해 git 원격 저장소에 게시할 수 있다는 점입니다. 사용자 데이터는 로컬 전용 git 저장소(또는 사용자 지정, 원격, 비공개, 암호화된 git 저장소)에 유지됩니다.
1990년대에 저는 텍스트 파일 기반으로 구축된 인터넷 포럼(telnet BBS) 소프트웨어를 사용했습니다. 우리는 끊임없이 더 많고 더 나은 기능을 갈망했습니다. 데이터에 "열(column)"을 추가해야 했습니다. TAB을 추가하고 그 다음에 추가 열을 넣었습니다. 기존 파일 전체에 이를 적용해야 했습니다. 그런 다음 우리는 (또 다른) 데이터 조각을 제거하고 싶었습니다. 모든 파일을 순회하며 이 데이터 조각을 제거하는 awk 스크립트를 작성했습니다. 그 사이 소프트웨어를 유지보수 모드로 전환해야 했는데, 소프트웨어가 다른 수의 필드를 가진 텍스트 파일을 인식했기 때문입니다. 그것은 지옥이었습니다. 우리는 더 나은 시스템을 간절히 원했지만, 최소한의 리소스로 소프트웨어를 실행할 수 있어야 했기 때문에 파일 시스템만 사용할 수 있었습니다. 우리는… 데이터베이스가 필요했습니다.
그러나 성능만이 문제가 아닙니다. 텍스트 파일도 손상될 수 있습니다. 예를 들어 두 프로세스가 동시에 파일에 쓰는 경우입니다.
또한 참조 무결성(referential integrity)이라는 것도 있습니다. 이는 내부 참조가 존재한다는 것을 보장합니다(예: 이 게시물은 주제 #152787과 사용자 #406에 속합니다).
그리고 트랜잭션, 스냅샷, 복제, 로드 밸런싱도 있습니다.
물론, 데이터베이스가 고장 날 수 있습니다. 제 차는 어제 고장 났는데, 지나치게 복잡한 ABS 제어 소프트웨어가 작고 겉보기에는 관련이 없는 문제에 매우 취약하기 때문입니다. 혼자서 수리하는 것은 불가능합니다. 수리하려면 상당한 돈을 지불해야 합니다. 하지만 어디를 가든 걷는 것보다 장점이 훨씬 많습니다. 신뢰할 수 없나요? 아니요. 여전히 브레이크가 작동했고, 대시보드의 경고등으로 즉시 통보받았습니다.
Richard의 비유가 적절합니다. Discourse의 데이터를 텍스트 파일로 관리하는 것은 불가능합니다.
또 다른 데이터베이스에 대한 지원을 추가하는 것만 해도 연간 약 20만 달러의 비용이 들 것입니다.
예산 범위를 정한 뒤 Marketplace 채널에서 데이터베이스 문제를 해결해 줄 사람을 찾는 것이 더 나을 수 있습니다. 몇 개의 레코드만 수정해야 하는 손상된 인덱스가 하나인지, 아니면 여러 개의 인덱스와 수십 개의 레코드를 수정해야 하는지 바로 명확하지 않기 때문에 견적을 내기 어려운 작업입니다.
