더 많은 개발자가 데이터베이스에 대해 이 사실을 알아야 합니다.

메모. 번역: Jaana Dogan은 Google의 숙련된 엔지니어로 현재 Go로 작성된 회사 프로덕션 서비스의 관찰 가능성을 연구하고 있습니다. 영어권 청중들 사이에서 큰 인기를 얻은 이 기사에서 그녀는 대규모/요구적인 애플리케이션 개발자가 고려하는 데 유용한 DBMS(때로는 일반적으로 분산 시스템)에 관한 중요한 기술 세부 사항을 17가지 항목으로 수집했습니다.

대다수의 컴퓨터 시스템은 상태를 추적하므로 일종의 데이터 저장 시스템이 필요합니다. 저는 오랜 시간 동안 데이터베이스에 대한 지식을 축적했으며, 설계 실수로 인해 데이터 손실과 중단이 발생했습니다. 대용량 정보를 처리하는 시스템에서 데이터베이스는 시스템 아키텍처의 중심에 있으며 최적의 솔루션을 선택하는 핵심 요소로 작용합니다. 데이터베이스 작업에 세심한 주의를 기울인다는 사실에도 불구하고 애플리케이션 개발자가 예상하려고 하는 문제는 종종 빙산의 일각에 불과합니다. 이 기사 시리즈에서는 이 분야의 전문 지식이 없는 개발자에게 유용한 몇 가지 아이디어를 공유합니다.

1. 99,999%의 시간 동안 네트워크가 문제를 일으키지 않는다면 운이 좋습니다.
2. ACID는 다양한 의미를 갖습니다.
3. 각 데이터베이스에는 일관성과 격리를 보장하기 위한 자체 메커니즘이 있습니다.
4. 일반적인 차단을 유지하기 어려울 때 낙관적 차단이 도움이 됩니다.
5. 더티 읽기(Dirty Read) 및 데이터 손실 외에도 다른 예외 사항이 있습니다.
6. 데이터베이스와 사용자가 행동 과정에 항상 동의하는 것은 아닙니다.
7. 애플리케이션 수준 샤딩은 애플리케이션 외부로 이동할 수 있습니다.
8. 자동 증가는 위험할 수 있습니다.
9. 오래된 데이터는 유용할 수 있으며 잠글 필요가 없습니다.
10. 왜곡은 모든 시간 소스에서 일반적입니다.
11. 지연에는 많은 의미가 있습니다.
12. 특정 트랜잭션에 대한 성능 요구 사항을 평가해야 합니다.
13. 중첩된 트랜잭션은 위험할 수 있습니다.
14. 트랜잭션은 애플리케이션 상태에 연결되어서는 안 됩니다.
15. 쿼리 플래너는 데이터베이스에 대해 많은 것을 알려줄 수 있습니다.
16. 온라인 마이그레이션은 어렵지만 가능합니다.
17. 데이터베이스가 크게 증가하면 예측 불가능성이 증가합니다.

이 기사의 이전 버전에 대한 피드백을 주신 Emmanuel Odeke, Rein Henrichs 및 기타 분들께 감사의 말씀을 전하고 싶습니다.

99,999%의 시간 동안 네트워크가 문제를 일으키지 않는다면 운이 좋습니다.

현대 네트워크 기술이 얼마나 신뢰할 수 있는지, 그리고 네트워크 오류로 인해 시스템이 얼마나 자주 다운되는지에 대한 의문이 남아 있습니다. 이 문제에 대한 정보는 부족하며 전문 네트워크, 장비 및 인력을 갖춘 대규모 조직이 연구를 주도하는 경우가 많습니다.

Spanner(Google의 전 세계적으로 분산된 데이터베이스)의 가용성 비율이 99,999%로 Google은 다음과 같이 주장합니다. 7,6% 문제는 네트워크와 관련이 있습니다. 동시에 회사는 전문 네트워크를 고가용성의 "주요 기둥"이라고 부릅니다. 공부하다 베일리스와 킹스버리, 2014년에 실시된 '분산 컴퓨팅에 대한 오해"는 Peter Deutsch가 1994년에 공식화한 것입니다. 네트워크가 정말 안정적인가요?

더 넓은 인터넷을 대상으로 거대 기업 외부에서 수행되는 포괄적인 연구는 존재하지 않습니다. 또한 고객 문제의 몇 퍼센트가 네트워크와 관련되어 있는지에 대한 주요 업체의 데이터가 충분하지 않습니다. 우리는 대규모 클라우드 제공업체의 네트워크 스택 중단으로 인해 인터넷 전체가 몇 시간 동안 중단될 수 있다는 사실을 잘 알고 있습니다. 이는 단순히 많은 사람과 회사에 영향을 미치는 중대한 사건이기 때문입니다. 네트워크 중단은 모든 사례가 주목을 받는 것은 아니더라도 더 많은 경우에 문제를 일으킬 수 있습니다. 클라우드 서비스 클라이언트도 문제의 원인에 대해 아무것도 모릅니다. 장애가 발생한 경우 서비스 제공자 측에서는 이를 네트워크 오류로 간주하는 것이 거의 불가능합니다. 이들에게 타사 서비스는 블랙박스입니다. 대규모 서비스 제공자가 아니면서 그 영향을 평가하는 것은 불가능합니다.

