Amazon과 같은 회사는 데이터베이스 계층에 액세스하는 병목 현상을 어떻게 방지합니까?

29

아마존 (또는 다른 대형 전자 상거래 웹 애플리케이션)과 같은 회사가 대규모 온라인 매장을 운영하고 있으며 창고에 물리적 품목의 수량이 제한되어 있다고 생각한다면 어떻게이를 최적화 할 수 있습니까? 단일 병목 현상? 물론 복제 할 수있는 많은 데이터베이스와로드를 독립적으로 처리하는 많은 서버가 있어야합니다. 그러나 여러 사용자가 별도의 서버에서 서비스를 받고 있고 둘 다 동일한 항목을 장바구니에 추가하려고하면 해당 항목에 남은 수량에 대해 "진실한 소스"가 있어야합니다. 최소한 단일 품목의 제품 정보에 액세스하는 모든 사용자가 동일한 데이터베이스를 직렬로 쿼리해야한다는 의미는 아닙니까?

분산 컴퓨팅을 사용하여 대형 매장을 운영하고 재고 정보가 포함 된 단일 DB에서 큰 병목 현상을 발생시키지 않는 방법을 알고 싶습니다.

web-applications scalability distributed-computing

— mattgmg1990
소스

(질문에 여전히 관련) 중반 2000 년대 아마존 아키텍처 : highscalability.com/amazon-architecture

— Joeri Sebrechts

비행기 내 좌석 (예 : 쇼핑 카트의 한 품목이 비행기, 렌터카, 호텔 숙박 및 항공편 등을 나타내는 패키지 휴가) 및 여러 다른 기관이 각 사이트에서 동일한 좌석을 판매하는 경우에도 마찬가지입니다. . 솔루션은 무수하지만 모두 어딘가에 각 부분의 실제 상태를 갖는 하나의 최종 진리 데이터베이스를 갖습니다.

— RemcoGerlich

1

@RemcoGerlich : "하나의 최종 진실 데이터베이스"라고 말하는 방식 은 커다란 신성한 데이터베이스 가있는 단일 머신을 생각하게 합니다. 실제로 중요한 데이터는 모든 트랜잭션이 한 번에 여러 서버에 도달하여 모든 데이터베이스가 항상 동기화되도록하는 것입니다.

— Arseni Mourzenko

27

그러나 여러 사용자가 별도의 서버에서 서비스를 받고 있고 둘 다 동일한 항목을 장바구니에 추가하려고하면 해당 항목에 남은 수량에 대해 "진실한 소스"가 있어야합니다.

실제로는 아닙니다. 두 가지 오류 사례 모두 비용이 많이 들지 않는 비즈니스 솔루션이 있기 때문에 100 % 완벽한 기술 솔루션이 필요한 문제는 아닙니다.

사용자에게 상품이 매진되었다고 잘못 알리면 판매가 중단됩니다. 매일 수백만 개의 상품을 판매하는 경우 하루에 한두 번 정도 발생하면 소음이 없어집니다.
주문을 수락하고 처리하는 동안 품목이 부족한 것으로 판명되면 고객에게 알리고 재입고가 가능할 때까지 기다리거나 주문을 취소하도록 선택할 수 있습니다. 약간 성가신 고객이 있습니다. 주문의 99.99 %가 정상적으로 작동 할 때 큰 문제는 아닙니다.

사실, 나는 최근에 두 번째 사례를 직접 경험했기 때문에 가설은 아닙니다. 그것이 일어나고 아마존이 처리하는 방식입니다.

이론적으로 해결하기 어려운 문제가있을 때 자주 적용되는 개념입니다 (성능, 최적화 등). 대부분의 경우 실제로 잘 작동하는 솔루션으로 생활하고 때로는 받아 들일 수 있습니다. 장애 발생시이를 감지하고 처리 할 수있는 한 장애가 발생합니다.

— 마이클 보그 워드
소스

2

팻 Helland의 추억, 추측으로, 그리고 사과는 또한 덮여 무덤에 건물 및 보상 거래는 여기에 관련 아이디어이다.

— Derek Elkins

1

당신은 "정말 그렇지 않다"고 말했지만 당신이 내가 제안한 것에 동의하는 것 같습니다. 당신이 말하는 것은 사용자가 탐색 중일 때 나머지 인벤토리에 대해 캐시 된 근사값을 제공하지만 실제로 구매를 완료하려고 할 때만 나머지 인벤토리를 줄이기 위해 쓰기를 수행한다는 것입니다. 해당 값을 포함하는 DB는 각 트랜잭션을 원자 적으로 실행하며 두 명의 사용자가 동시에 시도하면 두 번째 사용자에게 오류 메시지가 표시됩니다. 따라서 결국 "진리"를 포함하는 단일 머신에는 하나의 정수가 있습니다.

— mattgmg1990

2

@ mattgmg1990 : 맞습니다. 결국 어딘가에 "진실"을 알아야하지만 중요한 차이점은 주문 처리가 대기열에서 수행 될 수 있으므로 동시 원자 쓰기 액세스가 전혀 필요하지 않다는 것입니다. 필자의 경우 아마존 웹 사이트에서 주문을 마치고 몇 시간 후에 "오류 메시지"가 나타났습니다. 해당 품목의 공급에 문제가 있다는 주문 이메일을 받았으며 주문을 취소하거나 아무것도하지 않고 기다릴 수 있습니다. 그들이 그것을 성취하기 위해. 나는 그 품목을 즉시 필요로하지 않았기 때문에 후자를했다. 그리고 그들은 실제로 몇 주 후에 그것을 전달했다.

