3.1. 약한 ACID 속성
오랫동안 데이터 일관성은 설계자와 개발자에게 신성한 소였습니다. 모든 관계형 데이터베이스는 업데이트 잠금 및 읽기 차단 또는 실행 취소 로그를 통해 일정 수준의 격리를 제공했습니다. 엄청난 양의 정보와 분산 시스템의 출현으로 한편으로는 이들을 위한 일련의 트랜잭션 작업을 보장하고 다른 한편으로는 높은 가용성과 빠른 응답 시간을 확보하는 것이 불가능하다는 것이 분명해졌습니다.
또한 하나의 레코드를 업데이트하더라도 다른 사용자가 시스템의 변경 사항을 즉시 볼 수 있다는 보장은 없습니다. 예를 들어 마스터 노드에서 변경이 발생할 수 있고 복제본이 슬레이브 노드에 비동기식으로 복사되기 때문에 다른 사용자는 이를 통해 공장. 이 경우 일정 시간이 지나면 결과가 표시됩니다. 이를 최종 일관성이라고 하며 Facebook과 Amazon을 포함하여 현재 세계 최대 인터넷 기업이 모두 그렇게 하고 있습니다. 후자는 사용자가 일관성 없는 데이터를 볼 수 있는 최대 간격이 1초를 넘지 않는다고 자랑스럽게 선언합니다. 이러한 상황의 예가 그림에 나와 있습니다.
이러한 상황에서 발생하는 논리적인 질문은 전통적으로 운영의 원자성 일관성에 대한 요구 사항이 높고 동시에 금융, 온라인 상점 등 빠른 분산 클러스터가 필요한 시스템을 어떻게 처리해야 하느냐입니다. 실습에 따르면 이러한 요구 사항은 더 이상 관련이 없습니다. 금융 은행 시스템의 한 설계자는 다음과 같이 말했습니다. 화를 내며 도망칠 것이다. 귀하와 귀하의 파트너가 동시에 돈을 인출하고 한도를 초과하면 어떻게 됩니까? "둘 다 돈을 받고 나중에 고칠 것입니다."
또 다른 예는 그림에 표시된 호텔 예약입니다. 데이터 정책이 최종 일관성을 가정하는 온라인 상점은 이러한 상황에 대한 조치(자동 충돌 해결, 작업 롤백, 다른 데이터로 업데이트)를 제공해야 합니다. 실제로 호텔은 비상시를 대비하여 항상 무료 객실의 "풀"을 유지하려고 노력하며 이는 논란이 되는 상황에 대한 해결책이 될 수 있습니다.
사실 약한 ACID 속성이 전혀 존재하지 않는다는 의미는 아닙니다. 대부분의 경우 관계형 데이터베이스로 작업하는 애플리케이션은 논리적으로 관련된 개체(주문 - 주문 항목)를 변경하기 위해 트랜잭션을 사용합니다. 이는 서로 다른 테이블이기 때문에 필요합니다. NoSQL 데이터베이스에서 데이터 모델의 올바른 디자인을 사용하면(집계는 주문 항목 목록과 함께 주문됨) 관계형 데이터베이스에서와 같이 단일 레코드를 변경할 때 동일한 수준의 격리를 달성할 수 있습니다.
3.2. 분산 시스템, 공유 리소스 없음(아무 것도 공유하지 않음)
다시 말하지만 이것은 구조가 정의상 원격 노드에 잘 분산되지 않는 데이터베이스 그래프에는 적용되지 않습니다.
이것은 아마도 NoSQL 데이터베이스 개발의 주요 주제일 것입니다. 전 세계 정보의 눈사태 증가와 합리적인 시간 내에 처리해야 할 필요성으로 인해 수직 확장 성 문제가 발생했습니다. 프로세서 속도의 증가는 3.5GHz에서 멈추고 디스크에서 읽는 속도도 증가하고 있습니다. 느린 속도와 강력한 서버의 가격은 항상 여러 개의 단순 서버의 총 가격보다 높습니다. 이러한 상황에서 기존의 관계형 데이터베이스는 디스크 어레이에 클러스터된 경우에도 속도, 확장성 및 처리량 문제를 해결할 수 없습니다.
이 상황에서 벗어나는 유일한 방법은 여러 독립 서버가 빠른 네트워크로 연결되고 각각이 데이터의 일부 및/또는 읽기 업데이트 요청의 일부만 소유/처리하는 수평적 확장입니다. 이 아키텍처에서 스토리지 용량(용량, 응답 시간, 처리량)을 늘리려면 클러스터에 새 서버를 추가하기만 하면 됩니다. 샤딩, 복제, 내결함성(하나 이상의 서버가 응답하지 않아도 결과를 얻음), 노드 추가 시 데이터 재분배는 NoSQL 데이터베이스 자체에서 처리합니다.
분산 NoSQL 데이터베이스의 주요 속성을 간략하게 소개하겠습니다.
복제 - 업데이트 시 데이터를 다른 노드로 복사합니다. 둘 다 더 큰 확장성을 달성하고 데이터의 가용성과 안전성을 높일 수 있습니다. 두 가지 유형으로 세분화하는 것이 일반적입니다.
마스터-슬레이브 :
및 피어 투 피어 : 
첫 번째 유형은 읽기에는 좋은 확장성(모든 노드에서 발생할 수 있음)을 가정하지만 쓰기에는 확장 불가능(마스터 노드에만 해당)을 가정합니다. 지속적인 가용성을 보장하는 미묘함도 있습니다(마스터 충돌 시 수동 또는 자동으로 나머지 노드 중 하나가 해당 위치에 할당됨). 두 번째 복제 유형은 모든 노드가 동일하고 읽기 및 쓰기 요청을 모두 처리할 수 있다고 가정합니다.
샤딩은 노드별로 데이터를 나누는 것입니다.
샤딩은 속도와 처리량을 높이기 위해 관계형 데이터베이스에 대한 "버팀목"으로 자주 사용되었습니다. 사용자 애플리케이션은 데이터를 여러 독립 데이터베이스에 분할하고 사용자가 해당 데이터를 요청하면 특정 데이터베이스에 액세스했습니다. NoSQL 데이터베이스에서 복제와 같은 샤딩은 데이터베이스 자체에서 자동으로 수행되며 사용자 애플리케이션은 이러한 복잡한 메커니즘과 별개입니다.
3.3. NoSQL 데이터베이스는 대부분 오픈 소스이며 21세기에 생성되었습니다.
Sadalaj와 Fowler가 개체 데이터베이스를 NoSQL로 분류하지 않은 것은 두 번째 이유입니다(비록 http://nosql-database.org/가 일반 목록에 포함함). 개체 데이터베이스는 90년대에 만들어졌고 그다지 인기를 얻지 못했기 때문입니다. . .
NoSQL 운동은 엄청난 속도로 인기를 얻고 있습니다. 그러나 이것이 관계형 데이터베이스가 흔적이 남거나 구식이라는 의미는 아닙니다. 이전처럼 적극적으로 사용되고 사용될 가능성이 높지만 점점 더 많은 NoSQL 데이터베이스가 이들과 공생할 것입니다. 우리는 서로 다른 데이터 저장소가 서로 다른 요구에 사용되는 다국어 지속성의 시대에 접어들고 있습니다. 이제 경쟁이 없는 데이터 소스로서 관계형 데이터베이스의 독점은 없습니다. 점점 더 많은 아키텍트가 데이터 자체의 특성과 이를 조작하는 방법, 예상되는 정보의 양을 기준으로 스토리지를 선택하고 있습니다. 그래서 모든 것이 더 흥미로워집니다.
아래에서는 NoSQL Cassandra DBMS를 예로 사용하여 분산 데이터베이스의 작동을 이해하려고 노력할 것입니다.