나는 쿼리하고자하는 큰 데이터 세트가 있습니다. 쿼리는 변경되지 않지만 기본 데이터는 변경됩니다. 내가 읽은 것에서부터 나는 "견해"를 만들고 그것을 질의 할 수 있었다. 또한, 카우치 DB는 데이터가 변경 될 때 뷰를 업데이트하는 방법을 알고 있으므로 뷰를 다시 쿼리하는 것이 여전히 빠르다는 것을 알고 있다고 읽었습니다.속도, CouchDB보기 및 대안
내 질문은, 나는 CounchDB의 견해를 정확하게 이해합니까? CouchDB의 다른 기능은 필요하지 않습니다. SQL을 필요로하지 않습니다. 원하는 모든 것은 데이터 변경에 대해 동일한 쿼리입니다. 다른 것을 사용할 수 있을까요? 예전의 좋은 MySQL을 CouchDB보다 느리게 사용한다면 (위의 시나리오에서 다양한 DB가 대략 어떻게 수행 할 것인가?)
귀하가 제공 한 정보를 바탕으로 누구든지 귀하의 질문에 답변 할 수 있다고 생각하지 않습니다.
관계형 데이터베이스의 색인은 CouchDB보기와 유사합니다. 두 경우 모두 사전 정렬 된 데이터 인스턴스를 저장하고 데이터베이스는 해당 인스턴스를 표준 데이터와 동기화 된 상태로 유지합니다. 두 가지 유형의 데이터베이스는 모두 인덱스/뷰를 투명하게 사용하여 인덱스/뷰가 디자인 된 양식의 후속 쿼리를 빠르게 처리합니다.
인덱스/뷰가 없으면 쿼리는 n 데이터 레코드의 전체 모음을 검색해야하며 O(n) 시간에 실행됩니다. 쿼리가 인덱스/뷰의 이점을 얻을 때 O(log n) 시간에 실행됩니다.
그러나 이는 데이터 볼륨에 대한 성능 곡선을 매우 광범위하게 말합니다. 주어진 데이터베이스는 어떤 경우이든간에 빠른 성능을 발휘할 수 있기 때문에 어떤 제품이든 다른 제품을 능가합니다. 브랜드 X가 브랜드 Y보다 항상 빠르다는 일반화는 어렵습니다. 특정 사례에 대해 확신 할 수있는 유일한 방법은 두 데이터베이스 모두에서이 사례를 시도하고 성능을 측정하는 것입니다.
귀하의 평가는 정확합니다. 즐겨!
언급 할 가치가있는 유일한 성능 트릭은 emit()보기에서 필요한 모든 데이터를 볼 수 있으며 ?include_docs 기능을 절대로 사용하지 않으면 include_docs가 CouchDB가 기본 데이터베이스로 돌아가서 해당 행을 발생시킨 원본 문서 다시 말하면, 당신은 당신의 뷰 인덱스 (더 많은 공간이지만 더 빠름)에 필요한 모든 것을 emit()으로 만들거나 원래의 문서로 다시 사용할 수 있습니다. (공간은 적지 만 느리지 만)
인덱스는 미리 정렬되어 있다는 것을 알고있었습니다. (예 : O (log N))하지만 조회수가 새로 업데이트 된 데이터로 자동 채워지므로 검색이 전혀 없을 것이라고 생각했습니다. 다시 말해, 나는 견해가 견해와 매우 다르다고 생각했는데, 어떤 성과가 ... Btw, 정보가 충분하지 않다고 말하면, 좀 더 구체적으로 표현해 주시겠습니까? 데이터의 양과 마찬가지로? 나는 또한 질의가 다른 것보다 동일하고 데이터가 변하는 것이 더 중요하다고 생각했다 .... –
어떤 제품이 최상의 성능을 발휘 하는가는 특정 질의 및 정의한 색인 /보기에 달려있다. 그것이 내가 충분한 정보가 아니라는 것을 의미합니다. 각 제품에는 강점과 약점이 있으므로 최적화해야하는 쿼리를 알고 난 후에 만 최적화 할 수 있습니다. –
또한 인덱스에 결과에 필요한 모든 열이 포함되어 있으면 검색을 피하기 위해 인덱스를 사용할 수 있습니다. 이를 색인 *이라고합니다. 물론 많은 RDBMS 브랜드에서 한 번에 한 테이블의 열에 대해서만 인덱스를 정의 할 수 있으므로 CouchDB 뷰보다 다용도가 적을 수 있습니다. –