NewSQL = NoSQL+ACID

최근까지 Odnoklassniki는 SQL Server에서 실시간으로 처리된 약 50TB의 데이터를 저장했습니다. 이러한 볼륨의 경우 SQL DBMS를 사용하여 빠르고 안정적인 데이터 센터 액세스를 제공하는 것은 거의 불가능합니다. 일반적으로 이러한 경우 NoSQL 스토리지 중 하나가 사용되지만 모든 것이 NoSQL로 전송될 수는 없습니다. 일부 엔터티에는 ACID 트랜잭션 보장이 필요합니다.

이로 인해 우리는 NoSQL 시스템의 내결함성, 확장성 및 성능을 제공하면서도 동시에 ACID를 유지하면 기존 시스템에 친숙한 DBMS인 NewSQL 스토리지를 사용하게 되었습니다. 이 새로운 등급의 산업 시스템은 거의 작동하지 않으므로 우리는 이러한 시스템을 직접 구현하여 상업 운영에 투입했습니다.

작동 방식과 발생한 일 - 컷 아래를 읽어보세요.

현재 Odnoklassniki의 월간 독자 수는 70천만 명이 넘는 순 방문자입니다. 우리 우리는 상위 XNUMX위 안에 들어요 세계에서 가장 큰 소셜 네트워크이자 사용자가 가장 많은 시간을 보내는 8000개 사이트 중 하나입니다. OK 인프라는 프런트당 초당 백만 개가 넘는 HTTP 요청이라는 매우 높은 로드를 처리합니다. 1개 이상의 서버 집합 중 일부는 XNUMX개의 모스크바 데이터 센터에 서로 가까이 위치해 있어 이들 사이의 네트워크 대기 시간이 XNUMXms 미만입니다.

우리는 2010년부터 버전 0.6부터 Cassandra를 사용해 왔습니다. 현재 수십 개의 클러스터가 운영되고 있습니다. 가장 빠른 클러스터는 초당 4만 개 이상의 작업을 처리하며 가장 큰 저장 공간은 260TB입니다.

그러나 이들은 모두 저장용으로 사용되는 일반적인 NoSQL 클러스터이다. 약하게 조정된 데이터. 우리는 Odnoklassniki 창립 이후 사용되어 온 일관된 주요 스토리지인 Microsoft SQL Server를 교체하고 싶었습니다. 스토리지는 300TB의 데이터(비즈니스 엔터티)가 포함된 50개 이상의 SQL Server Standard Edition 시스템으로 구성되었습니다. 이 데이터는 ACID 트랜잭션의 일부로 수정되며 다음이 필요합니다. 높은 일관성.

SQL Server 노드 전체에 데이터를 배포하기 위해 우리는 수직 및 수평을 모두 사용했습니다. 파티셔닝 (샤딩). 역사적으로 우리는 간단한 데이터 샤딩 체계를 사용했습니다. 각 엔터티는 엔터티 ID의 기능인 토큰과 연결되었습니다. 동일한 토큰을 가진 엔터티는 동일한 SQL Server에 배치되었습니다. 기본 레코드와 하위 레코드의 토큰이 항상 일치하고 동일한 서버에 위치하도록 마스터-디테일 관계가 구현되었습니다. 소셜 네트워크에서는 거의 모든 기록이 사용자를 대신하여 생성됩니다. 즉, 하나의 기능 하위 시스템 내의 모든 사용자 데이터가 하나의 서버에 저장된다는 의미입니다. 즉, 비즈니스 트랜잭션에는 거의 항상 하나의 SQL 서버의 테이블이 포함되므로 별도의 테이블을 사용하지 않고도 로컬 ACID 트랜잭션을 사용하여 데이터 일관성을 보장할 수 있습니다. 느리고 신뢰할 수 없음 분산 ACID 트랜잭션.

샤딩 덕분에 SQL 속도가 향상되었습니다.

