일관된 백엔드 및 UX : 무엇이 잘못 될 수 있습니까?

기사 시리즈

1. 왜 신경 쓰야합니까?
2. 어떤 문제가 발생할 수 있습니까?
3. 새로운 기술 채택의 장벽은 무엇입니까?
4. 새로운 알고리즘은 어떻게 도움이됩니까?

이전 기사는 강력한 일관성을 설명합니다 (최종 일관성과는 반대로). 이 기사는 시리즈의 두 번째 부분이며, 일관성이 강해져서 최종 사용자 경험을 제공하기가 더 어려워지고, 심각한 엔지니어링 오버 헤드로 이어질 수있는 방법 및 공격에 취약하게 만드는 방법을 설명합니다. 이 섹션은 다른 데이터베이스 예외를 설명하고 여러 예제 시나리오를 사용하고 각 예외에 취약한 데이터베이스 유형을 간략하게 설명하기 때문에 더 길다.

사용자 경험은 모든 응용 프로그램 성공의 동인이며, 일관되지 않은 백엔드에 의존하면 좋은 경험을 제공하는 데 어려움이 있습니다. 더 중요한 것은, 일관성이없는 데이터 위에 응용 프로그램 논리를 구축하면 취약점이 생길 수 있습니다. 하나의 논문은 이러한 유형의 공격을 "산성 레인"이라고 부릅니다. 그들은 가장 인기있는 자체 호스팅 전자 상거래 응용 프로그램 중 12 개를 조사하여 최소 22 개 이상의 가능한 심각한 공격을 발견했습니다. 하나의 웹 사이트는 Bitcoin 지갑 서비스이며 이러한 공격으로 인해 종료되어야했습니다. 100% 산이 아닌 분산 데이터베이스를 선택할 때 문제가 있습니다. 이전의 예에서 설명 하듯이 엔지니어는 오해, 불분명하게 정의 된 용어 및 급진적 인 마케팅으로 인해 특정 데이터베이스가 제공 한 보증을 결정하기가 어렵습니다.

어떤 문제가 있습니까? 애플리케이션은 계정 잔액 오류, 사용자 보상 수신, 거래 실행, 순서대로 메시지 또는 응답 애플리케이션 규칙 위반과 같은 문제를 경험할 수 있습니다. 분산 데이터베이스가 필요한 이유와 어려운 이유에 대한 빠른 소개는 첫 번째 게시물 또는이 멋진 비디오 설명을 참조하십시오. 요컨대, 분산 데이터베이스는 확장 성, 대기 시간 및 가용성을 위해 여러 위치에 데이터 사본을 보유하는 데이터베이스입니다.

우리는이 네 가지 잠재적 문제 (그 이상)를 다루고 게임 개발의 예제로 설명 할 것입니다. 게임 개발은 복잡 하며이 개발자들은 실제 생활의 심각한 문제와 매우 유사한 많은 문제에 직면 해 있습니다. 게임에는 거래 시스템, 메시지 시스템, 조건을 충족 해야하는 보상 등이 있습니다. 게임에서는 사용자 경험이 중요하므로 게임 개발자는 종종 시스템이 결함이 있는지 확인해야합니다.

준비가 된? 첫 번째 잠재적 인 문제로 뛰어 들자!

1. 오래된 독서

오래된 읽기는 오래된 데이터를 반환하는 읽기를 말합니다. 즉, 반환 된 값은 최신 쓰기에 따라 업데이트되지 않았습니다. 복제본으로 확장하는 기존 데이터베이스를 포함하여 많은 분산 데이터베이스 (이러한 데이터베이스의 작동 방식을 이해하려면 1 부 읽기)는 오래된 읽기 문제를 경험합니다.

최종 사용자에게 미치는 영향

첫째, Stale Reads는 최종 사용자에게 영향을 미칩니다. 그리고 이것은 단일 영향이 아닙니다.

실망스러운 경험과 불공정 한 장점

게임의 두 사용자가 금화로 보물 상자를 만나고 있다고 상상해보십시오. 첫 번째 사용자는 하나의 데이터베이스 서버에서 데이터를 수신하고 두 번째 사용자는 두 번째 데이터베이스 서버에 연결됩니다. 이벤트 순서는 다음과 같습니다.

1. 사용자 1 (데이터베이스 서버를 통해)은 보물 상자를보고 엽니 다.
2. 사용자 2 (데이터베이스 서버 2를 통해)는 전체 보물 상자를보고 열고 실패합니다.
3. 사용자 2는 여전히 완전한 보물 상자를보고 왜 실패하는지 이해하지 못합니다.

