[database] NoSQL 데이터 저장소를 사용하여 어떤 확장 성 문제가 발생 했습니까? [닫은]

로드를 처리 할 수 ​​있도록 작은 하위 프로젝트를 MySQL에서 CouchDB로 전환했습니다. 결과는 놀랍습니다.

약 2 년 전, http://www.ubuntuusers.de/ (아마도 가장 큰 독일 리눅스 커뮤니티 웹 사이트) 에 자체 작성 소프트웨어가 릴리스되었습니다 . 이 사이트는 Python으로 작성되었으며 모든 예외를 잡아서 다른 소규모 MySQL 기반 웹 사이트로 보낼 수있는 WSGI 미들웨어를 추가했습니다. 이 작은 웹 사이트는 해시를 사용하여 다른 버그를 확인하고 발생 횟수와 마지막 발생 횟수를 저장했습니다.

안타깝게도 릴리스 직후에 역 추적 로거 웹 사이트가 더 이상 응답하지 않았습니다. 우리는 메인 사이트의 프로덕션 DB에 잠금 문제가있어 거의 모든 요청에 ​​예외가 발생했으며 테스트 단계에서 탐색하지 않은 다른 버그도 있습니다. 기본 사이트의 서버 클러스터 (트레이스 백 로거 제출 페이지라고도 함) 그리고 그것은 트레이스 백 로거를 호스팅하는 작은 서버에게는 너무 많은 길이었습니다 (이것은 이미 개발 목적으로 만 사용되었던 오래된 서버였습니다).

현재 CouchDB는 다소 인기가 있었으므로 그것을 사용 해보고 작은 역 추적 기록기를 작성하기로 결정했습니다. 새로운 로거는 단일 파이썬 파일로만 구성되었으며, 정렬 및 필터 옵션과 제출 페이지가 포함 된 버그 목록을 제공했습니다. 그리고 백그라운드에서 CouchDB 프로세스를 시작했습니다. 새로운 소프트웨어는 모든 요청에 ​​매우 신속하게 응답했으며 방대한 양의 자동 버그 보고서를 볼 수있었습니다.

한 가지 흥미로운 점은 이전의 솔루션이 기존 전용 서버에서 실행되고 있었지만 새로운 CouchDB 기반 사이트는 리소스가 매우 제한된 공유 xen 인스턴스에서만 실행되었다는 것입니다. 또한 키-값 저장소의 강점을 사용하여 수평 적으로 확장하지도 않았습니다. CouchDB / Erlang OTP가 어떤 것도 잠그지 않고 동시 요청을 처리하는 능력은 이미 요구를 충족시키기에 충분했습니다.

이제 빠르게 작성된 CouchDB-traceback 로거가 여전히 실행 중이며 기본 웹 사이트에서 버그를 탐색하는 데 유용한 방법입니다. 어쨌든 약 한 달에 한 번 데이터베이스가 너무 커지고 CouchDB 프로세스가 종료됩니다. 그러나 CouchDB의 compact-db 명령은 크기를 몇 GB에서 몇 KB로 다시 줄이고 데이터베이스가 다시 실행 중입니다 (cronjob을 추가하는 것을 고려해야 할 수도 있습니다 … 0o).

요약하면 CouchDB는 분명히이 하위 프로젝트에 대한 최선의 선택 (또는 적어도 MySQL보다 더 나은 선택)이었으며 잘 작동합니다.

답변

Name=An Example Product
Type=CategoryAProduct
Colour=Blue
Size=Large
Flavours={nice,lovely,unpleasant,foul}
Contains=[
Name=Product2
Type=CategoryBProduct
Size=medium
Flavours={yuck}
------
Name=Product3
Type=CategoryCProduct
Size=Small
Flavours={sublime}
]

var customers = redis.Lists["customers"]; //Implements IList<Customer>
customers.Add(new Customer { Name = "Mr Customer" });

var errors = redis.List["combined:errors"];
errors.Insert(0, new Error { Name = ex.GetType().Name, Message = ex.Message, StackTrace = ex.StackTrace});
redis.TrimList(errors, 1000);