• 샤딩할 때 엔터티 ID가 다른 서버에 있을 수 있으므로 외래 키 제약 조건을 사용하지 않습니다.
• DBMS CPU의 추가 부하로 인해 저장 프로시저 및 트리거를 사용하지 않습니다.
• 위의 모든 사항과 디스크에서 무작위 읽기가 많기 때문에 JOIN을 사용하지 않습니다.
• 트랜잭션 외부에서는 교착 상태를 줄이기 위해 Read Uncommitted 격리 수준을 사용합니다.
• 우리는 짧은 트랜잭션(평균 100ms 미만)만 수행합니다.
• 교착 상태가 많기 때문에 다중 행 UPDATE 및 DELETE를 사용하지 않습니다. 한 번에 하나의 레코드만 업데이트합니다.
• 우리는 항상 인덱스에 대해서만 쿼리를 수행합니다. 전체 테이블 스캔 계획이 있는 쿼리는 데이터베이스에 과부하가 걸려 실패를 초래한다는 것을 의미합니다.

이러한 단계를 통해 우리는 SQL 서버의 성능을 거의 최대화할 수 있었습니다. 그러나 문제는 점점 더 많아졌습니다. 그들을 살펴보자.

SQL 문제

• 자체 작성 샤딩을 사용했기 때문에 새 샤드 추가는 관리자가 수동으로 수행했습니다. 그동안 확장 가능한 데이터 복제본은 요청을 처리하지 못했습니다.
• 테이블의 레코드 수가 늘어날수록 삽입 및 수정 속도가 느려지고, 기존 테이블에 인덱스를 추가할 때는 속도가 몇 배로 떨어지며, 인덱스 생성 및 재생성은 다운타임과 함께 발생합니다.
• 프로덕션 환경에 SQL Server용 Windows가 소량 있으면 인프라 관리가 어려워집니다.

하지만 가장 큰 문제는

결함 허용

클래식 SQL 서버는 내결함성이 낮습니다. 데이터베이스 서버가 하나만 있고 20년에 한 번씩 오류가 발생한다고 가정해 보겠습니다. 이 시간 동안 사이트는 64분 동안 다운되는데, 이는 허용되는 시간입니다. 서버가 200개라면 사이트는 XNUMX주에 한 번씩 다운됩니다. 그리고 서버가 XNUMX개라면 사이트가 매주 작동하지 않습니다. 이것은 문제예요.

SQL Server의 내결함성을 향상시키기 위해 무엇을 할 수 있습니까? Wikipedia는 우리를 빌드하도록 초대합니다. 고가용성 클러스터: 구성 요소 중 하나라도 오류가 발생하는 경우 백업 구성 요소가 있습니다.

이를 위해서는 값비싼 장비가 필요합니다. 수많은 복제, 광섬유, 공유 스토리지 및 예비 포함이 안정적으로 작동하지 않습니다. 스위칭의 약 10%는 메인 노드 뒤의 열차처럼 백업 노드의 오류로 끝납니다.

그러나 이러한 고가용성 클러스터의 주요 단점은 해당 클러스터가 위치한 데이터 센터에 장애가 발생할 경우 가용성이 전혀 없다는 것입니다. Odnoklassniki에는 XNUMX개의 데이터 센터가 있으며, 그 중 하나에 완전한 장애가 발생하는 경우에도 운영을 보장해야 합니다.

이를 위해 우리는 사용할 수 있습니다 다중 마스터 SQL Server에 내장된 복제. 이 솔루션은 소프트웨어 비용으로 인해 훨씬 ​​더 비싸고 복제와 관련하여 잘 알려진 문제(동기 복제의 예측할 수 없는 트랜잭션 지연 및 비동기 복제의 복제 적용 지연(결과적으로 수정 사항 손실))로 인해 어려움을 겪습니다. 묵시적인 수동 충돌 해결 이 옵션을 우리에게 전혀 적용할 수 없게 만듭니다.

이 모든 문제에는 근본적인 해결책이 필요했고 우리는 이를 자세히 분석하기 시작했습니다. 여기서 우리는 SQL Server가 주로 수행하는 작업인 트랜잭션에 대해 알아야 합니다.

단순거래

응용 SQL 프로그래머의 관점에서 가장 간단한 트랜잭션인 앨범에 사진을 추가하는 작업을 생각해 보겠습니다. 앨범과 사진은 서로 다른 접시에 저장됩니다. 앨범에는 공개 사진 카운터가 있습니다. 그런 다음 이러한 거래는 다음 단계로 나뉩니다.

1. 열쇠로 앨범을 잠급니다.
2. 사진 테이블에 항목을 만듭니다.
3. 사진이 공개 상태인 경우 앨범에 공개 사진 카운터를 추가하고 기록을 업데이트하고 거래를 커밋합니다.

또는 의사코드에서는 다음과 같습니다.

