RavenDb 대 메모리 관리 접근 방식의 CouchDb

Question

RavenDB (쿼리 기능이있는 .Net JSON 스토리지 스토리지 db)는 다양한 캐시 크기를 조정할 수있는 구성 매개 변수 등을 통해 자체 스토리지 엔진 Munin을 통해 자체 제어하에 공격적인 캐싱/메모리 관리를 제공합니다. ... Google 그룹은 튜닝되지 않은 매개 변수 (충분한 크기의 db/index 포함)로 인해 이전에 (최신 릴리스의 경우는 아닐 수도 있음) 가끔 메모리 부족 예외를 제안합니다.

CouchDB는 다른 접근 방식을 취하고 운영 체제에 캐싱을 남깁니다. 내가/db1/doc-id-1을 구할 때 의미하는 것은 파일을 프로그래밍하는 측면에서 OS가 자체 캐시로 인해 최적화 할 수있는 파일 시스템을 읽어야한다는 것입니다. 마찬가지로 이것은 전망과 결과를 줄이는 것과 동일하다고 생각합니다 (범위에 따라 디스크에서로드/계산해야하는 b 트리의 여러 부분).

후자는 OS가 캐싱/페이징 등에서 수년간 발전해 왔으며 다른 서비스의 압력이 메모리 균형을 맞출 수 있다고 생각합니다.

먼저. 내 이해가 정확합니까? CouchDB의 접근 방식은 Unix 기반 OS에 고유합니다 (Windows 포트가 있음에도 불구하고). .Net DB 캔트가 OS에 의존하여 파일 읽기 등을 최적화하는 이유가 있습니까? 데이터 저장소 구축의 선택에 영향을 미치는 각 방법의 단점과 장점은 무엇입니까?

사이드 노트 : 나는, 레디 스가 같은 단지 메모리에 인덱스를 유지 믿습니다 각각 KEY를 GET은

Answer 1

Jia93 (중 디스크 헤드 여부 OS 파일 캐싱에 따라 충돌 않음) 디스크 히트 우리가하는 방식으로 작업하는 이유 중 하나는 레이어간에 더 강한 분리가 있다는 것입니다. CouchDB는 우리가하는 것 (mem에있는 것들을 유지하는 것)과 거의 같은 최적화를 가지고 있지만, 어플리케이션에 직접 노출되는 BTree 구조 위에 그렇게합니다.

결과 캐싱의 또 다른 이유는 모든 단일 요청에서 json을 구문 분석하는 비용을 피하기 위해서입니다.