대형 업체들이 자사 시스템에 대해 보고한 내용을 고려하면 네트워크 문제가 잠재적 가동 중지 시간 문제의 극히 일부만을 설명한다면 운이 좋다고 말할 수 있습니다. 네트워크 통신은 여전히 ​​하드웨어 오류, 토폴로지 변경, 관리 구성 변경, 정전 등 일상적인 문제로 인해 어려움을 겪고 있습니다. 최근에 발생할 수 있는 문제 목록이 추가된 것을 알고 놀랐습니다. 상어에 물린 (예, 당신이 옳게 들었습니다).

ACID는 다양한 의미를 가지고 있습니다.

ACID라는 약어는 원자성(Atomicity), 일관성(Consistency), 격리성(Isolation), 신뢰성(Reliability)을 의미합니다. 이러한 트랜잭션 속성은 장애, 오류, 하드웨어 오류 등이 발생한 경우 유효성을 보장하기 위한 것입니다. ACID 또는 유사한 체계가 없으면 애플리케이션 개발자가 자신이 담당하는 것과 데이터베이스가 담당하는 것을 구별하기 어려울 것입니다. 대부분의 관계형 트랜잭션 데이터베이스는 ACID를 준수하려고 노력하지만 NoSQL과 같은 새로운 접근 방식은 구현 비용이 많이 들기 때문에 ACID 트랜잭션이 없는 많은 데이터베이스를 탄생시켰습니다.

제가 업계에 처음 입문했을 때 기술 책임자는 ACID 개념이 얼마나 관련성이 있는지에 대해 이야기했습니다. 공평하게 말하면 ACID는 엄격한 구현 표준이 아니라 대략적인 설명으로 간주됩니다. 오늘날 나는 그것이 특정 범주의 문제를 제기하고 다양한 가능한 해결책을 제안하기 때문에 가장 유용하다고 생각합니다.

모든 DBMS가 ACID를 준수하는 것은 아닙니다. 동시에 ACID를 지원하는 데이터베이스 구현은 요구 사항 집합을 다르게 이해합니다. ACID 구현이 고르지 못한 이유 중 하나는 ACID 요구 사항을 구현하기 위해 이루어져야 하는 많은 절충안 때문입니다. 제작자는 자신의 데이터베이스를 ACID 규격으로 제시할 수 있지만 "가능성이 없는" 이벤트를 처리하는 메커니즘과 마찬가지로 극단적인 경우의 해석도 크게 다를 수 있습니다. 최소한 개발자는 기본 구현의 복잡성을 높은 수준으로 이해하여 특수한 동작과 설계 장단점을 적절하게 이해할 수 있습니다.

MongoDB가 ACID 요구 사항을 준수하는지 여부에 대한 논쟁은 버전 4 출시 이후에도 계속됩니다. MongoDB는 오랫동안 지원되지 않았습니다 벌채 반출그러나 기본적으로 데이터는 60초마다 한 번만 디스크에 커밋됩니다. 다음 시나리오를 상상해 보십시오. 애플리케이션이 두 번의 쓰기(w1 및 w2)를 게시합니다. MongoDB는 w1을 성공적으로 저장했지만 하드웨어 오류로 인해 w2가 손실되었습니다.

시나리오를 보여주는 다이어그램. MongoDB가 디스크에 데이터를 쓰기 전에 충돌이 발생함

디스크에 커밋하는 것은 비용이 많이 드는 프로세스입니다. 빈번한 커밋을 피함으로써 개발자는 안정성을 희생하면서 녹음 성능을 향상시킵니다. MongoDB는 현재 로깅을 지원하지만 로그는 기본적으로 100ms마다 캡처되므로 더티 쓰기는 여전히 데이터 무결성에 영향을 미칠 수 있습니다. 즉, 위험은 훨씬 낮지만 로그와 그에 표시된 변경 사항에 대해 유사한 시나리오가 여전히 가능합니다.

각 데이터베이스에는 고유한 일관성 및 격리 메커니즘이 있습니다.

ACID 요구 사항 중 일관성과 격리는 절충 범위가 더 넓기 때문에 가장 많은 수의 구현을 자랑합니다. 일관성과 격리는 상당히 비용이 많이 드는 기능이라고 할 수 있습니다. 데이터 일관성을 위해 조정이 필요하고 경쟁이 심화됩니다. 여러 데이터 센터에 걸쳐 데이터베이스를 수평적으로 확장해야 하는 경우(특히 서로 다른 지리적 지역에 위치한 경우) 문제의 복잡성이 크게 증가합니다. 높은 수준의 일관성을 달성하는 것은 가용성을 감소시키고 네트워크 분할을 증가시키기 때문에 매우 어렵습니다. 이 현상에 대한 보다 일반적인 설명을 보려면 다음을 참조하는 것이 좋습니다. CAP 정리. 또한 응용 프로그램은 약간의 불일치를 처리할 수 있으며 프로그래머는 문제를 처리하기 위해 데이터베이스에 크게 의존하지 않고도 응용 프로그램에 추가 논리를 구현하여 불일치를 처리할 수 있을 만큼 문제의 미묘한 차이를 이해할 수 있다는 점도 주목할 가치가 있습니다.

