애플리케이션을 만들다 보면 사용자가 일부 콘텐츠를 삭제하고 싶지만 데이터가 이전에 존재했었다는 사실을 알아야 하는 상황이 종종 발생합니다.
메시징 앱을 구축한다고 가정해 봅시다. 사용자에게 삭제된 대화를 복원할 수 있는 기회를 주고 싶을 수 있습니다.
따라서 누군가 대화를 삭제하려고 할 때 단순히 Couchbase에서 문서를 삭제하는 것 외에 다른 조치를 취해야 합니다. 대신 JSON 본문에서 해당 문서를 비라이브 문서로 식별하는 플래그를 사용할 수 있습니다. 예를 들어
|
1 2 3 |
{ "deleted": true } |
그 아래에 GSI 인덱스를 생성하여 모든 항목에 효율적으로 액세스할 수 있습니다. 삭제됨 대화:
|
1 |
CREATE INDEX deletedmsgs ON `conversations`(deleted); |
그런 다음 앱의 UI에서 삭제된 대화의 보기를 채우려면 N1QL 쿼리 예를 들어
|
1 |
SELECT * FROM `conversations` WHERE deleted = true; |
지금까지는 모든 것이 매우 분명해 보입니다.
기존 데이터 집합에 추가하기
이제 막 애플리케이션에 이 기능을 도입한 경우라면 어떻게 될까요? 이미 수천 개의 대화가 있는데 그 대화들의 기본 문서에는 삭제됨 플래그.
이번 기회에 N1QL의 누락됨. 맞지만 제가 제안하는 것과는 약간 다른 생각을 하고 계실 수도 있습니다.
당신 coulc 계정이 없는 문서에 대한 삭제됨 플래그를 변경하여 N1QL 쿼리를 다음과 같이 변경합니다:
|
1 |
SELECT * FROM `conversations` WHERE deleted = true OR deleted IS MISSING; |
좀 더 현실적으로 표현하기 위해 관련자를 기준으로 쿼리를 필터링할 수도 있습니다:
|
1 |
SELECT * FROM `conversations` WHERE sender = user123 AND deleted = true OR deleted IS MISSING; |
이렇게 하면 작업을 수행할 수 있지만 가장 효율적인 방법은 아닙니다.
OR 상황에서 N1QL의 MISSING 키워드를 도입한 다음, N1QL이 전체 문서 스캔을 시작하도록 설정합니다. 우리의 쿼리는 모든 문서에 삭제된 JSON 키가 있는지 확인하도록 N1QL에 요청하는 것입니다. 인덱스는 다음과 같은 문서에만 도움이 됩니다. 삭제됨 키가 없는 문서에는 색인을 생성하지 않기 때문에 존재하지 않습니다.
대신 이 경우에는 누락된 모든 문서를 반환하는 일회성 쿼리를 실행하는 것이 좋습니다. 삭제됨. 그런 다음 각 항목을 검토하여 다음을 포함하도록 업데이트할 수 있습니다. 삭제됨 = 거짓 이제 모든 문서가 효율적인 인덱스에 저장됩니다.
쿼리가 조금 더 오래 걸리더라도 괜찮습니다. 백그라운드 데이터 관리 작업의 일부로 실행되므로 사용자 중 누구도 이를 인지하지 못할 것입니다. 모든 문서에 대해 이 작업을 실행하고 나면 더 이상 누락 를 사용자 대면 쿼리에 넣으면 모든 대화 문서가 다음 중 하나라는 것을 알 수 있기 때문입니다. 삭제됨: true 또는 삭제됨: 거짓.
스키마 버전 대신 사용
스키마 버전 관리를 유지하면 MISSING을 아예 사용하지 않을 수 있습니다:
|
1 2 3 |
{ "schema": "1.2.3" } |
새로운 스키마 버전이 다음과 같은 기능을 제공한다고 가정하면 삭제됨 플래그가 2.0.0이면 백그라운드 관리자 작업은 스키마 버전이 2.0.0보다 오래된 모든 문서를 찾은 다음 업그레이드 프로세스를 통해 실행할 수 있으며, 그 중 일부가 삭제됨 플래그.
