Berkley DB에 10 억 개 이상의 키를로드해야하므로 더 나은 성능을 얻기 위해 사전에 조정하고 싶습니다. 표준 구성에서는 너무 느린 1'000'000 키를로드하는 데 약 15 분이 걸립니다. Berkley DB의 B + Tree (노드 크기 등 ...)를 조정하는 적절한 방법이 있습니까?Berkeley DB Java Edition - 대용량 데이터 조정
(도쿄 캐비닛을 튜닝 한 후 비교해 보면 25 분 안에 10 억 개의 키가로드 됨).
P. 실행중인 시스템 (예 : jvm 크기 등)에 설정할 매개 변수가 아닌 코드로 튜닝 팁을 찾고 있는데
TokyoCabinet이 1B 키를 25 분 내에로드 할 때 궁금한 점은 크기가 무엇입니까? 저장된 키/값 중? 사용중인 I/O 시스템과 스토리지 시스템은 무엇입니까? "로드"라는 용어를 사용하여 1B 안정적인 스토리지로의 트랜잭션 커밋을 의미합니까? 666,666 인서트/초가 될 것입니다. 이것은 내가 알고있는 I/O 시스템을 고려할 때 실제로 불가능합니다. 이 숫자에 키와 값의 크기를 곱하면 이제는 물리적 한계를 넘을 수 있습니다. 의 블로그를보고 I/O 시스템과 하드웨어가 하드웨어에서 작동하는 방식에 대해 조금 읽은 다음 진술을 검토하십시오. 저는 TokyoCabinet이 무엇을하고 있으며 무엇을하지 않고 있는지 정확히 알기를 바랍니다. 추측해야만한다면 운영 체제에서 파일 시스템 캐시로 커밋하고 디스크로 플러시 (fdsync())하지 않을 수도 있습니다.
전체 공개 : 저는 Oracle Berkeley DB (TokyoCabinet의 직접 경쟁 업체)의 제품 관리자로서 약 10 년 동안이 데이터베이스와 최상의 하드웨어를 사용하여 놀았습니다. 편파적이고 회의적이다.
버클리 DB에는 속도를 내기 위해 내구성을 (내림차순으로 ACID에서) 내림차순 similar methods을 모방 한 트랜잭션 핸들에 설정할 수있는 플래그가 있습니다.
지금까지 버클리 DB 자바 에디션 (BDB-JE)가 빨리 다음 시도 할 수 있도록하는 방법으로 :
그것은 데이터베이스 성능의 주장을 명확히하는 것이 매우 중요합니다. 그들은 단순 해 보이지만 데이터를 손상 시키거나 커밋 된 트랜잭션을 잃어 버리지 않도록 바로 잡는 것은 매우 까다로울 수 있습니다.
이 정보가 도움이 되었기를 바랍니다.
BDB-JE의 대량 삽입은 단일 트랜잭션으로 그룹화하면 더 빠르게 처리됩니다. 그 이유는 각각의 단일 커밋은 커밋시 트랜잭션이 동기화되는 동안 (기본적으로) 디스크에 동기화 쓰기를 발생시키기 때문입니다. 내 응용 프로그램에서 단일 커밋으로 100,000 개의 작은 키를 쓰는 데는 트랜잭션이 진행되는 동안 1 분 이상 걸립니다. 단 몇 초만 걸립니다.