NoSQL 데이터베이스 사용은 컨텐츠로 검색해야하는 대규모 데이터 세트에 비실용적입니까?

저는 일주일 동안 NoSQL 데이터베이스에 대해 배웠습니다.

저는 NoSQL 데이터베이스의 장점과 많은 유스 케이스를 잘 알고 있습니다.

그러나 종종 사람들은 NoSQL이 관계형 데이터베이스를 대체 할 수있는 것처럼 기사를 작성합니다 . 그리고 나는 내 머리를 얻을 수없는 요점이 있습니다.

NoSQL 데이터베이스는 종종 키-값 저장소입니다.

물론 할 수 저장 (JSON에서, XML을, 어떤 데이터를 인코딩하여) 키 - 값 저장소에 모든 것을,하지만 내가 보는 문제는 당신이 할 필요가 있다는 것입니다 수 많은에 특정 기준과 일치하는 데이터의 일부 금액을 사용 사례. NoSQL 데이터베이스에는 효과적으로 검색 할 수있는 기준이 하나뿐입니다 (키). 관계형 데이터베이스는 데이터 행의 모든 ​​값을 효과적으로 검색하도록 최적화되어 있습니다.

따라서 NoSQL 데이터베이스는 내용으로 검색해야하는 데이터를 유지하기위한 선택이 아닙니다. 아니면 내가 잘못 이해 했습니까?

예를 들면 :

웹샵에 대한 사용자 데이터를 저장해야합니다.

관계형 데이터베이스에서는 모든 사용자를 usersID, 이름, 국가 등이 포함 된 표의 행으로 저장합니다 .

NoSQL 데이터베이스에서는 ID를 키로 사용하고 모든 데이터 (JSON 등으로 인코딩)를 값으로 사용하여 각 사용자를 저장합니다.

따라서 특정 국가에서 모든 사용자를 확보해야하는 경우 (어떤 이유로 마케팅 담당자가 이에 대해 알아야 할 경우) 관계형 데이터베이스에서는 쉽게 수행 할 수 있지만 NoSQL 데이터베이스에서는 그다지 효과적이지 않습니다. 모든 사용자를 확보 하고 모든 데이터를 구문 분석 하고 필터링하십시오.

나는 그것이 불가능하다고 말하지는 않지만 훨씬 까다로워서 NoSQL 항목의 데이터를 검색하려는 경우 효과적이지 않을 것이라고 생각합니다.

이 국가에 거주하는 모든 사용자의 키를 저장하는 각 국가의 키를 생성하고이 국가의 키에 보관 된 모든 키를 가져와 특정 국가의 사용자를 확보 할 수 있습니다. 그러나이 기술은 복잡한 데이터 세트를 훨씬 더 복잡하게 만듭니다. 구현하기가 어렵고 SQL 데이터베이스 쿼리만큼 효과적이지 않습니다. 그래서 나는 그것이 프로덕션에서 사용하는 방법이 아니라고 생각합니다. 아니면?

그런 유스 케이스를 처리하기 위해 무언가를 잘못 이해했거나 일부 개념이나 모범 사례를 간과했는지 확실하지 않습니다. 어쩌면 당신은 내 진술을 수정하고 내 질문에 대답 할 수 있습니다.

NoSQL이 모든 데이터베이스 문제에 대한 만병 통치약이 아니라는 전제에 동의하지만 한 가지 핵심 사항을 오해하고 있다고 생각합니다.

NoSQL 데이터베이스에는 효과적으로 검색 할 수있는 기준 (키) 만 있습니다.

이것은 사실이 아닙니다.