TX.start("Albums", id);
Album album = albums.lock(id);
Photo photo = photos.create(…);

if (photo.status == PUBLIC ) {
    album.incPublicPhotosCount();
}
album.update();

TX.commit();

비즈니스 트랜잭션의 가장 일반적인 시나리오는 데이터베이스의 데이터를 애플리케이션 서버의 메모리로 읽고, 무언가를 변경하고, 새 값을 데이터베이스에 다시 저장하는 것입니다. 일반적으로 이러한 트랜잭션에서는 여러 엔터티, 여러 테이블을 업데이트합니다.

트랜잭션을 실행할 때 다른 시스템의 동일한 데이터가 동시에 수정될 수 있습니다. 예를 들어 안티스팸은 사용자가 어떤 식으로든 의심스러워서 사용자의 모든 사진이 더 이상 공개되어서는 안 되며 조정을 위해 사진을 보내야 한다고 판단할 수 있습니다. 이는 photo.status를 다른 값으로 변경하고 해당 카운터를 끄는 것을 의미합니다. 분명히, 이 작업이 다음과 같이 적용의 원자성과 경쟁 수정의 격리를 보장하지 않고 발생하는 경우 ACID, 그러면 결과가 필요하지 않게 됩니다. 사진 카운터에 잘못된 값이 표시되거나 모든 사진이 조정을 위해 전송되지는 않습니다.

하나의 트랜잭션 내에서 다양한 비즈니스 엔터티를 조작하는 유사한 코드가 Odnoklassniki 전체에 걸쳐 작성되었습니다. NoSQL로의 마이그레이션 경험을 바탕으로 최종 일관성 우리는 가장 큰 과제(및 시간 투자)가 데이터 일관성을 유지하기 위한 코드 개발에서 비롯된다는 것을 알고 있습니다. 따라서 우리는 애플리케이션 로직에 대한 실제 ACID 트랜잭션을 제공하기 위한 새 스토리지의 주요 요구 사항을 고려했습니다.

그다지 중요하지 않은 기타 요구 사항은 다음과 같습니다.

• 데이터 센터에 장애가 발생하면 새 스토리지에 대한 읽기 및 쓰기가 모두 가능해야 합니다.
• 현재 개발 속도를 유지합니다. 즉, 새 저장소로 작업할 때 코드의 양은 거의 동일해야 하며, 저장소에 아무것도 추가할 필요가 없고, 충돌 해결을 위한 알고리즘을 개발하고, 보조 인덱스를 유지 관리하는 등의 작업이 없어야 합니다.
• 데이터를 읽을 때와 트랜잭션을 처리할 때 모두 새로운 스토리지의 속도는 상당히 높아야 했습니다. 이는 학문적으로 엄격하고 보편적이지만 느린 솔루션(예: 예를 들어)을 적용할 수 없음을 의미합니다. XNUMX단계 커밋.
• 자동 즉석 확장.
• 이국적인 하드웨어를 구입할 필요 없이 저렴한 일반 서버를 사용합니다.
• 회사 개발자의 스토리지 개발 가능성. 즉, 독점 또는 오픈 소스 솔루션, 가급적이면 Java에 우선순위가 주어졌습니다.

결정, 결정

가능한 솔루션을 분석한 결과 두 가지 가능한 아키텍처 선택이 가능해졌습니다.

첫 번째는 SQL 서버를 가져와 필요한 내결함성, 확장 메커니즘, 장애 조치 클러스터, 충돌 해결 및 분산되고 안정적이며 빠른 ACID 트랜잭션을 구현하는 것입니다. 우리는 이 옵션을 매우 사소하지 않고 노동 집약적이라고 평가했습니다.

두 번째 옵션은 확장, 장애 조치 클러스터, 충돌 해결이 구현된 기성 NoSQL 스토리지를 사용하고 트랜잭션 및 SQL을 직접 구현하는 것입니다. 얼핏 보면 ACID 트랜잭션은 말할 것도 없고 SQL을 구현하는 작업조차 수년이 걸릴 작업처럼 보입니다. 그러나 우리가 실제로 사용하는 SQL 기능 세트는 ANSI SQL과는 거리가 멀다는 것을 깨달았습니다. 카산드라 CQL ANSI SQL과는 거리가 멀다. CQL을 더욱 자세히 살펴보면 우리가 필요로 하는 것과 매우 유사하다는 것을 깨달았습니다.

카산드라와 CQL