DBMS는 종종 다양한 수준의 격리를 제공합니다. 애플리케이션 개발자는 자신의 선호도에 따라 가장 효과적인 것을 선택할 수 있습니다. 격리 수준이 낮으면 속도가 빨라지지만 데이터 경합의 위험도 높아집니다. 절연성이 높으면 이러한 확률이 줄어들지만 작업 속도가 느려지고 경쟁이 발생할 수 있으며, 이로 인해 베이스에 브레이크가 발생하여 고장이 시작될 수 있습니다.

기존 동시성 모델 및 이들 간의 관계 검토

SQL 표준은 XNUMX가지 격리 수준만 정의하지만 이론적으로나 실제적으로는 더 많은 격리 수준이 있습니다. Jepson.io 기존 동시성 모델에 대한 훌륭한 개요를 제공합니다. 예를 들어 Google Spanner는 클록 동기화를 통해 외부 직렬성을 보장하며 이는 더 엄격한 격리 계층이지만 표준 격리 계층에서는 정의되지 않습니다.

SQL 표준에서는 다음과 같은 격리 수준을 언급합니다.

• 직렬화 가능 (가장 엄격하고 비용이 많이 듭니다): 직렬화 가능 실행은 일부 순차 트랜잭션 실행과 동일한 효과를 갖습니다. 순차적 실행은 각 후속 트랜잭션이 이전 트랜잭션이 완료된 후에만 시작됨을 의미합니다. 수준이라는 점에 유의해야 한다. 직렬화 가능 스냅샷 격리 자체는 SQL 표준에 표시되지 않지만 해석의 차이로 인해 소위 스냅샷 격리(예: Oracle)로 구현되는 경우가 많습니다.
• 반복 가능한 읽기: 현재 트랜잭션의 커밋되지 않은 레코드는 현재 트랜잭션에서 사용할 수 있지만 다른 트랜잭션(예: 새 행)에 의해 변경된 내용은 보이지 않는.
• 커밋된 읽기: 커밋되지 않은 데이터는 트랜잭션에 사용할 수 없습니다. 이 경우 트랜잭션은 커밋된 데이터만 볼 수 있으며 가상 읽기가 발생할 수 있습니다. 트랜잭션이 새 행을 삽입하고 커밋하는 경우 현재 트랜잭션은 쿼리 시 해당 행을 볼 수 있습니다.
• 커밋되지 않은 읽기 (가장 덜 엄격하고 비용이 많이 드는 수준): 더티 읽기가 허용되며, 트랜잭션은 다른 트랜잭션에서 커밋되지 않은 변경 사항을 볼 수 있습니다. 실제로 이 수준은 쿼리와 같은 대략적인 추정에 유용할 수 있습니다. COUNT(*) 책상 위에.

수평 직렬화 가능 데이터 경합의 위험을 최소화하는 동시에 구현 비용이 가장 많이 들고 시스템에서 가장 높은 경쟁 부하를 초래합니다. 다른 격리 수준은 구현하기 쉽지만 데이터 경합 가능성이 높아집니다. 일부 DBMS에서는 사용자 정의 격리 수준을 설정할 수 있지만 다른 DBMS에서는 강력한 선호도를 갖고 있으며 모든 수준이 지원되는 것은 아닙니다.

격리 수준에 대한 지원은 종종 특정 DBMS에서 광고되지만 해당 동작을 주의 깊게 연구해야만 실제로 무슨 일이 일어나고 있는지 알 수 있습니다.

다양한 DBMS에 대한 다양한 격리 수준의 동시성 이상 검토

그의 프로젝트에서 마틴 클레프만 암자 다양한 격리 수준을 비교하고, 동시성 이상에 대해 설명하고, 데이터베이스가 특정 격리 수준을 준수할 수 있는지 여부를 설명합니다. Kleppmann의 연구는 데이터베이스 개발자가 격리 수준에 대해 얼마나 다르게 생각하는지 보여줍니다.

일반적인 차단을 유지하기 어려울 때 낙관적 차단이 도움이 됩니다.

차단은 데이터베이스 경쟁을 증가시킬 뿐만 아니라 애플리케이션 서버가 지속적으로 데이터베이스에 연결해야 하기 때문에 비용이 매우 많이 들 수 있습니다. 네트워크 분할은 배타적 잠금 상황을 악화시키고 식별 및 해결이 어려운 교착 상태를 초래할 수 있습니다. 배타적 잠금이 적합하지 않은 경우 낙관적 잠금이 도움이 됩니다.

낙관적 잠금 문자열을 읽을 때 버전, 체크섬 또는 마지막 수정 시간을 고려하는 방법입니다. 이를 통해 항목을 변경하기 전에 원자 버전 변경이 없는지 확인할 수 있습니다.

UPDATE products
SET name = 'Telegraph receiver', version = 2
WHERE id = 1 AND version = 1

이 경우 테이블을 업데이트합니다. products 다른 작업이 이전에 이 행을 변경한 경우에는 수행되지 않습니다. 이 행에 대해 다른 작업이 수행되지 않은 경우 한 행에 대한 변경이 발생하며 업데이트가 성공했다고 말할 수 있습니다.

