알고리아 Sending And Managing Data(2-16)

Handling Concurrency with Versioning(버전 관리에서 동시성 처리)

 

https://www.algolia.com/doc/guides/sending-and-managing-data/send-and-update-your-data/in-depth/handling-concurrency-with-versioning/

Handling concurrency with versioning | Algolia

 

If you have multiple indexing processes running, one process could try to update an object at the same time as another. If this happens, your record might turn out differently than expected.

 

여러 인덱싱 프로세스가 실행 중인 경우 한 프로세스가 다른 프로세스와 동시에 개체를 업데이트할 수 있습니다. 이렇게 되면 기록이 예상과 다를 수 있습니다.

Imagine you have an ecommerce website, and your back end runs two processes to index its changes to Algolia with the partialUpdateObjects method. One process sends an update to set the stock of a product from 10 to 20, because you just received ten new items in a shipment. Simultaneously, another process sets the stock for this product from 10 to 9 because of an order that just came in.

Depending on which job wins the race condition, the stock is now either 9 or 20, even though the correct stock is 19.

당신이 전자상거래 웹사이트를 가지고 있고, 당신의 백엔드가 부분UpdateObjects 방법으로 Algolia에 대한 변경 사항을 색인화하기 위해 두 개의 프로세스를 실행한다고 가정해보자. 한 공정에서 업데이트를 보내 제품의 재고를 10개에서 20개로 설정합니다. 왜냐하면 당신은 배송에서 10개의 새 품목을 받았기 때문입니다. 동시에, 다른 공정에서 방금 들어온 주문으로 인해 이 제품의 재고를 10에서 9로 설정합니다.
어떤 직업이 경주 조건을 이기느냐에 따라 정확한 종목이 19개이긴 하지만 현재 주식은 9개 또는 20개 중 하나다.

Versioning

The first way to handle concurrency is the IncrementSet operation. It lets you update an object only if you provide a higher numerical value than already exists in the record, or a value higher than 0 if the record doesn’t exist.

A great use-case for this is adding a Unix timestamp to your records. With IncrementSet, the engine only updates your record if the timestamp you sent is more recent than the existing one. If you update in the meantime, you prevent the engine from overriding your record again; only the latest update is taken into account.

동시성을 처리하는 첫 번째 방법은 IncrementSet 작업입니다. 레코드에 이미 존재하는 것보다 높은 숫자 값을 제공하거나 레코드가 존재하지 않는 경우 0보다 큰 값을 제공하는 경우에만 개체를 업데이트할 수 있습니다.
Unix 타임스탬프를 레코드에 추가하는 것이 가장 좋은 방법입니다. IncrementSet을 사용하면 보낸 타임스탬프가 기존 타임스탬프보다 최신인 경우에만 엔진이 레코드를 업데이트합니다. 그 사이에 업데이트하면 엔진이 레코드를 다시 재정의하지 못하게 됩니다. 최신 업데이트만 고려됩니다.

Optimistic locking

Another way to handle concurrency is with the IncrementFrom operation. It lets you update an object only if you provide the current version of the object, or 0 if the record doesn’t exist.

A typical use-case is when you perform a read-modify-write sequence:

동시성을 처리하는 또 다른 방법은 IncrementFrom 작업을 사용하는 것입니다. 개체의 현재 버전을 제공한 경우에만 개체를 업데이트하고 레코드가 없는 경우 0을 업데이트할 수 있습니다.
일반적인 사용 사례는 읽기-수정-쓰기 시퀀스를 수행하는 경우입니다.

• you read an object from your index,
• you make the changes you want to make,
• you provide the IncrementFrom operation with the old value of your versioning attribute.

-색인에서 객체를 읽으면
-당신이 원하는 변화를 만들고
-IncrementFrom 작업에 버전 특성의 이전 값을 제공합니다.

 

With this approach, the engine only updates your record if the value from your IncrementFromoperation matches the current value currently in the record, and increments it. If another process incremented this value in the meantime, the engine ignores the update.

The engine doesn’t provide feedback when it rejects an update because of versioning or optimistic locking. You have to wait for the indexing operation to complete, then fetch the object to compare it to the desired result.

 

이 접근 방식에서는 EncrementFrom 작업의 값이 현재 레코드에 있는 값과 일치하고 증가하는 경우에만 엔진이 레코드를 업데이트합니다. 그동안 다른 프로세스가 이 값을 증가시킨 경우 엔진은 업데이트를 무시합니다.
버전 관리 또는 낙관적 잠금으로 인해 엔진이 업데이트를 거부할 때 피드백을 제공하지 않습니다. 인덱싱 작업이 완료될 때까지 기다린 다음 원하는 결과와 비교하려면 개체를 가져와야 합니다.