그렇다면 Cassandra의 흥미로운 점은 무엇이며 어떤 기능이 있습니까?

첫째, 여기에서는 다양한 데이터 유형을 지원하는 테이블을 생성할 수 있으며, 기본 키에 대해 SELECT 또는 UPDATE를 수행할 수 있습니다.

CREATE TABLE photos (id bigint KEY, owner bigint,…);
SELECT * FROM photos WHERE id=?;
UPDATE photos SET … WHERE id=?;

복제본 데이터 일관성을 보장하기 위해 Cassandra는 다음을 사용합니다. 정족수 접근 방식. 가장 간단한 경우, 이는 동일한 행의 XNUMX개 복제본이 클러스터의 서로 다른 노드에 배치될 때 대다수의 노드(즉, XNUMX개 중 XNUMX개)가 이 쓰기 작업의 성공을 확인한 경우 쓰기가 성공한 것으로 간주됨을 의미합니다. . 읽을 때 대부분의 노드가 폴링되어 확인된 경우 행 데이터는 일관성이 있는 것으로 간주됩니다. 따라서 XNUMX개의 복제본을 사용하면 한 노드에 장애가 발생하더라도 완전하고 즉각적인 데이터 일관성이 보장됩니다. 이 접근 방식을 통해 우리는 훨씬 더 안정적인 체계를 구현할 수 있었습니다. 항상 세 개의 복제본 모두에 요청을 보내고 가장 빠른 두 복제본의 응답을 기다립니다. 이 경우 세 번째 복제본의 지연 응답은 삭제됩니다. 응답이 느린 노드에는 브레이크, JVM의 가비지 수집, Linux 커널의 직접 메모리 회수, 하드웨어 오류, 네트워크 연결 끊김 등 심각한 문제가 발생할 수 있습니다. 그러나 이는 클라이언트의 작업이나 데이터에 어떤 방식으로도 영향을 미치지 않습니다.

XNUMX개의 노드에 접속하고 XNUMX개의 노드로부터 응답을 받는 접근 방식을 호출합니다. 추측: 추가 복제본에 대한 요청은 "떨어지기" 전에도 전송됩니다.

Cassandra의 또 다른 이점은 일괄 변경 사항이 완전히 적용되거나 전혀 적용되지 않도록 보장하는 메커니즘인 Batchlog입니다. 이를 통해 우리는 ACID의 A(원자성)를 즉시 해결할 수 있습니다.

Cassandra에서 트랜잭션에 가장 가까운 것은 소위 "경량 트랜잭션". 그러나 이는 "실제" ACID 거래와는 거리가 멀습니다. 실제로 이것은 다음을 수행할 수 있는 기회입니다. CAS 헤비웨이트 Paxos 프로토콜을 사용한 합의를 사용하여 단 하나의 레코드의 데이터에 대해서만 처리합니다. 따라서 이러한 거래의 속도는 느립니다.

Cassandra에서 우리가 놓친 것

그래서 우리는 Cassandra에서 실제 ACID 트랜잭션을 구현해야 했습니다. 이를 사용하면 기존 DBMS의 다른 두 가지 편리한 기능, 즉 기본 키뿐만 아니라 데이터 선택을 수행할 수 있는 일관되고 빠른 인덱스와 단조로운 자동 증가 ID의 일반 생성기를 쉽게 구현할 수 있습니다.

원뿔

그리하여 새로운 DBMS가 탄생했습니다. 원뿔, 세 가지 유형의 서버 노드로 구성됩니다.

• 스토리지 – 로컬 디스크에 데이터를 저장하는 역할을 하는 (거의) 표준 Cassandra 서버입니다. 데이터의 로드와 양이 증가함에 따라 그 양은 쉽게 수십, 수백으로 확장될 수 있습니다.
• 트랜잭션 코디네이터 - 트랜잭션 실행을 보장합니다.
• 클라이언트는 비즈니스 운영을 구현하고 트랜잭션을 시작하는 애플리케이션 서버입니다. 그러한 클라이언트는 수천 명에 달할 수 있습니다.

모든 유형의 서버는 공통 클러스터의 일부이며 내부 Cassandra 메시지 프로토콜을 사용하여 서로 통신하고 잡담 클러스터 정보 교환을 위해 Heartbeat를 통해 서버는 상호 오류에 대해 학습하고 단일 데이터 스키마(테이블, 구조 및 복제)를 유지 관리합니다. 파티셔닝 방식, 클러스터 토폴로지 등