이것은 사소한 문제처럼 보일지 모르지만 결과는 두 번째 플레이어 경험이 실망 스럽습니다. 그는 단점 일뿐 만 아니라 게임의 상황이 존재하지만 존재하지 않는 상황을 종종 본다. 다음으로, 오래된 독서에 대한 행동을 취하는 플레이어의 예를 살펴 보겠습니다!

내구성있는 독서는 반복 된 글로 이어집니다

게임의 캐릭터가 상점에서 방패와 검을 사려고한다고 상상해보십시오. 여러 위치에 데이터가 포함되어 있고 지능형 시스템이 일관성을 제공하지 않으면 한 노드에 다른 노드가 다른 것보다 오래된 데이터를 포함합니다. 이 경우 사용자는 항목을 구매 한 다음 (첫 번째 노드에 문의) 인벤토리를 확인한 다음 (두 번째 노드에 연락) 항목이 존재하지 않는지 확인할 수 있습니다. 사용자는 혼란 스러울 수 있으며 거래가 성공하지 못한다고 생각할 수 있습니다. 이 경우 대부분의 사람들은 무엇을할까요? 글쎄, 그들은 다시 아이템을 사려고 할 것입니다. 두 번째 노드가 따라 잡으면 사용자는 사본을 구입하고 사본이 잡히면 갑자기 돈이 부족하고 각 항목의 두 조각이 있음을 알게됩니다. 그는 우리 게임이 깨 졌다고 생각합니다.

이 경우 사용자는 지출하고 싶지 않은 리소스를 소비합니다. 해당 데이터베이스 위에 이메일 클라이언트를 작성하면 사용자가 이메일을 보내고 브라우저를 새로 고치려고 할 수 있지만 방금 보낸 이메일을 검색 할 수 없으므로 다시 전송됩니다. 좋은 사용자 경험을 제공하고 그러한 시스템 위에서 은행 거래와 같은 안전한 거래 (예 : 은행 거래)를 구현하는 것은 매우 어렵습니다.

개발자에게 미치는 영향

인코딩 할 때는 항상 무언가가 존재하지 않고 그에 따라 인코딩해야합니다. 읽기가 궁극적으로 일관 될 때 결함 방지 코드 작성이 매우 어려워지고 사용자는 응용 프로그램에 문제가있을 수 있습니다. 읽기가 마침내 일관되면,이 질문들은 당신이 그것들을 조사하기 전에 사라집니다. 기본적으로, 당신은 유령을 쫓아갑니다. 개발자는 여전히 문제를 알아 차리는 데 시간이 걸리기 때문에 여전히 궁극적으로 일관된 데이터베이스 또는 배포 방법을 선택합니다. 그런 다음 응용 프로그램에 문제가 발생하면 창의력을 발휘하고 기존 데이터베이스 위에 솔루션 (1, 2)을 구축하여 오래된 읽기를 수정하려고합니다. 이러한 가이드가 많이 있으며 Cassandra와 같은 데이터베이스가 이러한 문제가 실제적이며 생각보다 생산 시스템에서 문제를 일으킨다는 것을 보여주는 일관성 기능을 구현했다는 사실이 있습니다. 일관성을 위해 구축되지 않은 시스템 위에 구축 된 맞춤형 솔루션은 복잡하고 깨지기 쉽습니다. 상자 밖에서 강한 일관성을 제공하는 데이터베이스가 있다면 왜 그런 문제를 경험합니까?

이 예외를 나타내는 데이터베이스

기본 읽기 복제를 사용하는 기존 데이터베이스 (PostgreSQL, MySQL, SQL Server 등)는 일반적으로 오래된 읽기 문제를 경험합니다. 많은 새로운 분산 데이터베이스는 또한 처음에 또는 부실한 읽기에 대한 보호없이 처음 또는 말로 일관성이 있습니다. 이는 개발자 커뮤니티에 대한 강력한 믿음 때문입니다. 확장에 필요합니다. 이것은 가장 유명한 데이터베이스가 시작된 방식이지만 사용자 가이 예외를 처리하기 위해 어떻게 어려움을 겪고 있는지 인식하고 이후이를 피하기위한 추가 조치를 제공했습니다. 효율적이고 일관성있는 (예 : Cassandra, CouchDB 및 DynamODB)를 제공하도록 설계되지 않은 구형 데이터베이스 또는 데이터베이스는 기본적으로 일관됩니다. Riak과 같은 다른 접근법도 궁극적으로 일관성이 있지만, 구식 값의 가능성을 줄이기 위해 충돌 해결 시스템을 구현함으로써 다른 경로가 취해집니다. 그러나 충돌 해결이 완벽하지 않으므로 데이터 보안을 보장하지는 않습니다.