더티 읽기(Dirty Read) 및 데이터 손실 외에 다른 예외 사항이 있습니다.

데이터 일관성과 관련하여 더티 읽기 및 데이터 손실로 이어질 수 있는 경쟁 조건의 가능성에 중점을 둡니다. 그러나 데이터 이상 현상은 여기서 끝나지 않습니다.

이러한 이상 현상의 한 가지 예는 왜곡을 기록하는 것입니다. (비틀어 쓰기). 왜곡은 일반적으로 적극적으로 검색되지 않기 때문에 감지하기 어렵습니다. 더티 읽기나 데이터 손실로 인한 것이 아니라 데이터에 대한 논리적 제약 조건 위반으로 인해 발생합니다.

예를 들어, 한 명의 운영자가 항상 통화 중이어야 하는 모니터링 애플리케이션을 고려해 보겠습니다.

BEGIN tx1;                      BEGIN tx2;
SELECT COUNT(*)
FROM operators
WHERE oncall = true;
0                               SELECT COUNT(*)
                                FROM operators
                                WHERE oncall = TRUE;
                                0
UPDATE operators                UPDATE operators
SET oncall = TRUE               SET oncall = TRUE
WHERE userId = 4;               WHERE userId = 2;
COMMIT tx1;                     COMMIT tx2;

위 상황에서 두 트랜잭션이 모두 성공적으로 커밋되면 레코드 손상이 발생합니다. 더티 읽기나 데이터 손실은 없었지만 데이터 무결성이 손상되었습니다. 이제 두 사람이 동시에 통화 중인 것으로 간주됩니다.

직렬화 가능 격리, 스키마 디자인 또는 데이터베이스 제약 조건은 쓰기 손상을 제거하는 데 도움이 될 수 있습니다. 개발자는 프로덕션 환경에서 이러한 이상 현상을 방지하기 위해 개발 중에 이러한 이상 현상을 식별할 수 있어야 합니다. 동시에 녹음 왜곡은 코드 베이스에서 찾기가 매우 어렵습니다. 특히 대규모 시스템에서 서로 다른 개발 팀이 동일한 테이블을 기반으로 기능 구현을 담당하고 데이터 액세스의 세부 사항에 동의하지 않는 경우.

데이터베이스와 사용자가 무엇을 해야 할지에 대해 항상 동의하는 것은 아닙니다.

데이터베이스의 주요 기능 중 하나는 실행 순서를 보장하는 것이지만 이 순서 자체는 소프트웨어 개발자에게 투명하지 않을 수 있습니다. 데이터베이스는 프로그래머가 의도한 순서가 아닌 수신된 순서대로 트랜잭션을 실행합니다. 특히 부하가 높은 병렬 시스템에서는 트랜잭션 순서를 예측하기 어렵습니다.

개발 중에, 특히 비차단 라이브러리로 작업할 때 잘못된 스타일과 낮은 가독성으로 인해 사용자는 트랜잭션이 순차적으로 실행된다고 믿게 될 수 있습니다. 실제로 트랜잭션은 어떤 순서로든 데이터베이스에 도착할 수 있습니다.

얼핏 보면 아래 프로그램에서는 T1과 T2가 순차적으로 호출되는데, 이 함수들이 논블로킹이라면 즉시 결과를 다음과 같은 형식으로 반환한다. 약속, 호출 순서는 데이터베이스에 들어간 순간에 따라 결정됩니다.

result1 = T1() // 실제 결과는 약속입니다.
결과2 = T2()

원자성이 필요하고(즉, 모든 작업을 완료하거나 중단해야 함) 순서가 중요한 경우 작업 T1 및 T2는 단일 트랜잭션 내에서 수행되어야 합니다.

애플리케이션 수준 샤딩은 애플리케이션 외부로 이동할 수 있습니다.

샤딩은 데이터베이스를 수평으로 분할하는 방법입니다. 일부 데이터베이스는 자동으로 데이터를 수평으로 분할할 수 있는 반면 다른 데이터베이스는 분할할 수 없거나 그다지 능숙하지 않습니다. 데이터 설계자/개발자가 데이터에 액세스하는 방법을 정확하게 예측할 수 있으면 이 작업을 데이터베이스에 위임하는 대신 사용자 공간에 수평 파티션을 만들 수 있습니다. 이 프로세스를 "애플리케이션 수준 샤딩"이라고 합니다. (애플리케이션 수준 샤딩).

불행하게도 이 이름은 종종 샤딩이 애플리케이션 서비스에 존재한다는 오해를 불러일으킵니다. 실제로 데이터베이스 앞에 별도의 레이어로 구현될 수도 있습니다. 데이터 증가 및 스키마 반복에 따라 샤딩 요구 사항이 상당히 복잡해질 수 있습니다. 일부 전략에서는 애플리케이션 서버를 재배포하지 않고도 반복하는 기능을 통해 이점을 얻을 수 있습니다.

샤딩 서비스와 애플리케이션 서버가 분리된 아키텍처의 예