클라이언트

표준 드라이버 대신 Fat Client 모드가 사용됩니다. 이러한 노드는 데이터를 저장하지 않지만 요청 실행을 위한 조정자 역할을 할 수 있습니다. 즉, 클라이언트 자체가 요청의 조정자 역할을 할 수 있습니다. 즉, 스토리지 복제본을 쿼리하고 충돌을 해결합니다. 이는 원격 조정자와의 통신이 필요한 표준 드라이버보다 더 안정적이고 빠를 뿐만 아니라 요청 전송을 제어할 수도 있습니다. 클라이언트에서 열린 트랜잭션 외부에서는 요청이 리포지토리로 전송됩니다. 클라이언트가 트랜잭션을 열면 트랜잭션 내의 모든 요청이 트랜잭션 조정자에게 전송됩니다.

C*One 거래 코디네이터

코디네이터는 C*One을 위해 처음부터 구현한 것입니다. 트랜잭션, 잠금 및 트랜잭션 적용 순서를 관리하는 역할을 담당합니다.

각 서비스된 트랜잭션에 대해 코디네이터는 타임스탬프를 생성합니다. 각 후속 트랜잭션은 이전 트랜잭션보다 큽니다. Cassandra의 충돌 해결 시스템은 타임스탬프(충돌하는 두 레코드 중 최신 타임스탬프가 있는 레코드가 현재 것으로 간주됨)를 기반으로 하기 때문에 충돌은 항상 후속 트랜잭션을 위해 해결됩니다. 따라서 우리는 구현했습니다. 램포트 시계 - 분산 시스템의 충돌을 해결하는 저렴한 방법입니다.

자물쇠

격리를 보장하기 위해 우리는 레코드의 기본 키를 기반으로 하는 비관적 잠금이라는 가장 간단한 방법을 사용하기로 결정했습니다. 즉, 트랜잭션에서 레코드를 먼저 잠근 다음 읽기, 수정 및 저장해야 합니다. 성공적인 커밋 후에만 레코드의 잠금이 해제되어 경쟁 트랜잭션에서 사용할 수 있습니다.

비분산 환경에서는 이러한 잠금을 구현하는 것이 간단합니다. 분산 시스템에는 두 가지 주요 옵션이 있습니다. 클러스터에 분산 잠금을 구현하거나 동일한 레코드와 관련된 트랜잭션이 항상 동일한 코디네이터에 의해 서비스되도록 트랜잭션을 분산하는 것입니다.

우리의 경우 데이터는 이미 SQL의 로컬 트랜잭션 그룹에 분산되어 있으므로 로컬 트랜잭션 그룹을 코디네이터에게 할당하기로 결정했습니다. 한 코디네이터는 0에서 9까지의 토큰으로 모든 트랜잭션을 수행하고 두 번째 코디네이터는 10에서 19까지의 토큰으로 모든 트랜잭션을 수행합니다. 등등. 결과적으로 각 코디네이터 인스턴스는 트랜잭션 그룹의 마스터가 됩니다.

그런 다음 코디네이터의 메모리에 평범한 HashMap 형태로 잠금을 구현할 수 있습니다.

코디네이터 오류

하나의 코디네이터가 트랜잭션 그룹을 독점적으로 서비스하기 때문에 두 번째 트랜잭션 실행 시도가 시간 초과되도록 실패 사실을 신속하게 확인하는 것이 매우 중요합니다. 이를 빠르고 안정적으로 수행하기 위해 완전히 연결된 쿼럼 하트비트 프로토콜을 사용했습니다.

각 데이터 센터는 최소 XNUMX개의 코디네이터 노드를 호스팅합니다. 주기적으로 각 코디네이터는 다른 코디네이터에게 하트비트 메시지를 보내고 자신의 기능과 마지막으로 클러스터의 어느 코디네이터로부터 어떤 하트비트 메시지를 받았는지 알려줍니다.

하트비트 메시지의 일부로 다른 사람으로부터 유사한 정보를 수신한 각 코디네이터는 쿼럼 원칙에 따라 어떤 클러스터 노드가 작동하고 작동하지 않는지 스스로 결정합니다. 즉, 노드 X가 클러스터의 대다수 노드로부터 정상 상태에 대한 정보를 받은 경우 노드 Y로부터 메시지를 수신하면 Y가 작동합니다. 그 반대의 경우도 마찬가지입니다. 대다수가 노드 Y에서 누락된 메시지를 보고하자마자 Y는 거부했습니다. 쿼럼이 노드 X에 더 이상 메시지를 수신하지 않는다고 알리면 노드 X 자체가 실패한 것으로 간주한다는 점이 궁금합니다.