2. Lost Write

분산 데이터베이스 분야에서는 쓰기가 동시에 발생할 때 중요한 선택을해야합니다. 하나의 옵션 (안전한 옵션)은 모든 데이터베이스 노드 가이 쓰기의 순서에 동의하는지 확인하는 것입니다. 이는 동기 시계 (특정 하드웨어가 필요한) 또는 Calvin과 같은 시계 독립적 지능형 알고리즘이 필요하기 때문에 사소한 것과는 거리가 멀다. 두 번째 덜 안전한 옵션은 각 노드가 로컬로 쓰기를 한 다음 나중에 충돌을 처리하는 방법을 결정하는 것입니다. 데이터베이스에 대한 두 번째 옵션을 선택하면 쓰기가 손실 될 수 있습니다.

최종 사용자에게 미치는 영향

게임에서 두 가지 거래를 고려할 때, 우리는 11 개의 금화로 시작하여 두 가지 아이템을 구입합니다. 먼저, 우리는 5 개의 금화에 대한 검을 구입 한 다음 5 개의 금화에 대한 방패를 구입하고 두 거래는 분산 데이터베이스의 다른 노드로 향합니다. 각 노드는 값을 읽고이 경우 두 노드 모두에 대해 여전히 11입니다. 두 노드는 복제를 알지 못하기 때문에 결과 (11-5)로 6을 쓰기로 결정합니다. 두 번째 트랜잭션은 첫 번째 거래가 작성된 가치를 보지 못했기 때문에 플레이어는 10 개의 코인 대신 총 5 개의 코인을 위해 검과 방패를 구입하게됩니다. 사용자에게는 좋지만 시스템에 좋지 않습니다! 이 동작을 해결하기 위해 분산 데이터베이스에는 몇 가지 전략이 있습니다. 일부는 다른 전략보다 낫습니다.

결의 전략에는 "LWW (Last Write Win) (LWW) 또는"LONTEST 버전 기록 "(LVH) WIN이 포함됩니다. LWW는 오랫동안 Cassandra의 정책이었으며 다르게 구성하지 않으면 여전히 기본 동작입니다.

우리가 이전 예제에 LWW 충돌 해결을 적용하면 플레이어는 여전히 6 개의 금화가 남아 있지만 하나의 품목 만 구매됩니다. 데이터베이스가 인벤토리에있는 것으로 식별하지 않더라도 앱이 두 번째 항목 구매를 확인했기 때문에 사용자 경험이 좋지 않습니다.

예측할 수없는 보안

당신이 상상할 수 있듯이, 그러한 시스템 위에 보안 규칙을 작성하는 것은 안전하지 않습니다. 많은 응용 프로그램은 백엔드의 복잡한 보안 규칙 (또는 가능한 한 데이터베이스에서 직접)에 의존하여 사용자가 리소스에 액세스 할 수 있는지 여부를 결정합니다. 이 규칙이 끊임없이 업데이트 된 오래된 데이터를 기반으로하는 경우 어떻게 위반이 없을 수 있습니까? PAAS 애플리케이션 사용자가 그의 관리자에게 전화를 걸어 다음과 같이 묻습니다. "이 공개 그룹을 비공개로 만들 수 있도록 내부 데이터를 재사용 할 수 있습니까?" 관리자는 조치를 적용하고 그 행동이 완료되었다고 말합니다. 그러나 관리자와 사용자는 다른 노드에있을 수 있으므로 사용자는 기술적으로 여전히 공개 된 그룹에 민감한 데이터를 추가하기 시작할 수 있습니다.

개발자에게 미치는 영향

쓰기가 손실되면 사용자 문제를 디버깅하는 것이 악몽이 될 것입니다. 사용자가 자신의 앱에서 데이터를 잃어버린 다음 답장 시간을 얻는 데 하루가 걸렸다 고 상상해보십시오. 데이터베이스 또는 결함이있는 응용 프로그램 논리로 문제가 발생하는지 어떻게 알 수 있습니까? Faunadb 또는 Datomic과 같은 데이터 기록을 추적 할 수있는 데이터베이스에서 과거로 추적하여 데이터가 어떻게 조작되었는지 확인할 수 있습니다. 그러나 이러한 데이터베이스 중 어느 것도 누락 된 쓰기의 영향을받지 않으며, 실제로 그러한 예외에 취약한 데이터베이스에는 일반적으로 시간 종료 기능이 없습니다.

