ZODB 메모리 내 백엔드?

Question

저는 현재 요정 큰 프로젝트 (활동중인 회원은 약 수백 K)에서 일하고 있으며 Plone 솔루션에 강하게 의존했습니다.

과 here과 같은 몇 가지 질문을했습니다.

매우 숙련 된 Plonistas (및 활성 stackoverflowers)의 일부 답장을 받았습니다. 정말 감사. 사람들은 Plone이 그만큼 큰 규모로 확장되지 않는다고 계속 주장하고 있으며, 대부분의 이유는 ZODB 때문입니다.

그런 다음 ZODB의 메모리 내장 백엔드를 생각합니다. RAM은 지금 정말 싸다! 당신은 단지 $ 3k에 128GB, 정상적인 $ 300 128GB SSD에 비해 10 배, 그리고 ~ 300MB의 SSD에 비해 ~ 30GBs IO 대역폭을 얻을 수 있습니다.

메모리 내 백엔드 + 백업용 바이너리 + 10s 디스크 저널링 용 + 이전 10 개를 제외한 모든 실행 취소는 인스턴스 삭제입니다! 그들은 RDBM을 연기해야하고 그러한 소파 */redis 등에 비해 전체 ACID + 트랜잭션 + 객체 매핑을 제공해야합니다.

기술적으로 가능합니까? 구현이 있습니까? 구현할 가치가 있습니까 (귀하의 의견)?

Answer 1

전체 ZODB를 메모리에 유지하는 대신 portal_catalog를 별도의 탑재 지점에 탑재하고 메모리에 보관할 수 있습니다. 나는 이미 그런 종류의 구성을 보았으며 표준 하드웨어 (2 서버 + 1 제오 서버)를 사용하는 약 8k 사용자를 위해 원활하게 작동합니다. 필요에 따라 충분할 수도 있습니다.

Answer 2

느린 데이터베이스를 사용해야 할 때 도움이되는 RelStorage에 대한 memcache 옵션이 있지만 실제로는 운영 체제에 캐싱 종류를 남겨두고 데이터베이스 서버에 충분한 RAM이 있는지 확인해야합니다. RAM이 충분히 크면 파일 시스템 캐시에 이미 대부분의 데이터가 저장되어 있어야합니다. SSD를 사용하면 파일 시스템 캐시에없는 데이터에 대한 임의 액세스의 최악의 읽기 대기 시간을 크게 줄일 수 있습니다. Intel 330 SSD가 너무 싸고 배터리로 백업 된 RAID 컨트롤러와 동일한 콘덴서를 가지고 있기 때문에 지금은 사용하지 않는 것이 바보처럼 보입니다.

RAM 솔루션의 전부는 결코 ACID로 간주 될 수 없습니다 , 그것은 내구재가 아닐 것이기 때문에.

다른 게시물에 대한 내 의견에서 언급했듯이 여기에는 문제가되는 ZODB가 아니지만 Plone이 단일 contended portal_catalog를 동기식으로 사용합니다.