샤딩을 별도의 서비스로 이동하면 애플리케이션을 재배포할 필요 없이 다양한 샤딩 전략을 사용할 수 있는 기능이 확장됩니다. 비테스 애플리케이션 수준의 샤딩 시스템의 예입니다. Vitess는 MySQL에 수평 샤딩을 제공하고 클라이언트가 MySQL 프로토콜을 통해 이에 연결할 수 있도록 합니다. 시스템은 데이터를 서로에 대해 전혀 모르는 여러 MySQL 노드로 분할합니다.

자동 증가는 위험할 수 있습니다.

AUTOINCREMENT는 기본 키를 생성하는 일반적인 방법입니다. 데이터베이스가 ID 생성기로 사용되고 데이터베이스에 식별자를 생성하도록 설계된 테이블이 포함되어 있는 경우가 종종 있습니다. 자동 증가를 사용하여 기본 키를 생성하는 것이 이상적이지 않은 데에는 몇 가지 이유가 있습니다.

• 분산 데이터베이스에서 자동 증가는 심각한 문제입니다. ID를 생성하려면 전역 잠금이 필요합니다. 대신 UUID를 생성할 수 있습니다. 이는 서로 다른 데이터베이스 노드 간의 상호 작용이 필요하지 않습니다. 잠금을 사용한 자동 증가는 경합을 야기하고 분산 상황에서 삽입 성능을 크게 저하시킬 수 있습니다. 일부 DBMS(예: MySQL)는 마스터-마스터 복제를 적절하게 구성하기 위해 특별한 구성과 더 세심한 주의가 필요할 수 있습니다. 그리고 구성 시 실수를 저지르기 쉽고 이로 인해 녹음이 실패하게 됩니다.
• 일부 데이터베이스에는 기본 키를 기반으로 하는 분할 알고리즘이 있습니다. 연속 ID로 인해 예측할 수 없는 핫스팟이 발생하고 일부 파티션에서는 로드가 증가하는 반면 다른 파티션은 유휴 상태로 유지될 수 있습니다.
• 기본 키는 데이터베이스의 행에 액세스하는 가장 빠른 방법입니다. 레코드를 식별하는 더 나은 방법을 통해 순차 ID는 테이블에서 가장 중요한 열을 의미 없는 값으로 채워진 쓸모 없는 열로 바꿀 수 있습니다. 따라서 가능하다면 전역적으로 고유하고 자연스러운 기본 키(예: 사용자 이름)를 선택하십시오.

접근 방식을 결정하기 전에 자동 증가 ID 및 UUID가 인덱싱, 파티셔닝 및 샤딩에 미치는 영향을 고려하세요.

오래된 데이터는 유용할 수 있으며 잠금이 필요하지 않습니다.

MVCC(다중 버전 동시성 제어)는 위에서 간략하게 설명한 많은 일관성 요구 사항을 구현합니다. 일부 데이터베이스(예: Postgres, Spanner)는 MVCC를 사용하여 트랜잭션에 스냅샷(이전 버전의 데이터베이스)을 "공급"합니다. 일관성을 보장하기 위해 스냅샷 트랜잭션을 직렬화할 수도 있습니다. 이전 스냅샷에서 읽을 때 오래된 데이터를 읽습니다.

예를 들어 데이터에서 분석을 생성하거나 대략적인 집계 값을 계산할 때 약간 오래된 데이터를 읽는 것이 유용할 수 있습니다.

레거시 데이터 작업의 첫 번째 이점은 대기 시간이 짧다는 것입니다(특히 데이터베이스가 여러 지역에 분산되어 있는 경우). 두 번째는 읽기 전용 트랜잭션에는 잠금이 없다는 것입니다. 이는 오래된 데이터를 처리할 수 있는 한 많이 읽는 애플리케이션에 중요한 이점입니다.

애플리케이션 서버는 태평양 반대편에 최신 버전이 있어도 5초 전의 로컬 복제본에서 데이터를 읽습니다.

DBMS는 이전 버전을 자동으로 제거하며 경우에 따라 요청 시 이를 수행할 수 있습니다. 예를 들어 Postgres를 사용하면 사용자는 다음을 수행할 수 있습니다. VACUUM 요청 시 자동으로 이 작업을 주기적으로 수행합니다. Spanner는 가비지 수집기를 실행하여 XNUMX시간보다 오래된 스냅샷을 제거합니다.

모든 시간 소스는 왜곡될 수 있습니다.

컴퓨터 과학에서 가장 잘 지켜지는 비밀은 모든 타이밍 API가 거짓말을 한다는 것입니다. 사실 우리 기계는 정확한 현재 시간을 알지 못합니다. 컴퓨터에는 시간을 유지하는 데 사용되는 진동을 생성하는 석영 크리스털이 포함되어 있습니다. 그러나 이는 충분히 정확하지 않으며 정확한 시간보다 앞서거나 뒤처질 수 있습니다. 교대는 하루에 20초에 달할 수 있습니다. 따라서 컴퓨터의 시간은 주기적으로 네트워크 시간과 동기화되어야 합니다.

NTP 서버는 동기화에 사용되지만 동기화 프로세스 자체에는 네트워크 지연이 발생할 수 있습니다. 동일한 데이터 센터에 있는 NTP 서버와 동기화하는 경우에도 시간이 걸립니다. 공용 NTP 서버로 작업하면 훨씬 더 큰 왜곡이 발생할 수 있다는 것은 분명합니다.