글로 쉽게 잃어버린 데이터베이스

충돌 회피 대신 충돌 해결을 사용하는 모든 데이터베이스는 쓰기를 잃게됩니다. Cassandra와 DynamoDB는 LWW (Last Write Win)를 기본값으로 사용합니다. MongoDB는 LWW를 사용했지만 이후 버려졌습니다. MySQL과 같은 기존 데이터베이스의 마스터 마스터 배포 방법은 다른 충돌 해결 전략을 제공합니다. 일관성을 위해 구축되지 않은 많은 분산 데이터베이스는 글을 잃습니다. Riak의 가장 쉬운 충돌 해결은 LWW에 의해 구동되지만 더 똑똑한 시스템을 가능하게합니다. 그러나 스마트 시스템에서도 충돌을 해결하는 명백한 방법이 없습니다. Riak과 CouchDB는 클라이언트 또는 응용 프로그램에 올바른 쓰기를 선택하는 책임을 맡아 보관할 버전을 수동으로 선택할 수 있습니다.

분포가 복잡하기 때문에 대부분의 데이터베이스는 불완전한 알고리즘을 사용하므로 노드가 충돌하거나 네트워크 파티션이 나타나면 누락 된 쓰기는 종종 많은 데이터베이스에서 발생합니다. MongoDB (쓰기를 배포하지 않음 (쓰기는 노드로 이동))에도 불구하고, 쓰기 직후에 노드가 충돌하는 드문 경우에서는 쓰기 충돌이 발생할 수 있습니다.

3. 편차를 쓰십시오

쓰기 바이어스는 데이터베이스 공급 업체가 스냅 샷 일관성을 호출하는 보증 유형에서 발생할 수있는 일입니다. 스냅 샷 일관성에서 트랜잭션은 트랜잭션의 시작 부분에서 수행 된 스냅 샷에서 읽습니다. 스냅 샷 일관성은 많은 예외를 방지합니다. 실제로, 많은 사람들은 종이 (PDF)가 그렇지 않다는 것을 증명할 때까지 완전히 안전하다고 생각합니다. 따라서 개발자가 왜 일부 보증이 충분하지 않은지 이해하는 데 어려움이 있다는 것은 놀라운 일이 아닙니다.

스냅 샷 일관성에서 작동하지 않는 내용에 대해 논의하기 전에 먼저 어떤 효과가 있는지 논의 해 봅시다. 우리가 기사와 마법사 사이에 싸움을했다고 가정 해 봅시다. 그의 활력은 4 개의 마음으로 구성되어 있습니다.

캐릭터가 공격을 받으면 거래는 얼마나 많은 마음이 제거되었는지 계산하는 기능입니다.

 <code>damageCharacter(character, damage) { character.hearts = character.hearts - damage character.dead = isCharacterDead(character) }</code>