하트비트 메시지는 20ms 주기로 초당 약 50회 높은 빈도로 전송됩니다. Java에서는 가비지 수집기로 인한 일시 중지 시간이 비슷하기 때문에 50ms 이내에 애플리케이션 응답을 보장하기 어렵습니다. 우리는 GC 일시 중지 기간에 대한 목표를 지정할 수 있는 G1 가비지 수집기를 사용하여 이 응답 시간을 달성할 수 있었습니다. 그러나 매우 드물게 수집기 일시 중지가 50ms를 초과하는 경우도 있으며, 이로 인해 잘못된 오류 감지가 발생할 수 있습니다. 이를 방지하기 위해 코디네이터는 원격 노드의 첫 번째 하트비트 메시지가 사라질 때 여러 개가 연속으로 사라진 경우에만 원격 노드의 실패를 보고하지 않습니다. 이것이 우리가 200에서 코디네이터 노드의 실패를 감지할 수 있었던 방법입니다. ms.

하지만 어떤 노드가 작동을 멈췄는지 빠르게 이해하는 것만으로는 충분하지 않습니다. 이에 대해 뭔가 조치를 취해야 합니다.

페이지

고전적인 계획에는 마스터 오류가 발생한 경우 다음 중 하나를 사용하여 새 선택을 시작하는 것이 포함됩니다. 유행의 만능인 알고리즘. 그러나 이러한 알고리즘에는 시간 수렴 및 선거 프로세스 자체의 길이와 관련하여 잘 알려진 문제가 있습니다. 우리는 완전히 연결된 네트워크에서 코디네이터 교체 방식을 사용하여 이러한 추가 지연을 피할 수 있었습니다.

그룹 50에서 트랜잭션을 실행한다고 해보자. 교체 방식, 즉 메인 코디네이터에 장애가 발생할 경우 어느 노드가 그룹 50에서 트랜잭션을 실행할지 미리 결정해보자. 우리의 목표는 데이터 센터에 장애가 발생하더라도 시스템 기능을 유지하는 것입니다. 첫 번째 예약은 다른 데이터 센터의 노드가 되고 두 번째 예약은 세 번째 노드가 될 것이라고 결정해 보겠습니다. 이 구성표는 한 번 선택되면 클러스터의 토폴로지가 변경될 때까지, 즉 새 노드가 포함될 때까지 변경되지 않습니다(매우 드물게 발생함). 이전 마스터가 실패하는 경우 새 활성 마스터를 선택하는 절차는 항상 다음과 같습니다. 첫 번째 예비가 활성 마스터가 되고, 작동이 중지되면 두 번째 예비가 활성 마스터가 됩니다.

이 체계는 새 마스터를 활성화하려면 이전 마스터의 오류를 확인하는 것으로 충분하므로 범용 알고리즘보다 더 안정적입니다.

그러나 고객은 현재 어떤 마스터가 작업 중인지 어떻게 알 수 있습니까? 50ms 안에 수천 명의 클라이언트에게 정보를 보내는 것은 불가능합니다. 클라이언트가 트랜잭션 열기 요청을 보내는 경우 이 마스터가 더 이상 작동하지 않는다는 사실을 아직 모르고 요청이 시간 초과되는 상황이 발생할 수 있습니다. 이러한 일이 발생하는 것을 방지하기 위해 고객은 그룹 마스터와 그의 보유금 모두에 동시에 트랜잭션을 개설하라는 요청을 추측적으로 보내지만 현재 활성 마스터인 사람만이 이 요청에 응답합니다. 클라이언트는 트랜잭션 내에서 활성 마스터와의 모든 후속 통신을 수행합니다.

백업 마스터는 자신의 것이 아닌 트랜잭션에 대해 수신된 요청을 아직 생성되지 않은 트랜잭션의 대기열에 배치하고 해당 요청은 한동안 저장됩니다. 활성 마스터가 종료되면 새 마스터는 대기열에서 트랜잭션 열기 요청을 처리하고 클라이언트에 응답합니다. 클라이언트가 이미 이전 마스터와의 트랜잭션을 연 경우 두 번째 응답은 무시됩니다(물론 이러한 트랜잭션은 완료되지 않고 클라이언트에 의해 반복됩니다).

