NoSQL과 SQL에 관한 것이 아니라 BASE와 ACID에 관한 것입니다.

Scalable 은 다음과 같은 구성 요소로 분류되어야합니다.

• 읽기 스케일링 = 대량의 읽기 작업 처리
• 쓰기 스케일링 = 대량의 쓰기 작업 처리

기존 RDBMS와 같은 ACID 호환 데이터베이스는 읽기를 확장 할 수 있습니다. (가능한) 성능 병목 현상은 NoSQL (때로는 조인 및 제한과 같은)으로 인해 사용하지 않을 수 있기 때문에 NoSQL 데이터베이스보다 본질적으로 비효율적이지 않습니다. 클러스터 된 SQL RDBMS는 클러스터에 추가 노드를 도입하여 읽기를 확장 할 수 있습니다. 읽기 작업을 확장 할 수있는 범위에는 제한이 있지만 클러스터에 더 많은 노드를 도입 할 때 쓰기를 확장하기가 어렵 기 때문에 적용됩니다.

쓰기 스케일링은 문제가 많은 부분입니다. ACID 원칙에 의해 부과되는 다양한 제약이 있으며, 이는 일관된 기본 아키텍처에서 보이지 않습니다.

• Atomicity는 거래가 전체적으로 완료되거나 실패해야 함을 의미하므로이를 보장하기 위해 많은 부기를 유지해야합니다.
• 일관성 제약 조건은 클러스터의 모든 노드가 동일해야 함을 의미합니다. 한 노드에 쓰는 경우 클라이언트에 응답을 반환하기 전에이 쓰기를 다른 모든 노드에 복사해야합니다. 따라서 기존 RDBMS 클러스터를 확장하기가 어렵습니다.
• 내구성 제약 조건은 쓰기를 잃지 않기 위해 응답이 클라이언트에 반환되기 전에 쓰기가 디스크로 플러시되었는지 확인해야합니다.

특정 지점을 넘어 클러스터의 쓰기 작업 또는 노드 수를 늘리려면 일부 ACID 요구 사항을 완화 할 수 있어야합니다.

• 원자를 삭제하면 테이블 (데이터 세트)이 잠기는 기간을 단축 할 수 있습니다. 예 : MongoDB, CouchDB
• 일관성 삭제를 사용하면 클러스터 노드에서 쓰기를 확장 할 수 있습니다. 예 : riak, cassandra.
• Dropping Durability를 사용하면 디스크를 비우지 않고도 쓰기 명령에 응답 할 수 있습니다. 예 : memcache, redis.

NoSQL 데이터베이스는 일반적으로 ACID 모델 대신 BASE 모델을 따릅니다. A, C 및 / 또는 D 요구 사항을 포기하고 그에 따라 확장 성을 향상시킵니다. Cassandra와 같은 일부는 필요할 때 ACID 보증을 선택할 수 있습니다. 그러나 모든 NoSQL 데이터베이스가 항상 확장 가능한 것은 아닙니다.

SQL API에는 ACID 요구 사항이 완화 된 쿼리를 설명하는 메커니즘이 없습니다. 이것이 BASE 데이터베이스가 모두 NoSQL 인 이유입니다.

개인 참고 사항 : 내가 만들고 싶은 마지막 요점은 NoSQL이 현재 성능을 개선하는 데 사용되는 대부분의 경우 적절한 인덱스가있는 올바르게 정규화 된 스키마를 사용하여 적절한 RDBMS에서 솔루션을 사용할 수 있다는 것입니다. 이 사이트 (MS SQL Server 기반)에서 입증 한 바와 같이 RDBMS는 적절하게 사용하는 경우 높은 워크로드로 확장 할 수 있습니다. RDBMS를 최적화하는 방법을 이해하지 못하는 사람들은 데이터에 어떤 위험을 초래하는지 이해하지 못하기 때문에 NoSQL을 멀리해야합니다.

업데이트 (2019-09-17) :

이 답변을 게시 한 이후 데이터베이스 환경이 발전했습니다. RDBMS ACID 세계와 NoSQL BASE 세계 사이에는 여전히 이분법이 있지만, 그 선은 더 희미 해졌습니다. NoSQL 데이터베이스는 SQL API 및 트랜잭션 지원과 같은 RDBMS 세계의 기능을 추가했습니다. Google Cloud Spanner, YugabyteDB 또는 CockroachDB와 같이 SQL, ACID 및 쓰기 확장 을 약속하는 데이터베이스도 있습니다 . 일반적으로 악마는 세부 사항에 있지만 대부분의 경우 “충분히 ACID”입니다. 데이터베이스 기술과 그 발전 방식에 대해 자세히 살펴 보려면 이 슬라이드 데크를 살펴보십시오 (슬라이드 노트에는 함께 설명되어 있음).

답변