나는 얼마 동안이 점에 대해 궁금해했습니다. CouchDB를에서 우리는 몇 가지 매우 로그인 ID가 ... 예 :긴 ID의 성능
우리가이 항목에 대한 검색 및 뷰에 의해 생성 된 트리 구조를 통과하는 경우 "000ab56cb24aef9b817ac98d55695c6a"이제
. 그것은 ID가 훨씬 더 빠를 것이므로 단순한 정수로 보입니다. 우리가 64 비트 정수를 사용했다면, 간단한 CMP와 JMP (Erlang 코드가 JIT를 사용한다고 가정하지만, 당신은 나의 요지를 얻는다)가 될 것이다.
문자열의 경우 ID 또는 다른 해시를 해시한다고 가정하지만 어느 시점에서 33 자 모두에 대해 문자 비교를 수행해야합니다 ... 성능에 영향을주지 않습니까? CouchDB를에서
키 길이가 트리를 걷는 데 걸리는 시간에 직접 영향을 미치기 때문에 짧은 응답은 물론 성능에 영향을 미칩니다.
키가 길면 키가 더 많은 공간을 차지하므로 저장 공간에도 영향을줍니다.
그러나 누락 된 뉘앙스는 Couch CAN은 새로운 ID를 할당 할 수 있지만 필요하지 않습니다. 자체 ID를 생성하는 것보다 자신의 ID를 수락하는 것이 더 행복 할 것입니다. 따라서 열쇠 길이가 너를 괴롭히는 경우, 더 짧은 열쇠를 자유롭게 사용할 수 있습니다.
그러나 소파의 "json"특성을 고려하면 "텍스트"기반 데이터베이스에 가깝습니다. 보통의 Couch 인스턴스에 저장된 바이너리 데이터는 많지 않습니다 (첨부 파일은 견딜 수 없지만 BASE64에 저장되어 있다고 생각되는 파일은 잘못되었습니다).
그래, 64 비트가 가장 효율적이지만 간단한 사실은 소파가 모든 키에서 작동하도록 설계되었으며 "모든 키"가 텍스트에서 가장 쉽게 표현된다는 것입니다.
마지막으로, 키 비교 비용은 디스크 I/O 페치 시간과 데이터의 JSON 마샬링 (특히 쓰기)으로 인해 비하면 작다는 사실을 알 수 있습니다. 이러한 시스템으로 변환하여 얻은 실제 이득은 전체 성능에 "실제"영향을 미치지 않을 것입니다.
정말로 카우치 키 시스템의 속도를 높이려면 64Bit 길이의 키를 차단하는 키 루틴을 코딩하고 (말한대로) 그 키움을 완성하십시오. 8 바이트 텍스트는 64 비트 "long int"와 같습니다. 이것은 이론적으로 핵심 비교에서 8 배의 성능 향상을 제공합니다. erlang이 그러한 코드를 만들 수 있는지 여부는 말할 수 없습니다.
위대한 답변 윌, 고마워. –
: 확실한 가이드 북 :
내가 에서 어떤 점을이 그림을 그릴 필요하지만, 당신이 이상적인 BTREE 생각 경우 이유는, 때 사용 UUID의입니다 해당 트리에서 루트 노드의 수를 쳐야 할 수도 있습니다. 따라서 에 추가 노드가있는 경우 을 사용하면 해당 노드 각각을 쓸 수 있고 트리의 위에는 모두 을 쓸 수 있습니다. 그러나 단조 증가를 사용하는 경우 이드이므로 트리의 오른쪽 아래에 동일한 경로를 무효화하므로 다시 작성해야 할 노드 수는 최소화됩니다. 도 단조롭게 동일하게 나타납니다. 도 감소합니다. 업데이 트가 있다면 기술적으로 작동해야합니다 그 중 하나 또는 두 개의 노드가 나무의 안쪽에 있지만, 증명하기가 훨씬 어렵습니다.
순차적 ID는 성능상의 이점을 제공하지만 ID가 충돌하므로 둘 이상의 데이터베이스가있을 때 순차적 ID가 유지 보수 할 수 없음을 기억해야합니다.
답변 해 주셔서 감사합니다. 나는 더 긴 끈이 허용하는 우아함을 좋아합니다. 이제는 성능에 대한 염려가 줄어 들었습니다. –