거래 방식

클라이언트가 기본 키를 사용하여 해당 엔터티에 대한 트랜잭션을 열도록 코디네이터에게 요청을 보냈다고 가정해 보겠습니다. 코디네이터는 이 엔터티를 잠그고 메모리의 잠금 테이블에 배치합니다. 필요한 경우 코디네이터는 저장소에서 이 엔터티를 읽고 결과 데이터를 코디네이터 메모리의 트랜잭션 상태로 저장합니다.

클라이언트가 트랜잭션의 데이터를 변경하려고 하면 코디네이터에게 엔터티 수정 요청을 보내고, 코디네이터는 새 데이터를 메모리의 트랜잭션 상태 테이블에 배치합니다. 이것으로 녹음이 완료됩니다. 저장소에 녹음이 이루어지지 않습니다.

클라이언트가 활성 트랜잭션의 일부로 변경된 자체 데이터를 요청하면 코디네이터는 다음과 같이 작동합니다.

• ID가 이미 트랜잭션에 있는 경우 데이터는 메모리에서 가져옵니다.
• 메모리에 ID가 없으면 스토리지 노드에서 누락된 데이터를 읽어 이미 메모리에 있는 데이터와 결합한 다음 결과를 클라이언트에 제공합니다.

따라서 클라이언트는 자신의 변경 사항을 읽을 수 있지만 다른 클라이언트는 이러한 변경 사항을 볼 수 없습니다. 변경 사항은 코디네이터의 메모리에만 저장되고 아직 Cassandra 노드에는 없기 때문입니다.

클라이언트가 커밋을 보내면 서비스 메모리에 있던 상태가 코디네이터에 의해 기록된 배치로 저장되고 기록된 배치로 Cassandra 저장소에 전송됩니다. 저장소는 이 패키지가 원자적으로(완전히) 적용되도록 하기 위해 필요한 모든 작업을 수행하고 코디네이터에게 응답을 반환합니다. 코디네이터는 잠금을 해제하고 클라이언트에 대한 트랜잭션 성공을 확인합니다.

그리고 롤백하려면 코디네이터는 트랜잭션 상태가 차지하는 메모리만 해제하면 됩니다.

위의 개선 결과로 우리는 ACID 원칙을 구현했습니다.

• 원자성. 이는 트랜잭션이 시스템에 부분적으로 기록되지 않고 모든 하위 작업이 완료되거나 아무것도 완료되지 않음을 보장합니다. 우리는 Cassandra의 로그된 배치를 통해 이 원칙을 고수합니다.
• 일관성. 각각의 성공적인 트랜잭션은 정의에 따라 유효한 결과만 기록합니다. 트랜잭션을 열고 일부 작업을 수행한 후 결과가 유효하지 않은 것으로 확인되면 롤백이 수행됩니다.
• 격리. 트랜잭션이 실행될 때 동시 트랜잭션이 결과에 영향을 주어서는 안 됩니다. 경쟁하는 트랜잭션은 코디네이터의 비관적 잠금을 사용하여 격리됩니다. 트랜잭션 외부 읽기의 경우 읽기 커밋 수준에서 격리 원칙이 준수됩니다.
• 안정. 시스템 정전, 하드웨어 오류 등 하위 수준의 문제에 관계없이 성공적으로 완료된 트랜잭션으로 인한 변경 사항은 작업이 재개될 때 유지되어야 합니다.

인덱스로 읽기

간단한 표를 살펴보겠습니다.

CREATE TABLE photos (
id bigint primary key,
owner bigint,
modified timestamp,
…)

ID(기본 키), 소유자 및 수정 날짜가 있습니다. 매우 간단한 요청을 해야 합니다. 변경 날짜가 "마지막 날"인 소유자의 데이터를 선택하세요.

SELECT *
WHERE owner=?
AND modified>?

이러한 쿼리를 빠르게 처리하려면 기존 SQL DBMS에서는 열(소유자, 수정)별로 인덱스를 구축해야 합니다. 이제 ACID 보장이 있으므로 이 작업을 매우 쉽게 수행할 수 있습니다!

C*One의 인덱스

레코드 ID가 기본 키인 사진이 포함된 소스 테이블이 있습니다.