원자시계와 GPS 시계는 현재 시간을 확인하는 데 더 적합하지만 비용이 많이 들고 복잡한 설정이 필요하므로 모든 자동차에 설치할 수는 없습니다. 이 때문에 데이터 센터에서는 계층형 접근 방식을 사용합니다. 원자 및/또는 GPS 시계는 정확한 시간을 표시한 후 보조 서버를 통해 다른 시스템으로 방송됩니다. 이는 각 시스템이 정확한 시간에서 특정 오프셋을 경험한다는 것을 의미합니다.

애플리케이션과 데이터베이스가 서로 다른 시스템(다른 데이터 센터가 아닌 경우)에 위치하는 경우가 많기 때문에 상황은 더욱 악화됩니다. 따라서 시간은 서로 다른 시스템에 분산된 DB 노드에서만 달라지는 것이 아닙니다. 응용 프로그램 서버에서도 다릅니다.

Google TrueTime은 완전히 다른 접근 방식을 취합니다. 대부분의 사람들은 이 방향으로의 Google의 발전이 원자 시계와 GPS 시계로의 진부한 전환으로 설명된다고 믿지만 이는 큰 그림의 일부일뿐입니다. TrueTime의 작동 방식은 다음과 같습니다.

• TrueTime은 GPS와 원자 시계라는 두 가지 소스를 사용합니다. 이 시계에는 상관 관계가 없는 오류 모드가 있습니다. [자세한 내용은 5페이지를 참조하세요. 여기에 - 대략. 번역), 따라서 공동 사용으로 신뢰성이 높아집니다.
• TrueTime에는 특이한 API가 있습니다. 측정 오류와 불확실성이 내장된 간격으로 시간을 반환합니다. 실제 순간은 간격의 상한 경계와 하한 경계 사이의 어딘가에 있습니다. Google의 분산 데이터베이스인 Spanner는 현재 시간이 범위를 벗어났다고 안전하게 말할 때까지 기다립니다. 이 방법은 특히 마스터의 불확실성이 높은 경우 시스템에 약간의 대기 시간을 발생시키지만 전역적으로 분산된 상황에서도 정확성을 보장합니다.

Spanner 구성요소는 TT.now()가 간격을 반환하는 TrueTime을 사용하므로 Spanner는 현재 시간이 특정 지점을 지났다고 확신할 수 있는 지점까지 단순히 절전 모드로 유지됩니다.

현재 시간을 판단하는 정확도가 떨어지면 Spanner 작업 기간이 늘어나고 성능이 저하됩니다. 이것이 바로 완전히 정확한 시계를 얻는 것이 불가능하더라도 가능한 한 최고의 정확도를 유지하는 것이 중요한 이유입니다.

지연에는 많은 의미가 있습니다.

지연이 무엇인지 수십 명의 전문가에게 물어보면 아마도 다른 대답을 들을 수 있을 것입니다. DBMS에서 대기 시간은 종종 "데이터베이스 대기 시간"이라고 불리며 클라이언트가 인식하는 것과 다릅니다. 사실 클라이언트는 네트워크 지연과 데이터베이스 지연의 합을 관찰합니다. 증가하는 문제를 디버깅할 때 대기 시간 유형을 분리하는 기능은 매우 중요합니다. 측정항목을 수집하고 표시할 때 항상 두 가지 유형을 모두 주의 깊게 살펴보세요.

특정 트랜잭션에 대한 성능 요구 사항을 평가해야 합니다.

때로는 DBMS의 성능 특성과 제한 사항이 쓰기/읽기 처리량 및 대기 시간 측면에서 지정됩니다. 이는 주요 시스템 매개변수에 대한 일반적인 개요를 제공하지만, 새로운 DBMS의 성능을 평가할 때 훨씬 더 포괄적인 접근 방식은 중요한 작업(각 쿼리 및/또는 트랜잭션에 대해)을 별도로 평가하는 것입니다. 예:

• 관련 테이블에 지정된 제약 조건과 행 패딩을 사용하여 테이블 X(50천만 행 포함)에 새 행을 삽입할 때의 쓰기 처리량 및 대기 시간입니다.
• 평균 친구 수가 500명일 때 특정 사용자의 친구의 친구 표시가 지연됩니다.
• 사용자가 시간당 X 항목으로 100명의 다른 사용자를 팔로우할 때 사용자 기록에서 상위 500개 항목을 검색하는 데 지연이 발생합니다.

데이터베이스가 성능 요구 사항을 충족한다고 확신할 때까지 평가 및 실험에는 이러한 중요한 사례가 포함될 수 있습니다. 비슷한 경험 법칙에 따라 지연 시간 측정항목을 수집하고 SLO를 결정할 때 이러한 분석도 고려됩니다.

각 작업에 대한 지표를 수집할 때 높은 카디널리티에 유의하세요. 로그, 이벤트 수집 또는 분산 추적을 사용하여 고성능 디버깅 데이터를 얻습니다. 기사에서 "지연 시간을 디버그하고 싶나요?» 지연 디버깅 방법론에 익숙해질 수 있습니다.