— Michael Borgwardt

@DerekElkins는 특히 디지털 데이터가 현실이 항상 시스템이 자동으로 알 수없는 변화를 가질 수 있기 때문에 불가피하게 불완전한 현실을 표현한다는 점에서 훌륭한 기사입니다.

— Michael Borgwardt

6

의 조합

해싱
샤딩
복제
분포
높은 페일 오버
키-값 저장소

마술은 없으며 점점 더 복잡한 상황입니다. DNS와 마찬가지로 확장이 가능합니다.

'단일 버전의 진실'은 그러한 시스템의 일부입니다. 새로운 키를 생성하는 것은 시퀀스에서 다음 숫자를 생성하는 것보다 더 복잡한 작업이됩니다. 예를 들어 다른 시퀀스가 존재합니다. 이는 분산 데이터베이스 시스템이 처리 할 수있는 복잡한 유형으로, 새로운 객체를 만들 때 다른 객체에서 사용할 수 있도록 구성 요소에 대해 여러 작업을 수행하고 필요에 따라 시퀀스가 고유해야합니다 (복합 키 등). .

— 마이클 듀란트
소스

이러한 각 개념에 대해 읽었지만 계속 유지해야 할 부분은 남아있는 인벤토리의 특정 시나리오입니다. 5 권의 책이 남아 있고 여러 서버에서 요청을하는 사용자가 남은 인벤토리를 쿼리하여 두 명의 사용자가 동시에 마지막 책을 얻을 수 없도록 할 때 항상 단일 데이터베이스 테이블로 확인합니까? 위의 특정 용도는 전체 시스템 속도를 늦추지 않고 복제가 여전히 여러 DB 인스턴스에서 유용 할 수 있습니까?

— mattgmg1990

조금 더 추가했습니다. 이 형식과 관련된 모든 복잡성을 실제로 설명 할 수는 없습니다. 죄송합니다.

— Michael Durrant

1

일부 사람들 만 특정 책에 관심이 있습니다. 즉, 책은 비교적 작은 적재량의 샤드로 처리 할 수 있습니다.

— Basilevs December

6

시스템을 설명하는 시나리오에서 다른 사람이 마지막 사본을 구입했다고 사용자에게 사과해야한다고 생각합니다. 나는 이것이 때때로 발생한다고 상상한다.

— Matthew James Briggs

1

나는 남은 책이 5 권 밖에 안된다고 생각 한다 .

— mouviciel

5

'최종 품목 재고'문제가 다음과 같은 방식으로 해결되었습니다.

모든 재고 레벨을 매일 업데이트하고 임계 값 레벨에 따라 주문시 또는 재고 부족 범주로 제품을 높음, 낮음으로 표시하십시오.

분명히 문제가되는 '낮은 재고'항목

재고 수준이 높은 품목

재고 수준을 확인하지 않아도됩니다. 그냥 주문하십시오

재고 수준이 낮은 품목

'Last few left!'를 탐색 할 때 사용자에게 경고하십시오. 그들이 지불하려고 할 때, 재고 수준을 확인하고 감소시킵니다. 재고가 없으면 품목 상태를 업데이트하십시오.

이렇게하면 '낮은 재고'품목에 대해서만 데이터베이스에 도달 할 수 있으며 고객이 구매 프로세스를 훨씬 더 잘 수행 할 때만 그렇게합니다. 비용은 일부 고객이 구매를 완료 할 수 없다는 것입니다.

그러나 대부분의 경우 '재고 없음'은 실제로 다른 배송을 기다리는 것을 의미하므로 주문을 수락하고 경고 메시지를 표시하거나 배송 옵션을 제한하고자 할 수 있습니다. 그래서 그 고객들은 길을 잃지 않았습니다.

판매와 같은 높은로드 시간 동안 재고 확인을 끄고 나중에 고객에게 전자 메일을 보낼 수도 있습니다. '죄송합니다. X가 부족합니다. Y를 원하십니까?'

본질적으로 전자 상거래 플랫폼의 목표는 데이터베이스에서 읽지 않습니다. 항상 캐시 된 페이지를 제공하고 클라이언트 측에서 모든 작업을 수행하십시오.

— 이완
소스

2

이 비디오에서 Martin Fowler는 NoSQL 데이터베이스에 대해 설명합니다.

https://www.youtube.com/watch?v=qI_g07C_Q5I

요점 (어딘가에 있음) 중 하나는 아마존과 같은 곳에서 실제로 주문 가능한지 "확인"하지 않고 주문을 수락함으로써 99 %의 사람들을 행복하게하고, "죄송합니다. 누군가 당신을 이길 것 같습니다."

다시 말해서, 당신이 묘사 한 시나리오에 대한 실제 처리는 없으며, 아마존이 마지막으로 성공한 인벤토리를 기반으로 의심의 이점을 누리고 동시 트랜잭션이 oopsie 사이에서 미끄러 져 나가는 경우 이점을 얻습니다.

(Btw, NoSQL에 대해 궁금하다면 좋은 비디오입니다)

— 표백제
소스