인덱스의 경우 C*One은 원본의 복사본인 새 테이블을 생성합니다. 키는 인덱스 표현식과 동일하며 소스 테이블 레코드의 기본 키도 포함합니다.

이제 "마지막 날 소유자"에 대한 쿼리를 다른 테이블에서 선택하여 다시 작성할 수 있습니다.

SELECT * FROM i1_test
WHERE owner=?
AND modified>?

원본 테이블 사진과 인덱스 테이블 i1의 데이터 일관성은 코디네이터에 의해 자동으로 유지됩니다. 데이터 스키마만으로 변경 사항이 수신되면 코디네이터는 메인 테이블뿐만 아니라 복사본에도 변경 사항을 생성하여 저장합니다. 인덱스 테이블에 대해서는 추가 작업이 수행되지 않고, 로그가 읽히지 않으며, 잠금이 사용되지 않습니다. 즉, 인덱스를 추가하면 리소스가 거의 소모되지 않으며 수정 사항 적용 속도에 거의 영향을 미치지 않습니다.

ACID를 사용하여 SQL과 유사한 인덱스를 구현할 수 있었습니다. 일관되고 확장 가능하며 빠르고 구성 가능하며 CQL 쿼리 언어에 내장되어 있습니다. 인덱스를 지원하기 위해 애플리케이션 코드를 변경할 필요가 없습니다. 모든 것이 SQL만큼 간단합니다. 그리고 가장 중요한 점은 인덱스가 원본 트랜잭션 테이블 수정 실행 속도에 영향을 미치지 않는다는 것입니다.

어떻게 된 거예요

우리는 XNUMX년 전에 C*One을 개발하여 상용화에 착수했습니다.

결국 우리는 무엇을 얻었습니까? 소셜 네트워크에서 가장 중요한 데이터 유형 중 하나인 사진 처리 및 저장 하위 시스템의 예를 사용하여 이를 평가해 보겠습니다. 우리는 사진 자체에 대해 이야기하는 것이 아니라 모든 종류의 메타 정보에 대해 이야기하고 있습니다. 이제 Odnoklassniki에는 약 20억 개의 기록이 있으며, 시스템은 초당 80만 건의 읽기 요청, 데이터 수정과 관련된 초당 최대 8건의 ACID 트랜잭션을 처리합니다.

복제 인자 = 1(그러나 RAID 10)로 SQL을 사용했을 때 사진 메타 정보는 Microsoft SQL Server(32개 백업 포함)를 실행하는 11개 시스템의 고가용성 클러스터에 저장되었습니다. 백업 저장을 위해 10개의 서버도 할당되었습니다. 총 50대의 고가 자동차. 동시에 시스템은 예비 없이 정격 부하에서 작동했습니다.

새 시스템으로 마이그레이션한 후 복제 인자 = 3(각 데이터 센터의 복사본)을 받았습니다. 시스템은 63개의 Cassandra 스토리지 노드와 6개의 코디네이터 머신, 총 69개의 서버로 구성됩니다. 그러나 이러한 시스템은 훨씬 저렴하며 총 비용은 SQL 시스템 비용의 약 30%입니다. 동시에 부하는 30%로 유지됩니다.

C*One의 도입으로 대기 시간도 감소했습니다. SQL에서는 쓰기 작업에 약 4,5ms가 걸렸습니다. C*One에서 - 약 1,6ms. 트랜잭션 기간은 평균 40ms 미만이고 커밋은 2ms 안에 완료되며 읽기 및 쓰기 기간은 평균 2ms입니다. 99번째 백분위수 - 단 3~3,1ms에 불과하며 시간 초과 횟수가 100배 감소했습니다. 이는 모두 추측이 널리 사용되었기 때문입니다.

현재 대부분의 SQL Server 노드는 폐기되었으며 C*One만을 사용하여 새로운 제품이 개발되고 있습니다. 클라우드에서 작동하도록 C*One을 조정했습니다. 단일 클라우드이를 통해 새로운 클러스터의 배포 속도를 높이고 구성을 단순화하며 운영을 자동화할 수 있었습니다. 소스 코드가 없으면 이를 수행하는 것이 훨씬 더 어렵고 번거롭습니다.

이제 우리는 다른 스토리지 시설을 클라우드로 이전하는 작업을 진행하고 있지만 이는 완전히 다른 이야기입니다.

출처 : habr.com