중첩된 트랜잭션은 위험할 수 있습니다.

모든 DBMS가 중첩 트랜잭션을 지원하는 것은 아니지만 지원하는 경우 이러한 트랜잭션은 항상 감지하기 쉽지 않은 예기치 않은 오류를 초래할 수 있습니다(즉, 어떤 종류의 이상이 있음이 분명해야 합니다).

중첩 트랜잭션을 감지하고 우회할 수 있는 클라이언트 라이브러리를 사용하면 중첩 트랜잭션 사용을 피할 수 있습니다. 중첩된 트랜잭션을 중단할 수 없는 경우 완료된 트랜잭션이 중첩된 트랜잭션으로 인해 실수로 중단되는 예상치 못한 상황을 방지하기 위해 구현 시 특별한 주의를 기울이십시오.

서로 다른 계층에서 트랜잭션을 캡슐화하면 예상치 못한 중첩 트랜잭션이 발생할 수 있으며 코드 가독성 측면에서 작성자의 의도를 이해하기 어려울 수 있습니다. 다음 프로그램을 살펴보십시오.

with newTransaction():
   Accounts.create("609-543-222")
   with newTransaction():
       Accounts.create("775-988-322")
       throw Rollback();

위 코드의 출력은 무엇입니까? 두 트랜잭션을 모두 롤백합니까, 아니면 내부 트랜잭션만 롤백합니까? 트랜잭션 생성을 캡슐화하는 여러 계층의 라이브러리에 의존하면 어떻게 될까요? 이러한 사례를 파악하고 개선할 수 있을까요?

여러 작업이 포함된 데이터 레이어를 상상해 보세요(예: newAccount)은 이미 자체 트랜잭션에서 구현되었습니다. 자체 트랜잭션 내에서 실행되는 상위 수준 비즈니스 로직의 일부로 이를 실행하면 어떻게 되나요? 이 경우 격리성과 일관성은 어떻게 될까요?

function newAccount(id string) {
  with newTransaction():
      Accounts.create(id)
}

이렇게 끝없는 질문에 대한 답을 찾는 것보다 중첩된 트랜잭션을 피하는 것이 좋습니다. 결국 데이터 계층은 자체 트랜잭션을 생성하지 않고도 쉽게 높은 수준의 작업을 수행할 수 있습니다. 또한 비즈니스 로직 자체는 트랜잭션을 시작하고, 이에 대한 작업을 수행하고, 트랜잭션을 커밋하거나 중단할 수 있습니다.

function newAccount(id string) {
   Accounts.create(id)
}
// In main application:
with newTransaction():
   // Read some data from database for configuration.
   // Generate an ID from the ID service.
   Accounts.create(id)
   Uploads.create(id) // create upload queue for the user.

트랜잭션은 애플리케이션 상태와 연결되어서는 안 됩니다.

때로는 트랜잭션에서 애플리케이션 상태를 사용하여 특정 값을 변경하거나 쿼리 매개변수를 조정하고 싶은 유혹이 있을 수 있습니다. 고려해야 할 중요한 차이는 올바른 적용 범위입니다. 클라이언트는 네트워크 문제가 있을 때 종종 트랜잭션을 다시 시작합니다. 트랜잭션이 다른 프로세스에 의해 변경되는 상태에 의존하는 경우 데이터 경합 가능성에 따라 잘못된 값을 선택할 수 있습니다. 트랜잭션은 애플리케이션의 데이터 경합 조건 위험을 고려해야 합니다.

var seq int64
with newTransaction():
    newSeq := atomic.Increment(&seq)
    Entries.query(newSeq)
    // Other operations...

위의 트랜잭션은 최종 결과에 관계없이 실행될 때마다 시퀀스 번호를 증가시킵니다. 네트워크 문제로 인해 커밋이 실패할 경우 다시 시도하면 다른 시퀀스 번호로 요청이 실행됩니다.

쿼리 플래너는 데이터베이스에 대해 많은 정보를 제공할 수 있습니다.

쿼리 플래너는 데이터베이스에서 쿼리가 실행되는 방법을 결정합니다. 또한 요청을 보내기 전에 분석하고 최적화합니다. 계획자는 자신이 처분할 수 있는 신호를 기반으로 일부 가능한 추정치만 제공할 수 있습니다. 예를 들어, 다음 쿼리에 대한 가장 좋은 검색 방법은 무엇입니까?

SELECT * FROM articles where author = "rakyll" order by title;

결과는 두 가지 방법으로 검색할 수 있습니다.

• 전체 테이블 스캔: 표의 각 항목을 보고 작성자 이름이 일치하는 기사를 반환한 후 주문할 수 있습니다.
• 인덱스 스캔: 인덱스를 사용하여 일치하는 ID를 찾고 해당 행을 가져온 다음 순서를 지정할 수 있습니다.

