단일 실패가 대량 작업에 실패해야합니까?

API에서 작업 중이며 일련의 ID를 허용하는 대량 삭제 작업이 있습니다.

["1000", ..., "2000"]

필자는 적합하다고 생각되는 삭제 작업을 자유롭게 구현할 수 있었기 때문에 모든 것을 트랜잭션 처리하기로 결정했습니다. 즉, 단일 ID가 유효하지 않으면 전체 요청이 실패합니다. 이 모드를 엄격 모드 라고 합니다.

try{
savepoint = conn.setSavepoint();

for(id : IDs)
    if( !deleteItem(id) ){
        conn.rollback(savepoint);
        sendHttp400AndBeDoneWithIt();
        return;
    }

conn.commit();
}

대안 (소프트웨어 스위트의 다른 곳에서 구현)은 백엔드에서 수행 할 수있는 작업을 수행하고 어레이에서 오류를보고하는 것입니다. 소프트웨어의 해당 부분은 더 적은 요청을 처리하므로 응답은 이론적으로 거대한 배열이 아닙니다.

리소스가 부족한 서버에서 최근에 발생한 버그로 인해 코드를 다시 살펴 보았으므로 이제 원래 결정에 의문을 제기하고 있습니다. 그러나 이번에는 모범 사례가 아닌 비즈니스 요구에 더 많은 동기를 부여 받았습니다. 예를 들어, 전체 요청에 실패하면 사용자는 다시 시도해야하지만 여러 항목이 삭제되면 사용자는 작업을 완료 한 다음 관리자에게 나머지 작업을 수행하도록 요청할 수 있습니다 (버그 수정 작업 중) !). 이것은 허용 모드입니다.

이 문제에 대한 지침을 온라인에서 찾아 보았지만 빈손으로 왔습니다. 그래서 나는 당신에게 왔습니다.이 성격의 대량 작업에서 가장 기대되는 것은 무엇입니까? 더 엄격하게해야합니까, 아니면 더 관대해야합니까?

삭제 엔드 포인트의 '엄격한'또는 '좋은'버전을 수행하는 것은 좋지만 사용자에게 발생한 상황을 명확하게 알려야합니다.

이 엔드 포인트에서 삭제 조치를 수행하고 있습니다. 아마 DELETE /resource/bulk/또는 유사한 것. 나는 까다 롭지 않다. 여기서 중요한 것은 엄격하거나 착한 결정을 내리더라도 무슨 일이 있었는지 정확하게보고해야한다는 것입니다.

예를 들어, 내가 작업 한 API에는 DELETE /v1/student/대량 ID를 허용 하는 엔드 포인트가 있었습니다 . 우리는 테스트하는 동안 정기적으로 요청을 보내고 200응답을 얻고 모든 것이 잘되었다고 가정합니다. 나중에 목록의 모든 사람이 데이터베이스에 여전히 있거나 (비활성으로 설정되어 있음) 오류로 인해 실제로 삭제되지 않았 음을 알게되었습니다. GET /v1/student우리가 예상하지 못한 데이터를 다시 얻었 기 때문에 앞으로 전화를 걸었습니다 .

이에 대한 해결책은 삭제되지 않은 ID로 응답에 본문을 추가 한 이후 업데이트로 제공되었습니다. 이것은 내 지식으로는 일종의 모범 사례입니다.

결론은, 무엇을 하든지 최종 사용자에게 무슨 일이 일어나고 있는지, 왜 그런 일이 발생했는지 알려주는 방법을 제공해야합니다. IE, 엄격한 형식을 선택하면 응답은입니다 400 - DELETE failed on ID 1221 not found. 우리가 '좋은'버전을 골랐다면, 그것은 207 - {message:"failed, some ids not deleted", failedids:{1221, 23432, 1224}}잘못된 것일 수 있습니다 .

행운을 빕니다!

하나는 엄격하고 허용 적이어야합니다.

일반적으로 벌크로드는 2 단계로 분류됩니다.

• 확인
• 로딩