예를 들어 MongoDB는 인덱스를 지원합니다. ( https://docs.mongodb.org/v3.0/core/indexes-introduction/에서 )

인덱스는 MongoDB에서 효율적인 쿼리 실행을 지원합니다. 인덱스가 없으면 MongoDB는 컬렉션 검색을 수행해야합니다. 즉, 쿼리 문과 일치하는 문서를 선택하려면 컬렉션의 모든 문서를 검색해야합니다. 쿼리에 적합한 인덱스가 있으면 MongoDB는 인덱스를 사용하여 검사해야하는 문서 수를 제한 할 수 있습니다.

인덱스는 컬렉션 데이터 세트의 작은 부분을 트래버스하기 쉬운 형태로 저장하는 특수 데이터 구조입니다 [1]. 색인은 특정 필드 또는 필드 세트의 값을 필드 값에 따라 순서대로 저장합니다. 인덱스 항목의 순서는 효율적인 동등 일치 및 범위 기반 쿼리 작업을 지원합니다. 또한 MongoDB는 색인의 순서를 사용하여 정렬 된 결과를 반환 할 수 있습니다.

couchbase와 마찬가지로 ( http://docs.couchbase.com/admin/admin/Views/views-intro.html에서 )

카우치베이스 뷰를 사용하면 데이터를 인덱싱하고 쿼리 할 수 ​​있습니다.

뷰는 정의 된 형식과 구조에 따라 데이터에 대한 인덱스를 만듭니다. 뷰는 Couchbase의 객체에서 추출 된 특정 필드와 정보로 구성됩니다.

실제로 키-값 저장소가 아닌 NoSQL 데이터베이스 자체를 호출하는 것은 실제로 어떤 종류의 인덱싱 체계를 지원해야합니다.

실제로 이러한 인덱스 구성표의 유연성은 종종 NoSQL을 빛나게합니다. 제 생각에는 NoSQL 인덱스를 정의하는 데 사용되는 언어는 종종 SQL보다 표현력이 뛰어나고 자연스럽고 일반적으로 테이블 외부에 있으므로 테이블 스키마를 지원하기 위해 테이블 ​​스키마를 변경할 필요가 없습니다. (당신이 SQL에서 비슷한 일을 할 수는 없지만 나에게 훨씬 더 많은 후프 점프가 있다고 생각합니다).

일반적으로 워크 플로가 관계형 데이터베이스 쿼리와 완벽하게 일치하면 관계형 데이터베이스가 가장 효율적인 방법이라는 것을 알게 될 것입니다. 그것은 긴장 론적이지만 사실입니다.

많은 NoSQL 옹호자들이 주장하는 주장은 많은 워크 플로가 실제로 관계형 형식으로 마사지되었고 그러한 마사지 전에보다 효과적이었을 것입니다. 이 주장의 유효성은 확인하기가 복잡합니다. 분명히 SQL 쿼리에 의해 잘 설명 된 작업이 있습니다. 내 경험에 따르면 , 관계형 프로그래밍 작업은 NoSQL을 사용하여 거의 같은 수준의 효율성으로 수행 할 수 있다고 말할 수 있습니다. 그러나 그것은 좁은 경험에 근거한 매우 주관적인 진술입니다.

NoSQL 접근 방식의 판매가 대형 데이터베이스를 전제로 한 것 같습니다. 데이터베이스가 클수록 더 큰 데이터 세트를 지원하기 위해 워크 플로우를 정리해야합니다. NoSQL은 그루밍 노력을 더 잘 지원하는 것으로 보입니다. 따라서 데이터베이스가 클수록 NoSQL의 기능이 더 중요 할 수 있습니다.

이 예제를 사용하려면 국가별로 SQL 쿼리에서 명시 적으로 SQL users에 국가별로 테이블 을 인덱싱하도록 지시하지 않는 한 모든 국가의 NoSQL 스캔만큼 느립니다 . NoSQL은 동일한 작업을 수행 할 수 있으며, 여기서는 SQL이 후드 인 것처럼 정렬 된 키-값 컬렉션을 생성하고 유지 관리합니다.

차이점? SQL 엔진에는 테이블을 기본적으로 색인화하는 개념이있었습니다. 즉, 작업을 덜해야합니다 (테이블에 색인을 추가하기 만하면 됨). 그러나 또한 통제력이 떨어졌음을 의미합니다. 대부분의 경우, SQL 엔진이 작업을 수행하는 대신 제어 손실이 허용됩니다. 그러나 대규모 데이터 세트에서는 일반적인 SQL ACID 모델과 다른 일관성 모델을 원할 수 있습니다. 최종 일관성을 지원하는 BASE 모델을 사용할 수 있습니다. SQL 엔진이 작업을 수행하므로 SQL 엔진의 규칙에 따라 수행되어야하므로 SQL에서는 매우 어려울 수 있습니다. NoSQL에서 이러한 레이어는 일반적으로 노출되어 해킹 할 수 있습니다.

NoSQL은 기본적으로 관계가없는 모든 데이터베이스 시스템을 다루기 때문에 다소 모호한 용어입니다.

설명하는 것은 키-값 저장소 입니다.이 키 저장소 는 일종의 데이터베이스로 키 아래에 저장되며 키를 알고 있으면 빠르게 조회 할 수 있습니다. 정확한 키를 알고 있으면 이러한 데이터베이스가 엄청나게 빠르지 만 직접 말하면 데이터의 여러 속성을 검색하거나 필터링해야 할 경우 속도가 느리고 번거로울 수 있습니다.

올바른 가치를 가진 사람은 키-값 저장소가 일반적으로 관계형 데이터베이스를 대체 할 수 있다고 주장하지 않습니다. 그러나 키-값 저장소가 적합한 특정 사용 사례가있을 수 있습니다. 키-값 저장소는 일반적으로 ID별로 항목을 캐시하지만 캐시에 대해 임시 쿼리를 수행 할 필요가 없기 때문에 캐싱에 자주 사용됩니다. 예를 들어 Stackoverflow 사이트 자체는 Redis (키-값 db)를 광범위하게 사용 하지만 출력 캐싱에만 사용합니다. 기본 정식 데이터는 여전히 관계형 데이터베이스에 유지됩니다.

따라서 대답은 매우 분명합니다. 단일 키만 사용하여 저장하고 조회해야하는 경우 키-값 저장소를 사용하십시오. 그렇지 않으면 다른 종류의 데이터베이스를 사용하십시오. 의심스러운 경우 관계형 데이터베이스를 사용하십시오. 관계형 데이터베이스는 가장 다양한 종류의 데이터베이스이므로 NoSQL 데이터베이스는 종종 매우 특정한 사용 사례에 최적화되어 있습니다.

관계형 데이터베이스에 대한 주장은 더 이상 데이터가 많은 지점에서 더 이상 단일 서버에 복사 할 수 없을 때까지 사실입니다. 그런 다음 모든 종류의 흥미로운 문제가 발생하기 시작합니다. 대부분의 쿼리가 단일 서버에서 실행될 수 있도록 테이블을 어떻게 분할합니까? 몇 개의 데이터 사본을 작성합니까? 해당 사본 간의 불일치를 어떻게 처리합니까? 상대적으로 지리적으로 가까운 데이터 센터에 사용자 데이터를 어떻게 유지합니까?

이러한 목표는 종종 서로 상충됩니다. 많은 트위터 사용자가 전 세계의 사람들을 팔로우합니다. 트위터의 데이터베이스는 트윗을 읽거나 트윗을 작성하기 위해 지리적으로 최적화되어야합니까?

이러한 종류의 규모를 다룰 때 솔루션을 발명하고 중복성을 추가하며 NoSQL 데이터베이스와 매우 유사한 제한을 부과하기 시작합니다. 모든 데이터를 하나의 상자에 넣을 수 있다면 제한 사항 만 받고 혜택을 누릴 필요가 없습니다.

NoSQL 데이터베이스는“ No SQL” 과 관련이 거의 없습니다 .

그들은 당신이 데이터베이스를 가질 수 있다고 인정에 대한 있습니다 규모의 항상 일치 하고 복잡한 트랜잭션을 지원 하고 내구성이 있습니다.

일반적인 관계형 데이터베이스에서는 모든 인덱스가 트랜잭션 범위 내에서 자동으로 업데이트되므로 모든 쿼리에 사용할 수 있습니다.

NoSQL 데이터베이스에서 프로그래머는 많은 인덱스를 유지 관리해야하며 인덱스가 항상 오래된 것으로 가정합니다.

예를 들면 다음과 같습니다.

• 세금 번호 별 사람들의 색인에는 세금 등록 절차를 완료하지 않은 사람들이 포함될 수 있습니다.
• 따라서 색인을 사용하는 코드는 세금에 대한 불완전한 등록에 대처할 수 있어야합니다
• 또 다른 옵션은 세금으로 등록 된 사람이 색인에없는 시간을 갖는 것입니다. (따라서 디자인은 일관된 데이터가없는 것에 대처하고 데이터가 어떻게 일관성이 없는지 결정해야합니다.)

실제 예를 들어, 아마존은 106 개의 컴퓨터가 올바른 잠금이 해제되었음을 확인함으로써 웹 페이지의 표시를 지연시키는 것보다 오래된 책에 대한 설명을 보여줄 것입니다.

따라서.....

단일 정상 관계형 데이터베이스가 모든 데이터를 보유하고 잠금으로 인해 시스템이 유용한 작업을 수행하지 못하도록 각 트랜잭션을 신속하게 처리 할 수있는 경우 관계형 데이터베이스가 최선의 선택입니다.

그러나 둘 이상의 관계형 데이터베이스 사용에 대해 생각하거나 잠금 오류를 피하기 위해 트랜잭션을 분할해야하는 즉시“NoSQL”데이터베이스를 사용할 때 발생하는 문제에 대처해야합니다.

“NoSQL”데이터베이스는 이러한 문제를 숨기지 않기 때문에 시스템을 확장 할 때 최상의 옵션이 될 수 있습니다. 그러나 Stackoverflow는 캐싱 계층에서 NoSQL을 제한적으로 사용하여 모든 데이터를 저장하기 위해 관계형 데이터베이스를 계속 사용한다는 점을 기억하십시오. 따라서 NoSQL을 사용하여 데이터를 저장하기 전에는 매우 커야합니다.

관계형 데이터베이스는 데이터 행의 모든 ​​값을 효과적으로 검색하도록 최적화되어 있습니다.

행에서 "모든"값을 검색하는 기능과 행에서 "모든"값을 검색하는 기능을 혼동하지 마십시오. 이를 수행하는 가장 효과적인 방법은 하나 이상의 색인이 필요합니다. 색인에 모든 필드가 포함될 수 있지만 색인 변경 (삽입, 업데이트, 삭제)이 필요한 변경 작업을 수행하는 데 방해가됩니다. 귀하 (또는 귀하의 DBA)는 데이터, 사용법, 병목 현상 등을 이해해야합니다.

이미 많은 답변이 있지만 요약을 추가하고 싶었습니다.

분명히 NoSQL 개념은 디스크에서 데이터를 구성하고 메모리 내에서 쿼리 언어를 통해 데이터를 노출하는 다양한 접근 방식을 다룹니다 (일부는 SQL과 유사합니다). 필자의 견해로는이 다양한 시스템에서 장점이 제공되므로 작업에 가장 적합한 도구를 선택할 수 있습니다. 그러나 여전히 몇 가지 다른 솔루션으로 수십 가지 요구를 충족시킬 수 있기를 바랍니다. 수십 가지의 다른 시스템을 관리하고 싶지 않을 것입니다.

관계형 데이터베이스는 매우 멀리 떨어져 있고 입증 된 기술이지만 데이터베이스와 마찬가지로 각 프로젝트의 요구에 따라 프로그래밍 언어를 선택할 수 있습니다 (그러나 팀의 경험도 고려).

저는 2 년 동안 couchdb를 사용해 왔습니다. 주로 콘텐츠 관리 및 구성에 사용됩니다.

계층 적 관계의 경우 시각화 할 때 관리하기가 훨씬 쉽습니다. 대부분 읽기 데이터의 경우 많은 경우 UPDATE 문을 작성하는 것보다 JSON을 편집하는 것이 더 쉽습니다. 실제로 JSON을 편집하는 데 프로그래머가 필요하지 않습니다. 그리고 SQL은 행과 열을 제공하며, 그런 다음 일종의 객체 구조로 매핑해야합니다.

복잡한 쿼리에서 10-20 개의 테이블을 조인하지 않기 때문에 성능이 향상됩니다. Couchdb 뷰는 기반으로하는 자바 스크립트가 쿼리시 실행되지 않기 때문에 매우 빠릅니다.

대부분의 프로그래머는 Javascript를 이해하고 대부분의 프로그래머는 때때로 SQL로 어려움을 겪습니다.

Couchdb에서 뷰는 JSON 문서의 추상으로 생각할 수 있습니다. 뷰 데이터의 구조는 사용자가 결정합니다 (원래 계층에 의해 제한되지 않음).

트랜잭션이 많은 데이터에는 Couchdb를 사용하지 않지만 부품 폭발 유형 구조의 반 정적 데이터에는 SQL보다 작업하기가 훨씬 쉽습니다.

그러나 적용 할 수있는 명확한 '정규화'가 없으며 (데이터 복제를 피하는 것이 가치있는 목표 임에도 불구하고) 낙관적 잠금과 유사한 본질적이고 '낙관적'업데이트 전략이 있습니다.