데이터 유효성 검사는 시스템의 핵심 원칙이 '스키마 없는' 아키텍처를 중심으로 이루어지기 때문에 NoSQL 기술에서 다루기에 흥미로운 주제입니다. 수년 동안 SQL과 스키마는 애플리케이션 데이터를 제어하여 데이터베이스 내부 정보의 적합성을 보장해 왔습니다. 이러한 제한은 개발 시간을 늦춤으로써 대부분의 애플리케이션의 현대화를 방해했습니다.
그럼에도 불구하고 애플리케이션의 밑에 있는 정보를 관리하고 검증해야 합니다. 이를 염두에 두고 Couchbase를 사용하면 어떻게 이를 달성할 수 있을까요?
스키마가 없는 아키텍처의 유연성은 통신 지점의 수가 방대한 센서 및 엣지 디바이스 상호 작용과 같은 여러 소스에서 오는 정보의 구조를 적용하기가 더 어렵게 만듭니다. 이를 달성하는 방법은 다음과 같습니다. 데이터베이스 자체 내 데이터 유효성 검사를 사용하여 카우치베이스 이벤트 서비스를 사용합니다. 이 서비스는 그 자체로 매우 강력하고 유연하여 관리자가 문서에 대한 유효성 검사의 세부 사항과 그에 따른 조치를 제어할 수 있습니다.
이 블로그 게시물에서는 이벤트 서비스를 사용하여 클러스터에 있는 정보의 유효성을 검사하는 예제를 안내합니다. 보시다시피 이를 구축하는 방법에는 여러 가지가 있지만 우선 한 가지 방법만 집중적으로 살펴보겠습니다.
NoSQL 기본 사항
모든 데이터베이스의 중심에는 우리가 저장하고자 하는 실제 정보인 데이터가 있습니다. NoSQL을 도입하기 전에는 데이터를 시스템에 삽입했지만, 개발자나 DBA가 정의한 구조를 따라야 했습니다. DBA는 정규화 데이터 중복을 줄이기 위해 6번째 정규식까지 정보를 제공합니다.. 이 전체 구조는 일반적으로 스키마로 알려져 있으며 정보의 무결성을 검증하고 기록 품질 시스템을 보장하며 진실의 원천이 되는 데 매우 유용합니다.
이러한 장점에도 불구하고 스키마 기반 아키텍처에는 몇 가지 단점이 있었는데, 주로 애플리케이션이 더 높은 수준에서 운영되기 시작하고 기업이 더 빠르게 혁신하기 시작할 때 도입되었습니다. 데이터 저장에 대한 구조화된 접근 방식은 개발 속도를 늦추기 시작했고 스키마 변경은 귀찮은 일이 되었습니다.
사용자가 원하는 모든 정보를 저장할 수 있고 혁신적인 개발이 가속화될 수 있도록 하는 스키마-라스 접근 방식이 우선시되기 시작한 곳입니다.
SQL이지만 NoSQL
보다 유연하고 민첩한 데이터베이스로의 전환에도 불구하고 새로운 접근 방식에서는 이전 모델의 일부 속성이 요구되며, 데이터 유효성 검사는 이러한 주제 중 하나입니다. Couchbase는 최근 릴리스에서 SQL과 NoSQL 기술 간의 격차를 해소하기 위해 상당한 변경 사항을 적용했습니다.
범위 및 컬렉션은 다음과 같습니다. 를 출시하여 논리적 조직과 멀티테넌시 사용 사례의 문을 열었습니다. 이를 통해 유연한 개발 관행을 핵심으로 유지하면서 스키마에서 스키마 없이 데이터를 매핑할 수 있었습니다.
ACID 보증 제공 의 또 다른 큰 진전은 v6.5.1에서 트랜잭션 워크로드의 관련 없는 데이터에 대해 전부 아니면 전무의 의미를 보장하는 것이었습니다.
데이터 유효성 검사 는 이 주제와 함께 나오는 또 다른 주제입니다. 스키마를 적용할 수 없는 경우 데이터베이스의 정보를 어떻게 평가할 수 있을까요? 스키마 접근 방식을 보완하는 이전 기능과 마찬가지로, 이 기능을 사용할지 여부를 선택할 수 있는 기능은 유용합니다. 하지만 이 기능을 애플리케이션 자체의 기본 기능에 통합할 필요는 없습니다.
5G 네트워크와 모바일/엣지 디바이스가 확산됨에 따라 데이터 거버넌스 및 관리의 필요성이 여전히 존재할 가능성이 있습니다. 카우치베이스의 도구를 활용하면 애플리케이션이나 데이터베이스 노드의 성능에 영향을 주지 않으면서도 이 검증을 쉽고 완벽하게 제어할 수 있는 방법을 제공할 수 있습니다.
여러 애플리케이션 소스를 사용하는 엣지 컴퓨팅
서버에서 유효성 검사를 수행하는 재미있는 방법을 살펴보기 전에 사용 가능한 다른 옵션에 대해 논의해 보겠습니다. 애플리케이션 수준에서의 유효성 검사는 아마도 가장 먼저 떠오르는 생각일 것입니다. 정보가 저장하기에 적합한지 확인하려면 문서를 데이터베이스에 삽입하기 전에 확인하면 어떨까요? 시스템에서 수집하기 전에 데이터에 애플리케이션 로직을 적용하면 시스템에서 이미 유효성을 검사하지 않은 문서는 데이터베이스에 접근하지 못하도록 보장할 수 있습니다.
이론적으로는 단일 애플리케이션이 단일 데이터 세트와 통신하는 경우.... 좋은 아이디어처럼 들립니다. 그러나 단일 데이터베이스에서 여러 데이터세트와 통신하는 여러 엣지 디바이스와 통신할 수 있는 모바일 애플리케이션 영역으로 눈을 돌리면 유지 관리가 어려워집니다. 데이터베이스에 글을 쓰는 모든 팀은 유효성 검사 로직을 일관되게 유지하고 공유해야 하며, 단일 앱 시나리오에 대한 보장이 사라지기 시작합니다.
이벤트 서비스
애플리케이션 유효성 검사 문제를 고려할 때, 동일한 결과를 다른 지점에서 얻을 수 있는 방법이 필요하며, 이것이 바로 이벤트 서비스가 등장하는 이유입니다. 잘 모르는 분들을 위해 설명하자면, 이벤트 서비스를 사용하면 데이터베이스의 데이터 변이에 대해 프로그래밍 방식으로 조치를 취할 수 있습니다. 이러한 작업은 JavaScript 이벤트 핸들러 내에 정의되며 데이터가 업데이트되거나 삭제될 때 트리거됩니다.
| 함수 온업데이트(문서, 메타) { 로그('docId', meta.id); } 함수 OnDelete(메타, 옵션) { } |
데이터가 데이터베이스에 들어온 후 이벤트 서비스에서 이 로직을 실행할 수 있으므로 이러한 기능에 애플리케이션 로직을 통합하는 데 아무런 제한이 없습니다. 정보가 삽입되거나 수정될 때마다 정보를 확인할 수 있도록 이벤트 서비스에 책임을 넘길 것입니다.
이것은 두 가지 일을 합니다:
- 여러 애플리케이션에서 유효성 검사 로직의 중복을 제거합니다.
- '유효한' 데이터로 간주되는 구성 및 유지 관리의 중앙 집중화
이제 데이터의 출처에 관계없이 이벤트 서비스를 사용해 버킷 내의 문서 필드와 값을 확인할 수 있습니다. 하지만 여전히 한 가지 고려해야 할 사항이 있습니다. 문서가 다음과 같다고 판단되면 어떻게 해야 할까요? 유효하지 않음? 애플리케이션 수준에서 유효하지 않은 문서는 검사를 통과하지 못하고 오류 또는 예외를 발생시켜 사용자에게 알려주며, 사용자는 필요한 방식으로 처리할 수 있습니다.
정보가 이미 버킷에 있기 때문에 데이터의 무결성을 손상시키지 않고 문서의 유효성에 플래그를 지정해야 합니다. 이 부분을 어떻게 처리할지는 사용자가 결정할 수 있지만, 제 예에서는 유효하지 않은 문서에 대한 기록을 별도의 컬렉션에 보관했다가 유효한 상태로 정리되면 기록을 제거할 수 있습니다.
구현
먼저 대상 데이터 세트에 이벤트 함수를 빌드해야 합니다. 이 예제에서는 사용자 컬렉션을 추가합니다. 또한 이벤트 메타데이터를 저장할 위치를 지정해야 합니다( 이벤트 문서).
마지막으로 참조할 수 있는 유효하지 않은 데이터의 위치에 대한 별칭을 정의해야 하는데, 이를 위해 Users_Invalid 컬렉션.
구조가 생성되면 다음을 나타내는 무언가를 만들어야 합니다. 유효 문서에 저장합니다. 이렇게 하면 모든 새 문서를 이 문서와 대조하여 정보가 올바른지 확인할 수 있습니다. 이 예에서는 문서에 포함되어야 하는 모든 필수 필드와 유형을 나열하는 문서를 만들겠습니다. 원한다면 이것을 앞에서 설명한 스키마와 연관시킬 수 있으므로 이 문서를 Users_Schema.
| { "필드": [ { "이름": "이름", "유형": "문자열" }, { "이름": "나이", "유형": "숫자" }, { "이름": "구독자", "유형": "부울" } ] } |
다음으로 생성할 것은 유효성 검사 로직입니다. 이벤트는 소스 컬렉션에 문서 변경이 있을 때마다 로직을 실행합니다, 사용자. 문서에 관련 스키마 문서가 연결되어 있는지 확인합니다. 그렇다면 모든 필드 및 값 유형을 확인하고 참조 중인 문서와 비교합니다. 필드가 존재하지 않거나 유형이 예상과 일치하지 않는 필드가 있으면 Invalid_Users 컬렉션.
스크립트 하단에는 로직이 유효한 결과를 반환하면 레코드를 삭제하려고 시도하는 조건이 있습니다. 문서가 정리되거나 유효한 상태로 수정되면 유효하지 않은 레코드에서 제거됩니다.
| 함수 온업데이트(문서, 메타) { 로그('docId', meta.id); var 스키마, 유효, 이유 //스키마 문서 가져오기 스키마 = inv[doc.type + '_schema'] 이유 = ” 유효 = true //필드 반복 에 대한(const 필드 의 스키마.필드) { //필드가 존재하는지 확인 만약 (필드.이름 in doc) { //필드 유형이 올바른지 확인 만약 (typeof doc[field.name] == field.type) { 유효 = true } else { 이유 = '잘못된 필드 유형: ' + 필드.이름 + '. 예상: ' + field.type + '. 실제: ' + typeof doc[field.name] 유효 = false break } } else { 이유 = '필드: ' + 필드.이름 + ' 존재하지 않습니다. 유효 = false break } } 만약 (유효 ==) true){ 삭제 inv[meta.id] } else { var docContent = { "id": meta.id, "reason": 이유 } inv[meta.id] = docContent } } |
이제 테스트하기만 하면 됩니다. 사용자 문서에 잘못된 필드/유형이 있는 레코드가 생성되었는지 확인하고 Invalid_Users 컬렉션'. 유효하지 않은 문서를 수정하고 기록이 제거되었는지 확인합니다. 이렇게 하면 저장 시점 이후 비동기 데이터 유효성 검사를 간단한 3단계로 수행할 수 있습니다.
더 나아가...
아시다시피 이것은 매우 간단한 예시이며, 제가 JavaScript를 더 효율적으로 작성할 수 있었을 것이라는 데는 의심의 여지가 없습니다. 하지만 버킷 내의 모든 정보를 스키마라고 할 수 있는 것에 대해 유효성을 검사하고 정보의 무결성을 유지하면서 그 과정에서 데이터가 손실되지 않도록 보장할 수 있었습니다.
이 접근 방식은 제가 따르고 싶었던 방식이었지만 여러 가지 방법으로 수정하고 확장할 수 있습니다...
- 필드의 실제 값 검증(예: 나이는 1~100 범위여야 합니다... 등)
- 컬렉션에서 문서를 완전히 제거하기
- 전체 문서를 컬렉션 밖으로 옮기기
- cURL을 통해 외부 서비스로 알림 보내기(아마도 이메일 응답?)
- 보강을 통해 유효하지 않은 데이터를 자율적으로 수정하는 추가 로직 작성하기
이 블로그 게시물에서는 몇 가지 사항을 설명했습니다:
- 저장 시점 이후의 비동기 데이터 유효성 검사
- 이벤트 서비스 전체의 힘
다시 원점으로 돌아가서, SQL과 NoSQL 기술 간의 격차를 해소하는 것은 아키텍처의 변화가 아니라 한때 근본적인 구현을 위한 도구로서 점점 더 보편화되고 있습니다.