쿼리 플래너의 임무는 어떤 전략이 가장 좋은지 결정하는 것입니다. 쿼리 플래너의 예측 기능은 제한적이라는 점을 고려해 볼 가치가 있습니다. 이는 잘못된 결정으로 이어질 수 있습니다. DBA 또는 개발자는 이를 사용하여 성능이 저하된 쿼리를 진단하고 세부 조정할 수 있습니다. 새 버전의 DBMS는 쿼리 플래너를 구성할 수 있으며, 새 버전으로 인해 성능 문제가 발생할 경우 데이터베이스를 업데이트할 때 자가 진단이 도움이 될 수 있습니다. 느린 쿼리 로그, 대기 시간 문제 보고서 또는 실행 시간 통계는 최적화가 필요한 쿼리를 식별하는 데 도움이 됩니다.

쿼리 플래너가 제공하는 일부 측정항목에는 노이즈가 있을 수 있습니다(특히 대기 시간이나 CPU 시간을 추정할 때). 스케줄러에 추가되는 좋은 기능은 실행 경로를 추적하는 도구입니다. 이러한 도구를 사용하면 이러한 문제를 진단할 수 있습니다(아쉽게도 모든 DBMS가 이러한 도구를 제공하는 것은 아닙니다).

온라인 마이그레이션은 어렵지만 가능합니다.

온라인 마이그레이션, 실시간 마이그레이션 또는 실시간 마이그레이션은 가동 중지 시간이나 데이터 손상 없이 한 데이터베이스에서 다른 데이터베이스로 이동하는 것을 의미합니다. 동일한 DBMS/엔진 내에서 전환이 발생하면 실시간 마이그레이션을 수행하기가 더 쉽습니다. 성능과 스키마 요구 사항이 서로 다른 새로운 DBMS로 이동해야 하는 경우 상황은 더욱 복잡해집니다.

다양한 온라인 마이그레이션 모델이 있습니다. 다음은 그중 하나입니다.

• 두 데이터베이스 모두에서 이중 입력을 활성화합니다. 이 단계의 새 데이터베이스에는 모든 데이터가 포함되지 않고 최신 데이터만 허용됩니다. 이것을 확신하면 다음 단계로 넘어갈 수 있습니다.
• 두 데이터베이스 모두에서 읽기를 활성화합니다.
• 읽기와 쓰기가 주로 새 데이터베이스에서 수행되도록 시스템을 구성합니다.
• 이전 데이터베이스에서 데이터를 계속 읽는 동안 이전 데이터베이스에 대한 쓰기를 중지합니다. 이 단계에서 새 데이터베이스에는 여전히 일부 데이터가 없습니다. 이전 데이터베이스에서 복사해야 합니다.
• 이전 데이터베이스는 읽기 전용입니다. 이전 데이터베이스에서 누락된 데이터를 새 데이터베이스로 복사합니다. 마이그레이션이 완료되면 경로를 새 데이터베이스로 전환하고 이전 데이터베이스를 중지하고 시스템에서 삭제합니다.

추가 정보를 원하시면 문의하시기 바랍니다. 기사, 이 모델을 기반으로 한 Stripe의 마이그레이션 전략을 자세히 설명합니다.

데이터베이스가 크게 증가하면 예측 불가능성이 증가합니다.

데이터베이스의 증가로 인해 규모와 관련된 예측할 수 없는 문제가 발생합니다. 데이터베이스의 내부 구조에 대해 더 많이 알수록 데이터베이스의 확장 방식을 더 잘 예측할 수 있습니다. 그러나 어떤 순간은 아직 예측이 불가능합니다.
기반이 성장함에 따라 데이터 볼륨 및 네트워크 대역폭 요구 사항에 대한 이전 가정과 기대는 시대에 뒤떨어지게 될 수 있습니다. 이는 잠재적인 문제를 피하기 위해 대대적인 설계 정밀 검사, 대규모 운영 개선, 배포 재고 또는 다른 DBMS로의 마이그레이션에 대한 의문이 제기되는 때입니다.

그러나 기존 데이터베이스의 내부 구조에 대한 뛰어난 지식만이 필요하다고 생각하지 마십시오. 새로운 저울은 새로운 미지의 것을 가져올 것입니다. 예측할 수 없는 문제점, 고르지 못한 데이터 분포, 예상치 못한 대역폭 및 하드웨어 문제, 계속 증가하는 트래픽 및 새로운 네트워크 세그먼트로 인해 데이터베이스 접근 방식, 데이터 모델, 배포 모델 및 데이터베이스 크기를 다시 생각하게 됩니다.

...

이 기사를 게시하려고 생각하기 시작했을 때 원래 목록에는 이미 XNUMX개 항목이 더 있었습니다. 그러다가 엄청난 숫자가 나왔어 새로운 아이디어 그 밖에 무엇을 다룰 수 있는지에 대해. 따라서 이 기사에서는 최대한의 주의가 필요한 가장 명확하지 않은 문제를 다룹니다. 그러나 이것이 주제가 소진되었음을 의미하는 것은 아니며 향후 자료에서 더 이상 해당 주제로 돌아가지 않을 것이며 현재 자료를 변경하지 않을 것입니다.

PS

블로그에서도 읽어보세요.

• «데이터베이스 및 Kubernetes(개요 및 동영상 보고서)";
• «분산 추적: 우리가 모두 잘못했습니다";
• «Service Mesh: 최신 기술에 대해 모든 소프트웨어 엔지니어가 알아야 할 사항".

출처 : habr.com