noSQL 데이터베이스가 SQL보다 확장 성이 뛰어난 이유는 무엇입니까?

최근에는 noSQL DBMS에 대해 많이 읽었습니다. 나는 CAP 정리 , ACID 규칙, 기본 규칙 및 기본 이론을 이해합니다. 그러나 왜 noSQL이 RDBMS보다 더 쉽게 확장 가능한지에 대한 리소스를 찾지 못했습니다 (예 : 많은 DB 서버가 필요한 시스템의 경우)?

제약 조건과 외래 키를 유지하는 데 리소스가 필요하고 DBMS가 배포되면 훨씬 복잡합니다. 그러나 나는 이것보다 훨씬 더 많은 것을 기대합니다.

noSQL / SQL이 확장성에 어떤 영향을 미치는지 설명해 주시겠습니까?

noSQL 데이터베이스는 본질적으로 SQL 데이터베이스가 제공하는 방대한 기능을 포기합니다.

참조 무결성, 트랜잭션 등의 자동 시행과 같은 것. 일부 문제에 대해 매우 편리하며 단일 서버 외부에서 확장하기 위해 흥미로운 기술이 필요합니다. 원자 트랜잭션을위한 테이블이며 다른 서버에 있습니다!).

noSQL 데이터베이스에는이 모든 것이 없습니다. 그 물건이 필요하다면 직접해야하지만 필요하지 않은 경우 (그리고 많은 응용 프로그램이 필요하지 않은 경우), 소년 짖는 소리가 운이 있습니다. DB는 이러한 복잡한 작업을 모두 수행 할 필요가 없으며 많은 데이터 세트에서 잠금을 수행 할 필요가 없으므로 많은 서버 / 디스크 / 무엇을 통해 파티션을 나누고 실제로 빠르게 작업 할 수 있습니다.

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"입니다. 데이터베이스 기술과 그 발전 방식에 대해 자세히 살펴 보려면 이 슬라이드 데크를 살펴보십시오 (슬라이드 노트에는 함께 설명되어 있음).

NoSQL 데이터베이스 (MongoDB, Redis, Riak, Memcached 등)는 외래 키 제약 조건을 유지하지 않으며 원자 연산을보다 명시 적으로 지정해야합니다. SQL 데이터베이스 (SQL Server, Oracle, PostgreSQL 등)는 노련한 DBA에 의해 매우 큰 성능 요구 사항을 처리하도록 확장 될 수 있습니다.

NoSQL 데이터베이스를 사용하면 경쟁 조건 및 원 자성 작업을 잘 알고있는 노련한 프로그래머가 오늘날의 웹 응용 프로그램 코드 중 적은 비율로만 필요한 대량의 처리를 포기할 수 있습니다. NoSQL 데이터베이스는 확실히 원 자성 연산을 가지며 SQL 데이터베이스에 존재하는 대부분의 모든 트랜잭션 요구 사항은 NoSQL 데이터베이스를 얻을 수도 있습니다. 차이점은 추상화 수준입니다. NoSQL 데이터베이스는 더 높은 수준의 추상화를 제거하고 해당 기능을 응용 프로그램 프로그래머에게 넘겨 주므로 비 시즌적인 프로그래머에 의한 데이터 손상 가능성이 높아져 코드 전체가 더 빨라집니다.

결과적으로 개발 시간과 성능이 매우 중요한 웹 애플리케이션 공간에서 NoSQL 데이터베이스가 점점 더 많이 사용되는 것을 볼 수 있습니다. 금융 및 기업 소프트웨어는 하드웨어 성능이 상대적으로 저렴하고 DBA에 대한 경험이 풍부하고 비 시즌적인 프로그래머로 인한 위험 증가가 만족스럽지 않기 때문에 SQL 유산을 유지할 가능성이 높습니다.

IBM developerWorks : NoSQL 데이터베이스로 클라우드 레벨 데이터 확장 성 제공

확장 성은 매우 낮은 대기 시간으로 요청 속도가 매우 높은 매우 큰 데이터베이스를 지원할 수있는 시스템입니다.

NoSQL 시스템에는 다음과 같은 여러 가지 디자인 기능이 있습니다.

• 많은 서버에서 처리량을 수평으로 확장 할 수 있습니다.
• 간단한 호출 레벨 인터페이스 또는 프로토콜 (SQL 바인딩과 대조).
• 대부분의 기존 RDBMS에서 ACID 트랜잭션보다 약한 일관성 모델을 지원합니다.
• 데이터 저장을 위해 분산 인덱스 및 RAM을 효율적으로 사용합니다.
• 새로운 속성 또는 데이터 스키마를 동적으로 정의하는 기능.

관계형 데이터베이스가 스케일링에 최적이 아닌 이유

일반적으로 관계형 데이터베이스 관리 시스템은 수십 년 동안 "데이터 지속성 및 검색을위한 모든 규모의 솔루션"으로 간주되었습니다. 그들은 광범위한 연구 개발 노력을 거쳐 성숙해 왔으며 다양한 비즈니스 영역에서 대규모 시장과 솔루션을 성공적으로 창출했습니다.

확장 성과 새로운 애플리케이션 요구 사항에 대한 요구가 계속 증가함에 따라 일부 웹 스케일 애플리케이션에서이 모든 규모의 접근 방식에 대한 불만이 발생하는 등 기존 RDBMS에 새로운 과제가 발생했습니다. 이에 대한 답은 관계형 데이터베이스 관리 시스템의 지배에 도전하도록 설계된 차세대 저비용 고성능 데이터베이스 소프트웨어입니다. NoSQL의 움직임에 대한 큰 이유는 웹, 엔터프라이즈 및 클라우드 컴퓨팅 응용 프로그램의 구현마다 데이터베이스 요구 사항이 다르기 때문입니다. 예를 들어 모든 응용 프로그램에 엄격한 데이터 일관성이 필요한 것은 아닙니다.

또 다른 예 : eBay, Amazon, Twitter 또는 Facebook과 같은 대용량 웹 사이트의 경우 확장 성과 고 가용성은 타협 할 수없는 필수 요구 사항입니다. 이러한 응용 프로그램의 경우 약간의 중단이라도 중대한 재정적 영향을 미치고 고객의 신뢰에 영향을 줄 수 있습니다.

DBA.SE 이상 : 수평 스케일링이란 무엇입니까?

수평 스케일링은 기본적으로 구축되는 대신 구축됩니다. 더 큰 서버를 구입하지 않고 모든 부하를 서버로 옮기는 대신 1 대 이상의 추가 서버를 구입하여 서버간에 부하를 분산시킵니다.

수평 확장은 서버에서 여러 인스턴스를 동시에 실행할 수있는 경우에 사용됩니다. 일반적으로 1 서버에서 2 서버로 이동하는 것이 훨씬 어렵습니다. 그런 다음 2에서 5, 10, 50 등으로 이동합니다.

병렬 인스턴스 실행 문제를 해결 한 후에는 Amazon EC2, Rackspace 's Cloud Service, GoGrid 등의 환경을 활용하여 필요에 따라 인스턴스를 위 / 아래로 끌어 올릴 수 있으므로 서버 전력 비용을 절감 할 필요가 없습니다. 이러한 최대 부하를 다루기 위해 사용하지는 않습니다.

관계형 데이터베이스는 전체 읽기 / 쓰기를 병렬로 실행하기 어려운 항목 중 하나입니다.