대규모 데이터 세트로 도쿄 캐비닛/도쿄 폭군을 성공적으로 사용한 사람이 있습니까? Wikipedia 데이터 소스의 하위 그래프를 업로드하려고합니다. 약 3 천만 개의 레코드를 치고 나면 기하 급수적으로 느려집니다. 이것은 HDB 및 BDB 데이터베이스 모두에서 발생합니다. 나는 bnum을 약간의 속도로 HDB 케이스의 예상 레코드 수의 2-4 배로 조정했다. 또한 xmsiz를 1GB로 설정했지만 궁극적으로 벽에 부딪 혔습니다.왜 도쿄 폭군은 bnum을 조정 한 후에도 기하 급수적으로 천천히 감소합니까?
도쿄 폭군은 기본적으로 메모리 데이터베이스에있는 것으로 보이며 xmsiz 또는 RAM을 초과하면 간신히 사용할 수있는 데이터베이스를 얻게됩니다. 다른 누구도 전에이 문제가 발생 했습니까? 당신이 그것을 해결할 수 있었습니까?
나는 내가이 일을 금했다고 생각, 나는 다른 곳이 솔루션을 보지 못했다. 리눅스에서는 일반적으로 도쿄가 천천히 시작하는 두 가지 이유가 있습니다. 일반적인 범인을 뚫을 수 있습니다. 첫째, bnum을 너무 낮게 설정하면 해시에있는 항목 수의 절반 이상이되도록합니다. 둘째, xmsiz를 버킷 배열의 크기에 가깝게 설정하려고합니다. 버킷 배열의 크기를 얻으려면 올바른 bnum으로 빈 db를 만들고 도쿄가 파일을 적절한 크기로 초기화합니다. 예를 들어 빈 데이터베이스의 경우 bnum = 200000000은 약 1.5GB입니다.
하지만 이제는 조금 더 멀리 있긴하지만 여전히 느려집니다. 그 트릭은 파일 시스템에서 저널링 기능을 끄는 것이 었습니다. 해시 파일 크기가 2-3GB를 초과 할 때 어떤 이유로 저널링이 (ext3에서) 급격히 증가했습니다. (우리가 깨달은 방식은 디스크의 파일 변경, kjournald의 데몬 CPU 버스트와 일치하지 않는 I/O에서의 스파이크입니다.)
Linux의 경우 ext3 파티션을 마운트 해제하고 ext2로 다시 마운트하기 만하면됩니다. db를 빌드하고 ext3으로 다시 마운트하십시오. 저널링이 비활성화되었을 때 문제없이 180M 키 크기의 DB를 구축 할 수있었습니다.
Shardy라고하는 도쿄 캐비닛에 샤딩을 추가하는 솔루션을 만들기 시작했습니다.
도쿄 캐비닛의 키 값 저장소가 정말 좋습니다. 나는 사람들이 도쿄 내각의 테이블과 같은 가게를 사용하기 때문에 천천히 부른다 고 생각한다.
문서 데이터를 저장하려면 mongodb 또는 다른 nosql 엔진을 사용하십시오.
에 혹시 질문을 읽으셨습니까?그는 해시 데이터베이스와 B + 트리 데이터베이스를 사용하고 있습니다. – ibz
도쿄가 훌륭하게 비늘! 하지만 bnum과 xmsiz를 적절하게 설정해야합니다. bnum은 저장할 계획 인 레코드보다 .025 ~ 4 배 커야합니다. xmsiz는 BNUM의 크기와 일치해야합니다. 또한 2GB 이상을 저장할 계획이라면 opts = l로 설정하십시오.
위의 Greg Fodor의 게시물에서 xmsiz의 크기에 대한 값을 얻는 방법을 참조하십시오. xmsiz를 설정할 때 값은 바이트 단위입니다.
마지막으로, 디스크 기반 해시를 사용하는 경우 도쿄 데이터가 살아있는 파일 시스템에서 저널링을 끄는 것이 매우 중요합니다. Linux, Mac OSX 및 Windows에서는 아직 테스트하지는 않았지만 이는 사실입니다.
저널링을 사용하도록 설정하면 30 억 개가 넘는 행에 접근 할 때 성능이 크게 저하됩니다. 저널링 기능을 끄고 다른 옵션을 적절하게 설정하면 도쿄는 훌륭한 도구입니다.
"이 사람들은 전에이 문제가 발생했습니다."분명히 http://bjclark.me/2009/08/04/nosql-if-only-it-was-that-easy/ –
링크가 더 이상 작동하지 않습니다. , 이제 http://mod.erni.st/2009/08/nosql-if-only-it-was-that-easy/ –