그리고 각 공격 후에는 다른 ISCharacterDead 기능도 캐릭터에 마음이 있는지 확인합니다.

 <code>isCharacterDead(character) { if (character.hearts </code>

간단한 경우, 기사의 공격은 마법사에서 3 개의 하트를 제거한 다음 마법사의 주문은 기사에서 4 개의 마음을 제거하고 자신의 건강을 4로 회복시킵니다. 한 트랜잭션이 차례로 진행되면 두 트랜잭션이 대부분의 데이터베이스에서 올바르게 작동합니다.

그러나 우리가 세 번째 거래, 기사의 공격을 추가하면 마법사의 주문과 동시에 진행되면 어떻게해야합니까?

기사가 죽었습니까? 마법사는 아직 살아 있습니까?

이러한 혼란을 해결하기 위해 스냅 샷 일관성 시스템은 종종 "첫 번째 커밋터 승리"라는 규칙을 구현합니다. 거래는 다른 거래가 같은 라인에 기록되지 않은 경우에만 종료 될 수 있습니다. 그렇지 않으면 롤백됩니다. 이 예에서는 두 거래 모두 같은 라인 (마법사의 건강 가치)에 쓰려고 노력하기 때문에 생명을 구하는 주문 만 작동하며 기사의 두 번째 공격은 롤백됩니다. 그러면 최종 결과는 이전 예와 동일합니다 : 죽은 기사와 건강을 가진 마법사.

그러나 MySQL 및 InnoDB와 같은 일부 데이터베이스는 스냅 샷 격리의 일부로 "첫 번째 커밋터 승리"를 고려하지 않습니다. 이 경우 우리는 잃어버린 글을 쓸 것입니다. 마법사는 이제 죽었지 만, 기사의 공격이 발효되기 전에 인생에서 건강 포인트를 얻어야합니다. (우리는 불분명 한 용어와 느슨한 설명을 언급했습니다.)

"First Committer Wins"규칙을 포함하는 스냅 샷 일관성은 몇 가지를 잘 처리합니다. 오랫동안 좋은 솔루션으로 간주되어 왔기 때문에 놀라운 것은 아닙니다. 이것은 여전히 ​​PostgreSQL, Oracle 및 SQL Server의 방법이지만 모두 다른 이름을 가지고 있습니다. PostgreSQL은이 보증을 "반복 가능"하고, Oracle은이를 "Serializable (정의에 의해 잘못)이라고 부르며 SQL Server는이를"Snapshot 격리 "라고 부릅니다. 이 용어 숲에서 사람들이 길을 잃은 것은 당연합니다. 예상대로 작동하지 않는 예를 살펴 보겠습니다!

최종 사용자에게 미치는 영향

다음 전투는 두 군대 사이에서 일어날 것이며, 군대의 모든 인물이 죽었다면 한 군대는 죽은 것으로 간주됩니다.

 Isarmydead (육군) {
  if (모든 문자가 죽었습니다) {return true}
  else {return false}
}

각 공격 후 다음 함수는 캐릭터가 죽는 지 여부를 결정한 다음 위의 기능을 실행하여 군대가 죽는 지 확인합니다.

 DamagearmyCharacter (군대, 성격, 손상) {
  문자 .Hearts = 문자 .Hearts- 손상
  문자 .dead = ischaracterdead (캐릭터)
  군대 = Isarmydead (육군)
  if (Army.dead! = ArmyDead) {
    군대 .dead = 군대
  }
}

첫째, 캐릭터의 마음은 피해에 의해 감소 ​​될 것입니다. 그런 다음 각 캐릭터가 건강이 없는지 확인하여 군대가 죽었는지 확인합니다. 그런 다음 군대의 상태가 바뀌면 군대의 "죽음"부울을 업데이트 할 것입니다.

3 개의 마법사가 각각 한 번 공격하여 3 개의 "생명 흡수"가 발생했습니다. 스냅 샷은 트랜잭션의 시작 부분에서 수행되며 모든 트랜잭션이 동시에 시작되므로 스냅 샷은 동일합니다. 각 거래에는 모든 기사가 여전히 건강을 유지하는 데이터 사본이 있습니다.

첫 번째 "생명 흡수"거래가 어떻게 해결되는지 봅시다. 이 거래에서 MAGE1은 Knight1을 공격하고 Knight는 4 개의 건강 지점을 잃고 공격자는 모든 건강 지점을 복원합니다. 이 문제는 기사 군대가 죽지 않았다고 결정했다. 왜냐하면 두 기사가 여전히 건강을 가졌고 한 기사가 죽은 스냅 샷을 볼 수 있었기 때문이다. 다른 두 거래는 다른 마법사와 기사에서 작용하지만 비슷한 방식으로 수행됩니다. 이 거래 각각에는 처음에는 데이터 사본에 세 명의 살아있는 기사가 있으며, 한 기사만이 죽었습니다. 그러므로 모든 문제는 기사단의 군대가 여전히 살아 있다고 결정합니다.

모든 거래가 완료되면, 기사 중 어느 것도 살아 있지 않지만, 우리가 군대가 죽는 지 여부를 나타내는 부울 가치는 여전히 거짓으로 설정되어 있습니다. 왜? 스냅 샷을 찍을 때 기사는 죽지 않았기 때문입니다. 따라서 각 거래는 자체 기사가 죽는 것을 보지만 군대의 다른 기사들을 알지 못합니다. 이것은 우리 시스템에서 예외 (Write Bias라고 함)이지만, 쓰기는 각각 다른 역할에 글을 쓰고 군대에 대한 쓰기가 결코 변하지 않았기 때문에 통과되었습니다. 좋아, 우리는 지금 유령 군대가있다!

개발자에게 미치는 영향

데이터 품질

사용자가 고유 한 이름을 가지고 있는지 확인하려면 어떻게해야합니까? 사용자가 생성 한 거래는 이름이 존재하는지 확인합니다. 존재하지 않으면 해당 이름을 사용하여 새 사용자에게 쓸 것입니다. 그러나 두 사용자가 동일한 이름으로 등록하려고하면 스냅 샷에 사용자가 다른 행에 기록되므로 충돌이 없기 때문에 스냅 샷에 아무것도 눈치 채지 못합니다. 이제 시스템에 동일한 이름의 두 사용자가 있습니다.

쓰기 바이어스로 인해 다른 많은 예외 예제가 나타날 수 있습니다. 관심이 있으시면 Martin Kleppman의 저서 Data Dataining Data-Intensive Applications가이를 자세히 설명합니다.

롤백을 피하기 위해 다양한 방식으로 코드를 작성합니다

이제 공격이 군대에서 특정 역할을 목표로하지 않는 다른 접근법을 고려해 봅시다. 이 경우 데이터베이스는 먼저 공격 할 기사를 선택해야합니다.

 Damagearmy (군대, 손상) {
  문자 = GetFirsthealthycharacter (기사)
  문자 .Hearts = 문자 .Hearts- 손상
  문자 .dead = ischaracterdead (캐릭터)
  // ...
}

이전 예제와 같이 여러 개의 공격을 수행하면 GetFirsthealthyCharacter는 항상 동일한 기사를 대상으로하여 여러 트랜잭션이 동일한 라인에 기록됩니다. 이것은 "첫 번째 제출자 승리"규칙에 의해 차단되며, 이는 다른 두 공격을 롤백합니다. 예외를 방지하지만 개발자는 이러한 문제를 이해하고 주변에 창의적으로 코드를 작성해야합니다. 그러나 데이터베이스가 상자 밖으로 나가면 더 쉽지 않습니까?

편차를 작성하기 쉬운 데이터베이스

직렬화가 아닌 스냅 샷 격리를 제공하는 모든 데이터베이스는 쓰기 편향을 경험할 수 있습니다. 데이터베이스 및 격리 수준에 대한 개요는이 기사를 참조하십시오.

4. 순서 쓰기

누락 된 글과 오래된 읽기를 피하기 위해 분산 데이터베이스의 목표는 " 강한 일관성 "입니다. 우리는 데이터베이스가 글로벌 질서 (안전한 선택)에 동의하거나 갈등을 해결하기로 결정할 수 있다고 언급했습니다 (저술이 손실 된 선택). 우리가 글로벌 주문을 결정한다면, 검과 방패가 병렬로 구입되지만 최종 결과는 우리가 칼을 먼저 구입 한 다음 방패를 구입 한 것처럼 행동해야한다는 것을 의미합니다. 데이터베이스 작업을 선형화 할 수 있기 때문에 일반적으로 "선형화"라고도합니다. 선형화는 데이터 보안을 보장하기위한 금 표준입니다.

다른 공급 업체는 다른 격리 수준을 제공하며 여기에서 비교할 수 있습니다. 종종 나타나는 한 용어는 직렬화입니다. 이는 강한 일관성 (또는 선형화)의 약간 덜 엄격한 버전입니다. 직렬화는 이미 상당히 강하고 대부분의 예외를 다루지 만 여전히 글의 재정렬으로 인해 약간의 예외가 남아 있습니다. 이 경우 거래가 커밋 된 경우에도 데이터베이스가 주문을 자유롭게 전환 할 수 있습니다. 간단히 말해서, 선형화는 직렬화와 보장 된 순서입니다. 데이터베이스 에이 보장 된 주문이 없으면 응용 프로그램은 주문 외 쓰기에 취약합니다.

최종 사용자에게 미치는 영향

대화 재정렬

누군가가 오류로 인해 두 번째 메시지를 보내면 대화를 혼란스럽게 정렬 할 수 있습니다.

사용자 작업 재정렬

우리의 플레이어가 11 개의 금화를 가지고 있고 자신이 소유 한 금화의 양을 적극적으로 확인하지 않고 중요한 순서로 품목을 구매하는 경우 데이터베이스는 이러한 구매 주문을 재정렬 할 수 있습니다. 돈이 충분하지 않으면 먼저 가장 중요한 품목을 먼저 구입할 수있었습니다.

이 경우 금이 충분한지 확인하기위한 데이터베이스 점검이 있습니다. 0 미만의 계좌를 가질 수있는 돈이 충분하지 않다고 상상해보십시오. 은행이 0 미만일 때 초과 인출 수수료를 청구하는 것처럼 돈이들 것입니다. 세 품목을 모두 구매하기에 충분한 돈이 있는지 확인하기 위해 하나의 품목을 신속하게 판매 할 수 있습니다. 그러나 잔액을 늘리기 위해 설계된 판매는 거래 목록의 끝까지 재정렬 될 수 있으며, 이로 인해 잔액은 0보다 낮습니다. 이것이 은행이라면, 당신은 절대로 참을 수없는 경비를 일으킬 가능성이 높습니다.

예측할 수없는 보안

보안 설정을 구성한 후 사용자는 이러한 설정이 다가오는 모든 작업에 적용될 것으로 예상하지만 사용자가 다른 채널을 통해 서로 대화 할 때 문제가 발생할 수 있습니다. 우리가 논의한 예를 기억하십시오. 관리자는 그룹을 비공개로 만들고 싶어서 민감한 데이터를 추가하는 사용자와 대화하고 있습니다. 이는 직렬화 가능성을 제공하는 데이터베이스에서 발생할 수 있지만,이 상황의 시간 창이 작아 지지만, 사용자 작업이 끝날 때까지 관리자의 작업이 완료되지 않을 수 있기 때문에 여전히 발생할 수 있습니다. 사용자가 다른 채널을 통해 통신하고 데이터베이스를 실시간으로 정렬 할 것으로 예상하면 상황이 잘못됩니다.

이 예외는 사용자가로드 밸런싱으로 인해 다른 노드로 리디렉션되는 경우에도 발생합니다. 이 경우 두 개의 연속 작업이 다른 노드에서 끝나고 재정렬 될 수 있습니다. 소녀가 제한된 시청 권한을 가진 Facebook 그룹에 부모를 추가하고 봄 방학 사진을 게시하는 경우이 이미지는 여전히 부모의 피드에 나타날 수 있습니다.

다른 예에서, 자동 거래 봇은 구매 가격이 가장 높은 환경, 지출 한도 및 집중할 주식 목록을 가질 수 있습니다. 사용자가 봇이 구매 해야하는 주식 목록을 변경 한 다음 지출 한도를 변경하면 거래가 재정렬되고 봇이 이전 주식에 새로 할당 된 예산을 사용한 경우에는 행복하지 않습니다.

개발자에게 미치는 영향

취약성

일부 취약점은 거래의 잠재적 인 반전에 의존합니다. 게이머가 1,000 골드 동전을 가지고 일단 트로피를받을 것이라고 상상해보십시오. 그는이 트로피를 정말로 원합니다. 이 게임은 플레이어가 골드 코인의 여러 컨테이너 (예 : 스토리지 및 캐리 (재고)를 추가하여 플레이어가 가지고있는 금 동전 수를 계산합니다. 플레이어가 스토리지와 재고간에 돈을 빠르게 교환하면 실제로 시스템을 속일 수 있습니다.

다음 수치에서, 두 번째 플레이어는 범죄 파트너 역할을하여 스토리지와 재고 간 자금의 전송이 다른 거래에서 발생하도록함으로써 이러한 거래가 다른 노드로 라우팅 될 가능성이 높아집니다. 현실 세계에서 더 심각한 예는 타사 계정을 사용하여 돈을 이체하는 은행입니다. 은행은 다양한 거래가 다른 노드로 전송되었고 정렬 할 시간이 충분하지 않기 때문에 누군가가 대출을받을 자격이 있는지 여부를 잘못 계산할 수 있습니다.

주문 외부 쓰기 경향이있는 데이터베이스

선형화를 제공하지 않는 모든 데이터베이스는 쓰기 편향을 경험할 수 있습니다. 어떤 데이터베이스가 선형화를 제공하는지에 대한 개요는이 기사를 참조하십시오. 스포일러 : 많지 않습니다.

일관성이 제한되면 모든 예외가 돌아올 수 있습니다

결국 논의 할 강력한 일관성의 완화는 그것이 특정 범위 내에 있는지 확인하는 것입니다. 일반적인 범위는 데이터 센터 영역, 파티션, 노드, 컬렉션 또는 행입니다. 이러한 유형의 경계를 강력한 일관성에 부과하는 데이터베이스 위에 프로그래밍하는 경우 실수로 Pandora의 상자를 다시 열지 않도록 이러한 경계를 기억해야합니다.

아래는 일관성의 예이지만 한 세트 내에 보장됩니다. 다음 예제에는 세 가지 세트가 포함되어 있습니다. 하나는 플레이어 용, 하나는 대장장이 (즉, 플레이어의 아이템을 수리하는 대장장이), 다른 하나는 항목을위한 세트를 포함합니다. 각 플레이어와 각 대장장이에는 아이템 컬렉션의 항목을 가리키는 ID 목록이 있습니다.

두 플레이어 (예 : Brecht에서 Robert까지) 사이의 방패를 교환하려면 여전히 컬렉션에 있기 때문에 모든 것이 괜찮으므로 거래는 여전히 보장 된 일관성의 범위 내에 있습니다. 그러나 Robert의 검이 대장장이에서 수리되어 회수하고 싶다면 어떻게해야합니까? 그런 다음 거래는 두 세트, 즉 대장장이 세트와 플레이어 세트에 걸쳐 있으며 취소됩니다. 이 제한은 일반적으로 MongoDB와 같은 문서 데이터베이스에서 찾을 수 있습니다. 그런 다음 제한 사항에 대한 창의적인 솔루션을 찾으려면 프로그래밍 방법을 변경해야합니다. 예를 들어, 항목의 위치를 ​​항목 자체로 인코딩 할 수 있습니다.

물론 실제 게임은 복잡합니다. 플레이어가 아이템을 소유 할 수 있도록 바닥에 품목을 떨어 뜨리거나 시장에 배치 할 수 있지만 플레이어의 인벤토리에서는 반드시 아닙니다. 상황이 더욱 복잡해지면 이러한 해결 방법은 기술의 깊이를 크게 증가시키고 데이터베이스의 보장 된 범위 내에서 유지하도록 코드를 변경하는 방법을 변경합니다.

결론적으로

데이터베이스 동작이 기대에 맞지 않을 때 발생할 수있는 다양한 문제의 예를 보았습니다. 일부 상황은 언뜻보기에 사소한 것처럼 보일 수 있지만, 특히 시스템이 확장 될 때 개발자 생산성에 큰 영향을 미칩니다. 더 중요한 것은 예측할 수없는 보안 취약점에 취약하게 해줍니다. 이로 인해 응용 프로그램의 명성에 돌이킬 수없는 손상이 발생할 수 있습니다.

우리는 여러 수준의 일관성에 대해 논의했지만 이제는 이러한 예를 보았으므로 함께합시다.

또한 이러한 정확성 보증에는 경계가있을 수 있습니다.

마지막으로, 우리는 몇 가지 예외와 일관성 보장 만 언급했으며 실제로 더 많은 것이 있음을 인식하십시오. 관심있는 독자에게는 Martin Kleppman의 디자인 데이터 집약적 응용 프로그램을 적극 권장합니다.

우리는 제한없이 강력한 일관성 데이터베이스를 선택하는 한 더 이상 관리 할 필요가없는 시대에 살고 있습니다. Calvin (FAUNADB) 및 Spanner (Google Spanner, FoundationDB)와 같은 새로운 접근 방식의 출현 덕분에 이제는 대기 시간을 매우 낮은 대기 시간을 제공하고 각 경우에 예상대로 작동 할 수있는 다중 지역 분산 데이터베이스가 있습니다. 그렇다면 왜 여전히 발에 자신을 촬영하고 이러한 보증을 제공하지 않는 데이터베이스를 선택할 위험이 있습니까?

이 시리즈의 다음 기사에서는 개발자 경험에 미치는 영향을 다룰 것입니다. 개발자에게 일관성이 중요한 것을 설득하기가 어려운 이유는 무엇입니까? 스포일러 : 대부분의 사람들은 필요성을보기 위해 직접 경험해야합니다. 그러나 "오류가 있으면 응용 프로그램 오류 또는 데이터 오류입니까? 어떻게 알 수 있습니까?" 데이터베이스의 제한이 오류 또는 잘못된 사용자 경험으로 나타나면 데이터베이스의 한계를 해결해야하며, 이는 확장 할 수없는 비효율적 인 접착 코드로 이어질 수 있습니다. 물론, 그때까지 당신은 많은 돈을 투자했고 그것이 너무 늦었다는 것을 깨달았습니다.

기사 시리즈

1. 왜 신경 쓰야합니까?
2. 어떤 문제가 발생할 수 있습니까?
3. 새로운 기술 채택의 장벽은 무엇입니까?
4. 새로운 알고리즘은 어떻게 도움이됩니까?

위 내용은 일관된 백엔드 및 UX : 무엇이 잘못 될 수 있습니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!