유효성 검사 단계에서 모든 레코드는 데이터 사양의 요구 사항을 충족하는지 엄격히 검토합니다. 단 몇 초 만에 10 만 개의 레코드를 쉽게 검사 할 수 있습니다. 유효한 레코드는로드 할 새 파일에 배치되고 유효하지 않은 레코드는 플래그가 지정되어 제거되며 일반적으로 별도의 파일 (건너 뛰기 파일)에 저장됩니다. 그런 다음 유효성 검사에 실패한 레코드에 알림이 전송되므로 문제 해결 목적으로 검사 및 진단 할 수 있습니다.

데이터의 유효성이 검사되면로드됩니다. 일반적으로 장기 실행 트랜잭션을 피할 수있을만큼 충분히 크거나 실패가있는 경우 복구가 더 쉬워집니다. 배치 크기는 데이터 세트의 크기에 따라 다릅니다. 하나에 1000 개의 레코드 만있는 경우 하나의 배치가 정상입니다. 여기서는 장애가 다소 허용 될 수 있지만 실패한 배치 임계 값을 설정하여 전체 작업을 중지하려고 할 수 있습니다. [N] 배치가 실패하면 서버가 다운되었거나 이와 유사한 경우 전체 작업이 중지 될 수 있습니다. 일반적으로이 시점에서 데이터가 이미 검증 되었기 때문에 실패가 없지만 환경 문제 또는 기타 문제로 인해 실패한 배치를 다시로드하면됩니다. 이렇게하면 복구가 조금 더 쉬워집니다.

단일 실패가 대량 작업에 실패해야합니까?

이에 대한 정식 답변은 없습니다. 사용자의 요구와 결과는 검토되어야하고, 절충점은 평가되어야합니다. OP는 필요한 정보를 제공했지만 다음은 진행 방법입니다.

질문 1 : '개인 삭제가 실패하면 사용자에게 어떤 영향이 있습니까?'

대답은 나머지 디자인 / 구현 된 행동을 주도해야합니다.

OP 종류의 명시된대로 단순히 사용자가 예외를 발견하고 문제 티켓을 열지 만 영향을받지 않으면 (삭제되지 않은 항목은 후속 작업에 영향을 미치지 않음) 자동 알림으로 허용됩니다. 당신에게.

사용자가 계속 진행하기 전에 실패한 삭제를 해결해야하는 경우 엄격하게 사용하는 것이 좋습니다.

사용자에게 옵션을 제공하는 것 (예를 들어, 기본적으로 엄격하거나 허용되는 기본적으로 무시-실패 플래그)은 가장 사용자 친화적 인 접근 방법 일 수 있습니다.

질문 2 : '데이터 저장소에 삭제되지 않은 항목이 남아있는 후속 작업을 수행하는 경우 데이터 일관성 / 일관성 문제가 있습니까?'

다시, 그 대답은 최고의 디자인 / 행동을 이끌어 낼 것입니다. 예-> 엄격, 아니요-> 허용, 어쩌면-> 엄격 또는 사용자 선택 (특히 사용자가 결과를 정확하게 판단 할 수있는 경우)

나는 이것이 확장 성을 원하는지 아닌지에 달려 있다고 생각합니다. ID가 많지 않다면 너무 중요하지 않습니다. 백만 개의 ID를 가지고 있거나 더 나은 ID를 얻지 않으려는 경우 절대로 ID가 발생하지 않을 것이라고 확신하지 못하면 1 시간 동안 유효하지 않은 ID로 인해 ID를 완전히 재설정하기 위해 ID를 삭제하는 데 1 시간을 소비 할 수 있습니다.

여기서 중요한 점 은 대량의 항목을 삭제 한다는 의미 입니다.

이 ID는 논리적으로 관련이 있습니까, 아니면 편리 성 / 성능-일괄 그룹화입니까?

어떻게 든 느슨하게 연결되어있는 경우, 나는 갈 것입니다 strict. 배치 모드 일 경우 (예 : 사용자가 마지막 작업 시간 동안 "저장"을 클릭 한 다음 배치가 전송 된 경우에만 해당) permissive버전으로 이동합니다 .

다른 답변에서 알 수 있듯이 : "어떻게했는지"사용자에게 정확히 알려주십시오.