IBM Cloudant 동영상 스크립트 소개

IBM Cloudant 오신 것을 환영합니다. 이 과정은 17개의 비디오 시리즈로 구성되어 있으며, IBM Cloudant 대한 개요를 제공합니다.

본 동영상은 파트 1 - IBM Cloudant 개념입니다.

IBM Cloudant는 IBM Cloud®에서 서비스로 실행되는 데이터베이스입니다. 해당 작업은 애플리케이션의 데이터를 안전하게 저장하고 이를 빠르고 효율적으로 검색할 수 있도록 하는 것입니다. IBM Cloudant의 주요 기능은 다음 목록에 표시되어 있습니다.

데이터베이스

데이터를 저장하고 검색합니다. 더 구체적으로는 JSON 문서 저장소입니다. JSON은 JavaScript에서 제공되며 범용 파일 형식으로 간단한 오브젝트를 나타냅니다.

"문서"

IBM Cloudant의 스토리지 단위입니다. 문서는 전부 추가, 업데이트 및 삭제됩니다.

HTTP API

HTTPS 사용하면 모든 IBM Cloudant 작업을 수행할 수 있습니다. HTTP는 월드 와이드 웹을 구동하는 프로토콜이고 IBM Cloudant는 웹용으로 빌드된 데이터베이스입니다. 대부분의 데이터베이스는 사설 네트워크에 숨겨져 있으며 액세스할 수 없습니다(일부 머신 제외). IBM Cloudant (주로) 공용 인터넷에 위치하며, 인터넷에 연결되어 있고 (그리고 그렇게 할 수 있는 권한이 있는) 사람이라면 누구나 액세스할 수 있습니다.

IBM Cloudant는 전적으로 IBM에서 작성되지 않았습니다. 이는 Apache Foundation에서 실행하는 오픈 소스 프로젝트인 Apache CouchDB를 기반으로 합니다. IBM Cloudant에서는 여러 CouchDB 컨트리뷰터를 채택하지만 Apache의 규칙에 따라 이들이 개발을 독점할 수 없습니다.

이 과정에서 확인할 수 있는 대부분은 IBM Cloudant에서와 같이 Apache CouchDB에 적용될 수 있습니다. API는 99% 동일합니다. 상이한 부분을 파악했습니다.

IBM Cloudant는 CouchDB가 "서비스대로" 실행된다고 간주할 수 있습니다. IBM Cloudant 서비스는 쉽게 배치되며 IBM 엔지니어가 연중무휴로 관리합니다. 이 서비스에는 설치할 소프트웨어도, 관리할 서버도, 이해할 구성도 없습니다. CouchDB 전문가가 아니어도 이 서비스를 사용하고 관리할 수 있습니다.

IBM Cloudant이(가) 진정한 오픈 소스 기반에 빌드되고 있으므로, 데이터 계층이 특정 플랫폼, 클라우드 또는 벤더에 종속되지 않도록 보장할 수 있습니다. IBM Cloudant을(를) CouchDB와 함께 사용하여 복제를 통해 데이터를 공유하는 하이브리드 애플리케이션을 작성할 수 있습니다.

나중에 과정을 수행하는 중에 under the hood를 보고 어떻게 IBM Cloudant 작동하는지 확인합니다. 그러나 초기에는 IBM Cloudant를 "블랙 박스"로 처리합니다.

요약하면, Cloudant는 오픈 소스 프로젝트인 Apache CouchDB를 기반으로 하며 JSON 문서를 저장합니다. 이는 HTTP API를 사용하여 액세스되며, 따라서 HTTP를 사용하는 인터넷의 모든 디바이스에서 액세스가 가능합니다(애플리케이션 코드, 웹 브라우저, IoT 디바이스 또는 모바일 전화). IBM Cloudant은(는) 여러 하드웨어 장애에서도 계속 작동할 수 있는 고가용성 관리 서비스입니다.

이 파트의 끝입니다. 다음 파트는 문서입니다.

문서 동영상 스크립트

IBM Cloudant 오신 것을 환영합니다. 이 과정은 17개의 비디오 시리즈로 구성되어 있으며, IBM Cloudant 대한 개요를 제공합니다.

이 영상은 2부입니다 - IBM Cloudant.

이전 절에서는 IBM Cloudant가 JSON 문서 저장소라는 것을 확인했습니다. 실제로 이것이 의미하는 바와 그것이 다른 유형의 데이터베이스와 비교되는 방법을 알아 봅시다.

대부분의 데이터베이스는 테이블이라고 하는 콜렉션에 데이터를 저장합니다. 여기서 각 데이터의 단위는 동일하고 고정된 열이 있는 행입니다. 각 테이블의 스키마는 미리 정의되어 있습니다. 이름, 날짜 유형, 값 제한조건 및 다른 테이블과의 관계가 신중하게 정의된 열 목록입니다. 각각의 새 레코드는 테이블에 행을 형성합니다.

IBM Cloudant는 다릅니다!

IBM Cloudant 서비스에는 여러 개의 문서가 있는 데이터베이스(테이블 대신)라고 하는 콜렉션이 포함됩니다.

이 슬라이드의 예는 전통적인 표 형식의 데이터베이스에 표현된 것과 동일한 데이터를 보여주고, 동일한 데이터가 IBM Cloudant JSON 문서로 어떻게 저장되는지를 보여줍니다.

따라서 관계형 데이터베이스 백그라운드를 갖고 있는 경우 테이블은 IBM Cloudant의 "데이터베이스"이고, 행은 "문서"입니다.

IBM Cloudant 문서는 중괄호로 시작하고 끝나며 여러 키 값 속성을 포함하는 JSON 오브젝트여야 합니다.

JSON 오브젝트의 크기는 1MB보다 작아야 하며 문자열, 숫자, 부울, 배열 및 오브젝트를 포함해야 합니다. 오브젝트 내에서 오브젝트의 중첩은 계속해서 깊이를 유지할 수 있습니다.

사용되는 키는 사용자가 원하는 대로 간단하거나 세부적일 수 있습니다.

다음 목록에는 각 데이터 유형이 어떻게 사용되는지를 보여주는 간단한 예제 문서가 포함되어 있습니다.

• 첫 번째 예제는 문자열, 부울 및 태그 배열을 저장하는 개인 오브젝트를 보여줍니다.
• 두 번째 예에서는 스토리지에 저장할 간략한 속성 이름을 표시하며 웹 사이트 클릭과 같은 웹 이벤트를 나타냅니다.
• 마지막 예에서는 문서에 자체적으로 주제가 포함되는 방법을 보여줍니다.

날짜에 대한 참고사항. JSON에는 원시 날짜 유형이 없으므로 일반적으로 날짜는 30-10-2018 또는 이와 유사한 형식으로 저장됩니다. 나중에 해당 날짜로 돌아갑니다.

이제 첫 번째 실습을 위해 www.ibm.com/cloud에 방문하십시오. 계정이 아직 없으면 IBM Cloud에 등록하십시오.

등록하면 서비스를 클릭하고 Cloudant 데이터베이스를 검색하여 새 서비스를 제공할 수 있습니다.

IBM Cloudant Lite 서비스는 사용자가 개발 중에 제한된 용량으로 IBM Cloudant를 시도할 수 있도록 무료 플랜을 제공합니다. 좀 더 상위 레벨인 Standard Plan은 애플리케이션에 대한 초당 읽기, 쓰기 및 조회 수를 지정하는 유료 서비스이며 해당 용량은 사용자를 위해 예약됩니다. 프로비저닝한 용량과 데이터 스토리지 사용량에 대해 비용을 지불합니다.

Lite 플랜은 비슷한 방식으로 운영됩니다. 프로비저닝된 적은 용량과 고정 스토리지 크기만 있지만 IBM Cloudant 서비스를 테스트하는 것이 좋습니다.

IBM Cloudant는 종종 "스키마 없는" 데이터베이스라고 하지만 이 용어를 어떻게 정의하는지는 주의해야 합니다.

IBM Cloudant 미리 스키마(필드 이름, 유형, 제약 조건, 관계)를 정의할 필요가 없다는 것은 사실입니다. 간단하게 자체 디자인의 JSON 문서를 데이터베이스에 작성할 수 있습니다.

개발자는 자신의 코드로 데이터를 설계하고 이를 JSON으로 변환하여 데이터베이스에 작성할 수 있기 때문에 이러한 유연성을 선호합니다.

데이터 모양에 대해 생각해 보는 것은 여전히 중요합니다. 특히 나중에 확인할 수 있듯이 조회하고 인덱싱하는 방법의 측면에서는 특히 중요합니다.

데이터 설계는 여전히 필요하지만, 엄격히 말하면 데이터베이스가 스키마에 대해 알 필요는 없습니다.

미국 대통령 데이터베이스를 만들고 싶다고 가정해 봅시다. 간단하게 앱에 "모델"을 만들고 이를 JSON으로 변환하여 데이터베이스에 작성할 수 있습니다. 이 경우 일반적인 CouchDB 규칙을 사용합니다. "유형" 필드는 문서의 데이터 유형을 나타냅니다.

이후에 더 많은 데이터를 "스키마"에 추가할 경우 IBM Cloudant에서 반대 없이 새 오브젝트를 데이터베이스에 간단하게 작성할 수 있습니다. "주소" 오브젝트를 다음 문서에만 추가하도록 결정할 수 있습니다.

• 지금부터 작성된 문서
• 주소를 보유한 문서만

즉, 같은 유형의 문서에는 필드가 있거나 없을 수 있습니다.

데이터베이스의 스키마는 시간 경과에 따라 애플리케이션의 요구에 맞게 발전할 수 있습니다. 데이터베이스에 스키마 변경에 대해 (반드시) 알릴 필요는 없습니다. 새 형식으로 새 문서를 작성하십시오.

동일한 데이터베이스에 다중 문서 "유형"을 저장할 수도 있습니다. 이 경우 사용자, 서적 및 장소는 동일한 데이터베이스에 있습니다. "유형" 필드로 인해 무엇이 무엇인지 알 수 있습니다(이 필드는 규칙이며 IBM Cloudant에 어떠한 의미도 없음).

이 구성의 대안은 세 개의 데이터베이스 사용자, 서적 및 공간을 갖춘 각 데이터 유형을 자체 데이터베이스에 보관하는 것입니다. 두 접근 방법 모두 가능합니다. 유형 전반에 조회를 수행해야 하거나 모든 데이터베이스 유형을 함께 복제해야 하는 경우 동일한 데이터베이스에 여러 유형을 함께 사용하도록 선택할 수 있습니다. 그렇지 않으면 별도의 데이터베이스 접근 방식이 좀 더 적합할 수 있습니다.

요약하면, IBM Cloudant는 "스키마 없음" 이지만 이 사실로 최상의 성능을 얻기 위해 세부적인 데이터 디자인을 수행해야 하는 필요성이 제거하지 않습니다.

이러한 팁은 특히 관계형 데이터베이스 경험이 있는 경우 관련됩니다.

• 결합을 계획하지 않음 - IBM Cloudant 하나의 API 호출에서 검색될 수 있도록 문서에는 해당 오브젝트에 대해 필요한 모든 내용이 포함되어야 합니다.
• 정규화는 JSON 저장소에서 창 밖으로 이동하므로 데이터를 보다 효율적으로 검색할 수 있는 경우에는 일부 반복되는 값을 허용할 수 있습니다.
• 문서 크기의 한계는 1MB이지만 문서의 크기는 더 작아야 합니다. 일반적으로 작은 숫자의 KB입니다.
• 애플리케이션이 "쓰기 전용" * 디자인 패턴을 허용하면(여기서 데이터는 데이터베이스에만 추가됨) 사용자는 더욱 편리해집니다. 짧은 시간 창에서 동일한 문서를 계속 업데이트하는 것에 의존하는 패턴은 반드시 피해야 합니다.

이 파트의 끝입니다. 다음 파트는 The Document ID입니다.

_id 동영상 스크립트

IBM Cloudant 오신 것을 환영합니다. 이 과정은 17개의 비디오 시리즈로 구성되어 있으며, IBM Cloudant 대한 개요를 제공합니다.

본 동영상은 파트 3 - *문서 _id*입니다.

이전 절에서는 애플리케이션이 IBM Cloudant 데이터베이스에 JSON 오브젝트를 저장하는 방식에 대한 유연성과 함께 데이터가 IBM Cloudant 문서에 저장되는 방식을 살펴보았습니다. 하지만 몇 가지 엄격하고 빠른 규칙이 있습니다.

한 가지 규칙은 모든 문서에 문자열인 _id라는 고유 ID가 포함되어야 한다는 것입니다. 동일한 데이터베이스에 있는 두 개의 문서는 동일한 " _id " 필드를 가질 수 있습니다. 다른 데이터베이스에서는 어떠한 열이 고유 ID인지 지정하지만 IBM Cloudant에서는 항상 _id이며 변경할 수 없습니다.

또한 관계형 데이터베이스와는 다르게 IBM Cloudant에는 "자동 증가 ID"가 없습니다. 즉, ID 필드는 1부터 시작하고 추가된 문서마다 증가합니다.

IBM Cloudant의 _id 필드는 다음 문자열 중 하나입니다.

• IBM Cloudant에서 생성된 32자의 문자열. ID는 고유한 것으로 보장된 의미 없는 순서의 숫자 및 문자입니다.
• 사용자가 정의한 문자열(데이터에 대해 고유한 것을 알고 있는 경우).

다음 예에서는 사용자 고유의 문서 _id를 제공하는 방법을 보여줍니다.

이를 사용하여 고유 항목(즉, 사용자의 이메일 주소)을 저장할 수 있습니다. 등록 메커니즘은 이메일 주소당 하나의 사용자 주소 정책을 시행할 수 있습니다. 일부 사용자는 _id에서 문서 유형을 인코딩하도록 선택합니다(예: user:56, book:55). 마지막 예는 대략적인 날짜 및 시간 순서로 정렬하도록 설계된 32자리 문자열(앱에서 생성됨)로 표시됩니다. 이 방법을 사용하면 2차 인덱스 없이 데이터베이스에서 최신 문서를 쉽게 검색할 수 있습니다.

IBM Cloudant는 _ids 문서를 사용하여 인덱스(예: 서적의 목차 페이지)에 저장합니다. 이 1차 인덱스는 _id 순서로 되어 있으며 IBM Cloudant가 _id로 문서를 검색할 수 있도록 하는 데 사용됩니다. 따라서 키-값 저장소와 유사한 기능을 합니다.

_id 필드를 신중하게 설계하면 1차 인덱스를 사용하여 1차 인덱스에서 타당한 데이터를 함께 보존할 수 있습니다. 이 방법을 사용하면 나중에 해당 데이터를 더 빨리 검색할 수 있습니다. 시간 정렬 가능한 _ids를 사용하면 근사치인 날짜 및 시간 순서로 데이터를 검색할 수 있음을 확인했습니다.

나중에 문서 ID의 범위를 검색하는 경우 예를 볼 수 있습니다.

결론적으로 각 문서에는 데이터베이스에서 고유한 _id 필드가 있어야 합니다. IBM Cloudant에서 자동 생성되거나 애플리케이션에서 제공될 수 있습니다. 이 경우 사용자는 _id 필드의 고유성에 대한 책임을 져야 합니다.

_id 필드는 데이터베이스의 1차 인덱스의 기반이며, 나중에 키-값 검색 및 범위 조회에 사용될 수 있습니다.

이 파트의 끝입니다. 다음 파트는 The rev token입니다.

개정 토큰 동영상 스크립트

IBM Cloudant 오신 것을 환영합니다. 이 과정은 17개의 비디오 시리즈로 구성되어 있으며, IBM Cloudant 대한 개요를 제공합니다.

본 동영상은 파트 4 - rev 토큰입니다.

두 번째 기본 IBM Cloudant 규칙은 각 문서 개정에 고유한 개정 토큰이 제공되는 것입니다. 이것이 무엇을 의미하는지 알아 봅시다.

API를 사용하는 문서를 추가, 업데이트 또는 삭제할 때 작성된 개정 토큰을 생성할 필요가 없습니다.

개정 토큰은 두 부분으로 구성됩니다.

숫자 1, 2, 3 등과 문서 본문의 암호화 해시입니다. (초보자의 경우 해시는 일부 데이터의 디지털 "지문"입니다. 데이터가 변경되면 지문이 변경됩니다. 두 개의 지문이 동일하지 않습니다. 즉, 컨텐츠가 다른 두 개의 문서에 동일한 해시가 있을 수 없습니다.)

화면의 예에서 볼 수 있듯이, 저희 문서는 수정 토큰(키가 _rev 로 시작)이 있으며, 그 뒤에 대시가 붙은 1 로 시작합니다. 이는 이 개정이 문서의 첫 번째 개정임을 표시합니다. 04aa8... 로 시작하는 숫자는 문서의 암호화 해시입니다.

문서의 라이프사이클을 따르는 경우 이는 revision 1에서 시작합니다. 나중에 수정되면 이는 revision 2 등을 가져옵니다. 문서의 내용도 수정 중이므로 각 개정 번호가 증가하면서 해시가 변경됩니다.

문서의 번호가 같은 개정이 여러 개 있을 수 있습니다. 이 경우 두 개의 revision 3s가 있습니다. 이 시나리오는 충돌이라고 하며 일부 상황에서는 "정상" 입니다. 나중에 이 과정에서 이유를 알 수 있지만 지금은 문서에 대한 각 업데이트와 함께 개정 번호가 증가한다고 가정할 수 있습니다.

예제 IBM Cloudant 문서의 라이프사이클을 따르십시오.

새 문서가 작성되면(자동 생성된 _id 또는 사용자 제공된 _id에서), 이에는 revision 1이(가) 할당됩니다. 사용자는 API 요청에 대한 응답으로 토큰을 전송합니다. 일반적으로, rev를 삭제할 수 있습니다(곧 문서를 수정하지 않을 경우).

_rev가 revision 1에 있는 문서를 수정하면 문서가 저장되고 revision 2 토큰이 생성되어 API 응답으로 리턴됩니다. Liz에서 Elizabeth로 문서의 이름을 변경했습니다.

지금까지는 아주 간단했습니다.

나중에 문서를 삭제하면 revision 3이 작성됩니다.

대부분의 다른 데이터베이스와는 달리 IBM Cloudant는 삭제된 문서에 대한 참조 항목을 보관합니다. 삭제는 다른 문서 개정입니다. 여기서 _deleted: true는 문서 본문을 대체합니다.

실제로 문서의 최신 개정 히스토리(개정 트리 - 각 개정 번호 중 둘 이상을 가질 수 있음)가 유지됩니다.

IBM Cloudant의 개정 트리를 버전 제어 시스템으로 사용하여 이전 개정을 검색하거나 롤백할 수 없습니다. 수정본이 대체되면, 이전 수정본의 문서 본문이 삭제되고, 압축이라는 과정을 통해 디스크 공간이 복구됩니다. 압축이 IBM Cloudant에서 자동으로 발생하므로 이전 개정을 검색할 수 있다고 가정하는 것은 안전하지 않습니다.

요약하면, 개정 토큰은 추가, 편집 및 삭제 시 데이터베이스에서 생성됩니다. (자체 개정 토큰을 작성하지 않아도 됩니다.) 일반적으로 개정 번호는 매번 1씩 증가하지만 좀 더 복잡한 시나리오가 가능합니다(나중에 이러한 시나리오 포함). 오래된 문서 본문은 버려지거나 압축됩니다. (다시 되돌릴 수 있는 것에 의존하지 마십시오.) 문서를 변경하는 모든 IBM Cloudant 오퍼레이션에는 문서의 _id 및 해당 _rev 가 필요합니다(이 시나리오는 대부분의 데이터베이스와 다름).

이 파트의 끝입니다. 다음 파트는 Authentication입니다.

인증 동영상 스크립트

IBM Cloudant 오신 것을 환영합니다. 이 과정은 17개의 비디오 시리즈로 구성되어 있으며, IBM Cloudant 대한 개요를 제공합니다.

본 동영상은 파트 5 - 인증입니다.

앞에서 IBM Cloudant는 공용 인터넷의 웹 기반 서비스라고 했습니다. 데이터가 안전하고 우리 코드만 액세스할 수 있는지 어떻게 확인할 수 있습니까? 이 시나리오는 인증이 수신되는 위치입니다.

IBM Cloudant에서는 두 가지 인증 유형을 지원합니다.

레거시 인증은 HTTP 사용하는 각 요청에 사용자 이름 또는 API 키와 비밀번호를 제공하거나 일회성 세션 API 호출을 사용하는 쿠키와 교환하는 방식입니다. 세션 쿠키는 정기적으로 순환되므로 클라이언트 코드는 새로 고친 쿠키를 캡처하여 후속 요청을 위해 저장해야 합니다. IAM 인증은 모든 IBM Cloud 서비스를 지원하는 액세스 관리 시스템입니다. IAM으로 인증하려면 IAM API 키와 IBM Cloudant 호스트 이름이 필요합니다. API키는 IAM API를 사용하여 Bearer 토큰으로 교환되며 Bearer 토큰은 각 요청과 함께 IBM Cloudant로 전달됩니다. Bearer 토큰은 1시간만 지속되므로 IAM 서비스로 주기적으로 갱신해야 합니다. IBM Cloudant 가 프로비저닝되면, IAM 전용 자격 증명 또는 IAM과 레거시 자격 증명 모두를 생성할 수 있습니다.

인증 정보는 어떻게 생성됩니까?

IBM Cloud 서비스 아래의 IBM Cloudant 대시보드에 있는 서비스 인증 정보 탭에서 새 인증 정보를 클릭하십시오. IAM 키, 기본 인증 사용자 이름과 비밀번호, 그리고 IBM Cloudant 이름이 포함된 JSON 문서가 생성됩니다.

인증 정보의 예시 세트를 확인하세요:

IAM의 경우, apikey와 host가 필요합니다. 레거시 인증이나 기본 인증, 또는 둘 다의 경우 URL ( URL 에 포함된 사용자 이름과 비밀번호)이 필요합니다.

IBM Cloudant 에는 Java™, Node.js, Python 세 가지 공식 클라이언트 라이브러리가 있습니다.

세 가지 모두 인증을 자동으로 처리합니다. 세션 토큰으로 API 키를 교환하는 방법이나 IAM 인증 작동 방식에 대해서는 걱정할 필요가 없습니다. 사용자를 대신해서 처리됩니다.

문서에서 API에 대해 설명할 때 편의상 기본 인증을 사용합니다. 그러나 IBM Cloud 플랫폼 및 세분화된 권한과 더욱 잘 통합할 수 있으므로 가능하면 IAM 인증을 사용하는 것이 좋습니다.

다음 실습을 위한 시간입니다.

IBM Cloud 로그인하고, 지난번에 만든 IBM Cloudant 라이트 서비스를 찾습니다. Service Credentials 탭에서 New Credential 단추를 클릭하여 IAM+Legacy 인증 정보 세트를 생성합니다. 반환되는 JSON을 메모해 두세요 - 다음 연습에 필요할 것입니다.

그런 다음 JSON 인증 정보에 지정된 URL을 방문합니다. 무엇이 보입니까?

요약하면, IBM Cloud 대시보드에서 인증 정보가 생성됩니다. IAM 또는 IAM + 레거시 인증 정보를 둘 다 가질 수 있습니다. 두 인증 방법 모두 시간 제한 토큰(인증)에 대한 인증 정보를 교환하는 것을 포함합니다. 그러면 서비스를 사용할 때 토큰이 주기적으로 업데이트됩니다. 공식 라이브러리는 사용자를 위해 이러한 모든 태스크를 처리합니다.

이 파트의 끝입니다. 다음 파트는 대시보드입니다.

대시보드 동영상 스크립트

IBM Cloudant 오신 것을 환영합니다. 이 과정은 17개의 비디오 시리즈로 구성되어 있으며, IBM Cloudant 대한 개요를 제공합니다.

본 동영상은 파트 6 - 대시보드입니다.

시작하고, 데이터베이스를 작성하고, 문서를 추가하는 가장 쉬운 방법은 IBM Cloudant 대시보드를 사용하는 것입니다.

IBM Cloudant 대시보드는 서비스에 빌드되는 웹 앱입니다. 그래픽 사용자 인터페이스를 통해 기본 데이터 조작을 수행할 수 있습니다. 데이터베이스를 작성하고 삭제할 수 있습니다. 관리되는 추가, 업데이트, 삭제 및 복제 작업을 문서화합니다. 또한 일회성 쿼리를 수행하고 보조 인덱스를 설정하는 데도 편리한 곳입니다(나중에 설명할 내용).

또한 요청 등급을 시각화하는 몇 가지 간단한 모니터링 도구도 포함되어 있습니다.

IBM Cloudant 대시보드에서 수행할 수 있는 태스크도 IBM Cloudant HTTP API를 사용하여 가능하다는 점에 유의해야 합니다. 실제로, IBM Cloudant 대시보드는 간단히 자체적으로 표준 API 호출을 수행합니다.

IBM Cloudant 서비스 대시보드를 열려면 IBM Cloud에 로그인하여 IBM Cloudant 서비스를 찾고 ** IBM Cloudant 대시보드 실행** 단추를 클릭하십시오. 새 창이 열리고 IBM Cloudant 대시보드에 로그인합니다.

대시보드 창을 오래 방치할 경우 로그아웃하고(보안을 위해) 실행을 다시 클릭해야 합니다.

대시보드에는 여러 탭이 있습니다. 기본 탭인 데이터베이스는 사용자가 그룹 20으로 작성한 데이터베이스를 나열합니다. 각 데이터베이스는 저장 중인 문서 수와 사용 중인 디스크 공간이 표시됩니다. 데이터베이스 이름을 클릭하여 내용을 검토합니다.

데이터베이스를 작성하려면 데이터베이스 작성을 클릭하고 작성할 데이터베이스의 이름을 제공하십시오.

이제 빈 데이터베이스가 새로 만들어졌습니다. 데이터베이스의 문서는 ID 순서대로 여기에 나열됩니다. 그러나 이 데이터베이스는 새 데이터베이스이므로 문서가 존재하지 않습니다. 문서를 추가하려면 문서 작성을 클릭하십시오.

IBM Cloudant 대시보드에서 미리 생성된 _id를 사용하여 템플리트 문서를 작성했습니다. 속성의 나머지 부분을 스스로 완료하여 JSON 문서를 완료하고 문서 작성을 클릭하여 저장하십시오.

이제 다른 실습을 할 시간입니다. books라는 데이터베이스를 작성하고 해당 데이터베이스에서 제목, 작성자, 날짜, 게시자 및 ISBN의 필드가 있는 세 개 이상의 문서를 작성하십시오(각각 원하는 서적 표시).

작성되면 문서 중 하나를 편집하여 등록 날짜를 수정합니다.

그런 다음 문서 중 하나를 삭제합니다.

요약하면, IBM Cloudant 대시보드는 IBM Cloudant 서비스에 빌드된 웹 앱이며 CouchDB 오픈 소스 오퍼링의 일부입니다. 데이터베이스, 문서, 인덱스, 조회 및 복제 작업을 관리하는 데 사용됩니다. 또한 서비스 처리량을 모니터링하는 데도 사용할 수 있습니다. 대시보드는 단순히 API 클라이언트이며, 대시보드를 통해 수행할 수 있는 무엇이든 HTTP API를 사용하여 스크립트될 수 있습니다.

이 파트의 끝입니다. 다음 파트는 HTTP API Basics입니다.

HTTP API 기본 동영상 스크립트

IBM Cloudant 오신 것을 환영합니다. 이 과정은 17개의 비디오 시리즈로 구성되어 있으며, IBM Cloudant 대한 개요를 제공합니다.

본 동영상은 파트 7 - HTTP API Basics입니다.

이전 파트에서는 IBM Cloudant의 API에 대한 HTTP 호출을 수행하는 웹 앱인 IBM Cloudant 대시보드를 확인했습니다. 이 단계에서는 명령행을 사용하여 HTTP 요청을 수행하고 여기에서 일부 문서를 추가, 편집 및 삭제합니다.

상위 레벨 클라이언트 라이브러리를 사용하려는 경우에도 첫 번째 원칙의 HTTP API를 이해하는 것이 좋습니다.

HTTP API가 있는 데이터베이스의 장점은 원하는 경우 인터넷의 모든 디바이스가 데이터를 읽고 쓸 수 있다는 것입니다. 특별한 소프트웨어가 필요하지 않습니다. 사용자 정의 프로토콜을 사용하는 드라이버가 없습니다. 표준 HTTP 라이브러리만 사용하면 됩니다. 예를 들어, 모두 HTTP를 사용합니다.

• 웹 브라우저
• 프로그래밍 언어
• Curl과 같은 명령줄에서 스크립트를 작성하는 데 사용할 수 있는 도구
• 모바일 디바이스

HTTP 요청을 디스패치할 수 있는 무료 오픈 소스 명령행 도구인 curl을 사용하여 API를 알아볼 예정입니다. curl은 대부분의 Mac 및 Unix와 유사한 운영 체제에 사전 설치됩니다. 컴퓨터에 없는 경우 Google curl을 실행하고 설치 지시사항을 따르십시오.

먼저 Curl을 사용하여 웹 페이지(Google의 홈페이지)를 가져옵니다.

1. 명령행 터미널에서 curl https://www.google.com을 입력하십시오.

   응답으로 HTML 페이지를 얻게 됩니다.
   이 메소드가 실행되면 curl이 설치되고 다음 태스크를 진행할 수 있습니다. 이제 IBM Cloudant 서비스의 URL 매번 입력할 필요가 없으므로 IBM Cloudant URL URL 이라는 환경 변수에 저장하겠습니다.

2. 나중에 액세스할 수 있는 export URL이라는 변수를 작성하려면 URL 명령을 실행하십시오.

   export URL=https://username:password@host

3. alias를 작성하십시오.

   alias acurl="curl -sgH 'Content-type: application/json'"

   alias는 나중에 입력 시간을 줄여주는 acurl이라고 하는 단축키입니다. 이 acurl 명령은 curl의 별명이지만 JSON 컨텐츠 유형 헤더와 몇 가지 유용한 명령행 스위치를 사용합니다.

4. alias을 페치하여 acurl $URL/를 테스트하십시오. IBM Cloudant에서 일부 JSON을 다시 가져옵니다.

   첫 번째 IBM Cloudant API 호출을 완료했습니다. 이제, acurl 별명이 설정됩니다. API 탐색을 시작할 수 있습니다. 데이터베이스 목록을 리턴하는 _all_dbs 엔드포인트부터 시작합니다.

5. 데이터베이스 배열을 보려면 acurl $URL/_all_dbs를 입력하십시오.

여기 명령행에서 JSON 형식화에 대한 간단한 참고 사항이 있습니다. acurl 명령의 출력을 다른 도구에 전송할 수 있습니다. 그러면 터미널에서 데이터가 올바르게 형식화됩니다. 사용할 수 있는 도구는 다음과 같습니다.

• 페이지 URL JQ를 사용할 수 있습니다. 이것은 단순한 JSON 포맷터 그 이상입니다 - JSON을 구문 분석, 쿼리, 조작할 수 있습니다.
• Python이 컴퓨터에 설치된 경우 python -m json.tool은 단순 JSON 포맷터입니다.

따라서 acurl $URL/_all_dbs | jq는 acurl의 출력을 jq로 파이핑함을 의미하며, 올바르게 형식화된 유색의 출력이 표시됩니다.

IBM Cloudant API 경로는 서비스에 대한 정보를 제공하는 첫 번째 레벨의 계층 구조이며 각 데이터베이스는 그 아래에 있는 레벨로 배치됩니다.

acurl $URL/books 는 앞서 만든 도서 데이터베이스에 대한 정보를 제공합니다.

보유하고 있는 문서의 수, 삭제된 문서의 수 및 차지하고 있는 디스크 공간의 양에 대한 정보가 표시됩니다.

jq 또는 Python으로 출력을 파이핑하여 더욱 올바른 출력을 얻으십시오.

데이터베이스에 포함된 문서를 보려는 경우 _all_docs 엔드포인트를 사용할 수 있습니다.

따라서 acurl $URL/books/_all_docs는 제공된 URL의 IBM Cloudant 서비스에서 서적 데이터베이스의 모든 문서를 가져오는 것을 의미합니다.

이 명령의 결과는 문서마다 _id 및 _rev 값의 목록을 리턴합니다. 문서 본문을 원하는 경우 API 호출에 ?include_docs=true를 추가합니다.

데이터베이스에서 단일 문서를 다시 가져오려는 경우, 문서는 URL 계층에서 데이터베이스 레벨의 한 레벨 아래에 위치합니다.

따라서 acurl $URL/books/id는 "제공된 URL의 IBM Cloudant 서비스에서 books 데이터베이스의 문서 ID를 가져오는" 것을 의미합니다.

계층 구조(서비스, 데이터베이스 및 문서)에 유의하십시오.

지금까지 웹 브라우저에 URL을 입력할 때 사용되는 curl의 기본값인 GET HTTP 메소드만 사용했습니다.

IBM Cloudant의 API는 종종 데이터를 페치하기 위한 GET HTTP 메소드를 verb로 사용하여 데이터베이스에 요청되는 조치에 대해 설명합니다.

curl을 사용하면 -X 명령행 옵션과 함께 사용할 메소드를 지정할 수 있습니다.

따라서 API를 사용하는 books 데이터베이스에 새 문서를 작성하려면 POST 메소드를 사용하여 문서를 HTTP 요청의 본문으로 사용하게 됩니다.

acurl -X POST에서는 POST HTTP 메소드를 사용 중임을 지정합니다. -d에서는 작성하고자 하는 문서를 지정하며, 이는 요청의 본문으로 전송됩니다. 마지막으로, 작성되는 URL은 $URL/books - 문서 데이터베이스입니다.

또는 작성 중인 문서의 ID를 제공하는 경우 PUT 메소드를 사용할 수 있습니다. URL은 $URL/books/이고 그 다음에 작성하려는 ID가 표시됩니다.

두 쓰기 메소드 모두 동일한 응답을 생성합니다. OK: 쓰기가 성공적으로 이루어졌음을 보여줍니다. ID는 작성된 문서 ID이고, rev는 데이터베이스에서 생성된 수정 토큰입니다.

문서를 수정하기 위해, PUT 메소드를 사용하여 겹쳐쓸 문서 ID를 지시하는 URL에 새 본문을 쓸 수 있습니다. -d에서는 새 문서 본문을 제공하며, URL에는 문서의 데이터베이스와 ID를 포함함은 물론 변경하려는 문서의 개정(rev)도 중요하게 포함됩니다.

rev 매개변수를 잊고 생략하면 오류 응답을 수신합니다.

HTTP 응답 코드는 요청의 성공 여부를 표시합니다. 200개 범위 내에서의 응답이 성공적입니다. 400 범위의 응답은 사용자 오류(예: 올바르지 않은 매개변수)이고 500 범위의 응답은 서버 측 오류입니다. 또한 -v 명령행 옵션을 curl/acurl에 제공하여 전체 HTTP 요청 및 응답을 볼 수 있습니다.

또한 문서에 대한 업데이트는 전체적으로 업데이트되거나 아예 업데이트되지 않습니다. 문서의 일부를 수정하는 API 구성이 존재하지 않습니다. 이전 개정을 덮어 쓰려면 전체 문서를 제공해야 합니다.

마지막으로 문서를 삭제하려면 DELETE 메소드인 -X DELETE를 사용하십시오. 삭제할 데이터베이스 이름 및 문서가 포함된 URL에 요청을 보내고, 비판적으로 삭제할 문서의 개정인 rev도 제공합니다.

개정 토큰을 생략하면 오류가 리턴되고 요청에 실패합니다.

요약하면, HTTP API를 이해한 경우 코드와 IBM Cloudant 서비스 간의 관계를 파악하는 데 도움이 됩니다.

URL은 계층 구조인 service/database/document 또는 service/database/endpoint입니다.

HTTP 메소드는 수행할 조치를 정의하는 verbs역할을 합니다.

모든 조치는 명령행 또는 코드에서 단순 HTTP API 호출을 사용하여 트리거될 수 있고 이에 따라 쉽게 스크립트될 수 있습니다.

이 파트의 끝입니다. 다음 파트는 대량 API입니다.

벌크 API 동영상 스크립트

IBM Cloudant 오신 것을 환영합니다. 이 과정은 17개의 비디오 시리즈로 구성되어 있으며, IBM Cloudant 대한 개요를 제공합니다.

본 동영상은 파트 8 - 대량 API입니다.

이전 파트에서 IBM Cloudant HTTP API를 사용하여 문서를 쉽게 추가, 업데이트 및 삭제할 수 있는 방법을 살펴보았습니다. 본 파트에서는 두 개의 API 호출을 사용하여 모든 기본 IBM Cloudant 오퍼레이션을 수행하는 방법을 확인합니다. API 호출당 둘 이상의 문서에 영향을 줄 수 있는 추가된 장점이 있습니다.

_all_docs 엔드포인트에 대해서는 이미 설명했습니다. 데이터베이스의 모든 문서 목록을 페치하는 데 사용했지만 다른 기능도 포함되어 있습니다.

키 매개변수를 사용하여 페치할 단일 문서를 지정하면 GET /db/id API 호출과 동일하게 만들 수 있습니다. 마찬가지로, 키 매개변수는 문서 ID의 배열을 사용하고 이를 모두 리턴합니다. startkey 및 endkey 매개변수는 제공된 한계 사이의 1차 인덱스 슬라이스를 페치합니다. include_docs=true를 추가하면 IBM Cloudant에도 문서 본문을 제공하도록 지시합니다. 그리고 한계는 한 번의 API 호출로 리턴할 문서 수를 지정합니다.

_bulk_docs 엔드포인트를 사용하면 한 번의 API 호출로 여러 삽입, 업데이트 및 삭제 오퍼레이션을 수행할 수 있습니다. 이는 문서 배열을 포함하는 오브젝트를 예상합니다. 해당 배열의 각 요소는 단일 문서에서 수행할 오퍼레이션입니다. 요청 본문이 IBM Cloudant에 게시되어 여러 오퍼레이션을 단일 API 호출로 패킹할 수 있습니다.

이 예에서는 개정 토큰이 제공되지 않으므로 첫 번째 문서는 삽입입니다. 두 번째 문서는 개정 토큰에 새 문서 본문이 제공되므로 문서에 대한 업데이트입니다. 세 번째 문서는 삭제입니다. 개정 토큰은 제공되지만 본문은 단순히 _deleted: true이며, 이는 문서를 삭제됨으로 표시하도록 IBM Cloudant에 알립니다.

이 시나리오는 관계형 데이터베이스의 트랜잭션과 유사하지 않습니다. 이 오퍼레이션은 모두 성공 또는 실패하거나 아예 성공 또는 실패하지 않을 수 있습니다. 이 요청에 대한 응답 데이터는 오퍼레이션마다 응답을 차례로 표시합니다.

요약하면, 두 개의 API 호출 _bulk_docs 및 _all_docs을(를) 사용하면 IBM Cloudant 문서에 대한 모든 작성, 읽기, 갱신 및 삭제 조작을 수행할 수 있으며 벌크에서도 이를 수행할 수 있습니다. _all_docs은(는) _id 또는 ID 범위로 문서를 검색합니다. _bulk_docs에서는 문서를 대량으로 작성, 업데이트 및 삭제합니다. 일반적으로, 대량 쓰기가 500개의 일괄처리로 실행되는 것이 좋습니다. 소형 문서의 경우에는 더 많고 대형 문서의 경우에는 더 적습니다.

명령줄 터미널에서 IBM Cloudant 사용하는 화면 캡처를 확인하세요

이 파트의 끝입니다. 다음 파트는 프로그래밍 방식으로 IBM Cloudant에 액세스입니다.

프로그래밍 방식으로 IBM Cloudant에 액세스 동영상 스크립트

IBM Cloudant 오신 것을 환영합니다. 이 과정은 17개의 비디오 시리즈로 구성되어 있으며, IBM Cloudant 대한 개요를 제공합니다.

본 동영상은 파트 9 - 프로그래밍 방식으로 IBM Cloudant에 액세스입니다.

지금까지 API 상호작용은 대시보드에 의해 또는 명령행에서 curl을 사용하여 트리거되었습니다. 다음 절에서는 IBM Cloudant가 프로그래밍 방식으로 액세스하는 방법을 확인합니다.

예에서는 Node.js를 사용하므로 코드를 직접 시도하려면 nodejs.org에서 노드와 npm을 설치해야 합니다.

그런 다음 npm install @cloudant/cloudant를 사용하여 공식적인 IBM Cloudant Node.js 라이브러리를 설치할 수 있습니다. (npm은 Node.js와 함께 제공되는 패키지 관리자로 수천 개의 오픈 소스 프로젝트에 액세스하여 무료로 애플리케이션에 빌드 할 수 있습니다.)

IBM Cloudant 라이브러리가 설치되면 일부 소스 코드를 빌드할 수 있습니다. 이 코드 스니펫을 한 줄씩 살펴 보겠습니다.

IBM Cloudant 서비스 URL 앞서 만든 환경 변수에서 가져옵니다.

@cloudant/cloudant 라이브러리는 기본 제공 필수 기능과 함께 Node.js 앱에 로드됩니다. 그런 다음 첫 번째 행에 저장한 인증 정보로 구성된 라이브러리의 인스턴스를 작성합니다. IBM Cloudant 오브젝트를 사용하여 books 데이터베이스에 대한 참조를 가져오고 이를 변수 데이터베이스에 저장합니다. 우리는 어떤 API 호출도 하지 않았습니다 - 단지 자격 증명을 저장하는 데이터 구조와 작업 중인 데이터베이스를 생성했을 뿐입니다. 기본 함수는 db.list를 호출합니다. 이때 이전에 본 _all_docs 엔드포인트와 1-1을 맵핑합니다. db.list에 전달된 매개변수는 _all_docs가 결과 세트를 제한하고 각 ID에 대해 문서 본문을 리턴할 것으로 예상하는 옵션과 관련이 있어야 합니다.

문서를 작성하는 또 다른 코드 스니펫을 보십시오.

표준 JavaScript 오브젝트가 기본적으로 JavaScript에서 JSON 형식으로 전환됨에 따라, 표준 JavaScript 오브젝트는 코드에서 사용할 수 있고 변환 없이 IBM Cloudant에 전송할 수 있는 첫 번째 행에서 확인할 수 있습니다.

문서를 작성하는 것은 단순히 db.insert API 호출 또는 PUT/POST로 맵핑되는 _bulk_docs를 호출하는 문제입니다.

요약하자면, IBM Cloudant 공식 라이브러리는 Java™, Python, Nodejs입니다. 이는 IBM Cloudant HTTP API 주변의 thin 랩퍼이므로 모든 매개변수를 이해하기 위해 기본 API를 이해할 만한 가치가 있습니다.

라이브러리는 두 가지를 처리합니다. 유용한 점은 다음과 같습니다.

인증

기존 인증이든 IAM이든 간에 토큰과 키를 교환합니다.

재시도 로직

프로비저닝된 용량을 초과한 API 호출을 다시 시도하도록 라이브러리를 구성할 수 있습니다. 이 방법으로 구성된 경우, 이들은 지수 백오프로 API 호출을 여러 번 일시정지하고 다시 시도합니다.

일시적이고 예기치 않은 트래픽 증가가 발생한 경우 이러한 API 호출을 재시도하는 것은 합리적입니다. 정기적으로 프로비저닝된 용량을 초과하는 경우 수 많은 재시도를 해도 데이터베이스 작업은 완료되지 않습니다. 더 많은 용량이 필요합니다!

이 파트의 끝입니다. 다음 파트는 Querying입니다.

조회 동영상 스크립트

IBM Cloudant 오신 것을 환영합니다. 이 과정은 17개의 비디오 시리즈로 구성되어 있으며, IBM Cloudant 대한 개요를 제공합니다.

본 동영상은 10 - 조회입니다.

지금까지 우리는 명령줄, 대시보드, 코드에서 CRUD(생성, 검색, 업데이트, 삭제) 작업을 수행했습니다. 이러한 작업은 문서의 문서 속성( _id )을 사용합니다

• _id별로 문서를 페치합니다.
• _id = 'x'인 문서를 업데이트합니다.
• _id = 'x'인 문서를 삭제합니다.
• _id 범위 'a' - 'z'의 문서를 가져옵니다.

이러한 오퍼레이션은 데이터베이스의 빌딩 블록이지만, 이것으로는 한계가 있습니다. 문서 내의 필드에 일치하는 문서의 서브세트를 리턴해야 하면 어떻게 합니까? 사람의 생년월일? 책 제목? 주문 가격?

여기에서 쿼리가 시작됩니다.

IBM Cloudant에는 데이터를 조회하는 여러 가지 방법이 있습니다. 처음에는 IBM Cloudant 조회라고 합니다.

IBM Cloudant 조회 언어는 MongoDB 조회 언어로 영향을 받았습니다. 조회는 JSON으로 표현되며, 여기서 selector 속성은 리턴할 데이터의 서브세트를 설명합니다. 조회를 수행하기 위해 데이터베이스의 _find 엔드포인트에 조회 JSON이 게시됩니다.

가장 단순한 조회 양식은 속성에 고정 값이 있는 문서를 찾는 것입니다(예: author == J Smith).

두 번째 예는 조회에 두 개의 절을 표시합니다. 문서가 검색 결과에 작성되도록 하려면 두 절이 모두 충족되어야 합니다(예: isbn === 6725252 AND date = 2018-01-01).

세 번째 예제에서는 논리 연산자를 추가할 수 있는 방법을 보여 줍니다. $gt 연산은 비교 연산자( greater than )를 의미합니다(비교 연산자보다 크거나 같으면 gte 를, 비교 연산자보다 작으면 lt/lte 를 사용할 수 있습니다). $or 연산자는 OR 연산이므로 일치하는 문서에는 작성자인 J Smith(작성자) OR Murder(제목) 중 조회의 1보다 더 큰 날짜 값이 있어야 합니다.

문서 내의 오브젝트에 액세스해야 하는 경우, 표준 점 표기법(예: address.zipcode)을 사용하여 주소 오브젝트 내의 우편번호 문자열에 액세스할 수 있습니다.

또한 다음 매개변수를 추가할 수 있습니다.

필드

리턴할 문서 속성을 지정합니다(기본값은 전체 문서).

정렬

데이터 정렬 방법을 정의합니다. sort는 배열이므로 여러 속성에서 정렬을 계산할 수 있습니다.

한계

리턴할 문서의 수.

관계형 데이터베이스 백그라운드를 갖고 있는 경우 이 조회는 마지막 IBM Cloudant 조회 예제와 동일한 SQL 조회입니다.

WHERE 절은 IBM Cloudant Query에서 SELECTOR과(와) 동일합니다. ORDER 및 LIMIT은(는) 정확히 동일하며, IBM Cloudant Query FIELDS 목록은 SELECT 키워드 이후의 쉼표로 구분된 속성 목록과 같습니다.

JSON 구문을 사용하는 데 다소 시간이 걸릴 수 있지만, MongoDB 사용자에게는 익숙할 수 있습니다.

IBM Cloudant 조회는 IBM Cloudant 대시보드에서 실행될 수 있습니다. 작업 중인 데이터베이스(예: books)를 선택한 후 조회 탭을 선택하십시오.

제공된 상자에 IBM Cloudant 조회 JSON 조회를 입력하고 준비가 되면 조회 실행 을 클릭하십시오. 결과 집합이 페이지에 나타납니다.

설명 단추는 데이터베이스가 제공된 조회를 해석하는 방법에 대한 설명을 제공하는 데 사용됩니다. 이러한 설명은 다음 파트에서 인덱싱할 때 더욱 중요합니다.

조회는 curl에서도 트리거될 수 있습니다. 이 경우, 조회 JSON은 파일에 저장되고 POST 구문을 통해 _find 엔드포인트에 게시(-d@ command-line)합니다.

Node.js 코드는 유사합니다. 조회는 사용자 대신 db.find 엔드포인트에 게시(POSTs)하는 _find 함수로 전달되는 표준 JavaScript 오브젝트입니다.

이제 실습할 시간입니다. 20세기에 작성된 서적 제목을 찾는 고유한 IBM Cloudant 조회를 생성하십시오. 필요한 경우 IBM Cloudant 조회 문서는 화면에 표시되는 URL입니다.

답을 알고 싶지 않다면 프레젠테이션을 일시정지하십시오...

한 가지 해결책을 보십시오:

$and 연산자를 사용하여 날짜 속성에 두 개의 절을 결합합니다. 하나의 절은 날짜가 >= 1900인 문서를 찾기 위한 것이며, 다른 하나는 날짜가 < the year 2000인 문서를 찾기 위한 것입니다. 문서를 선택하려면 두 절이 모두 맞아야 합니다. 일치하는 서적의 제목만 필요하므로 전체 문서를 리턴하는 대신 필드 속성을 제공할 수 있습니다.

요약하면, IBM Cloudant 조회는 구문이 JSON 양식으로 표현되는 MongoDB에서 영향을 받은 조회 언어입니다.

조회는 문서의 _id가 아니라 문서 내부의 데이터에 실행되는 절을 사용하여 데이터베이스에서 문서의 서브세트를 선택합니다.

조회는 curl을 사용하거나 대시보드를 사용하여 프로그래밍 방식으로 데이터베이스의 _find 엔드포인트에 전송됩니다.

조회 선택기는 어떤 데이터 잘라내기가 필요한지 결정합니다.

이 파트의 끝입니다. 다음 파트는 인덱싱입니다.

인덱싱 동영상 스크립트

IBM Cloudant 오신 것을 환영합니다. 이 과정은 17개의 비디오 시리즈로 구성되어 있으며, IBM Cloudant 대한 개요를 제공합니다.

본 동영상은 파트 11- 인덱싱입니다.

이전 파트에서 실행한 조회는 최적이 아니었습니다. 응답을 얻기 위해 IBM Cloudant는 데이터베이스의 모든 문서를 차례로 스풀링하여 검색 기준에 부합하는지 여부를 확인합니다.

성능 기준에 맞고 확장 가능한 방식으로 실행되는 조회를 작성하려면 인덱싱이 필요합니다.

IBM Cloudant를 사용하여 여러 개의 인덱스를 지정할 수 있습니다.

인덱스는 문서 목록에서 빌드된 보조 데이터 구조입니다. 여기에는 사용자가 지정하는 필드별로 정렬된 데이터(예: 날짜 및 제목별로 정렬된 서적)가 포함됩니다. 문서의 날짜 및 제목과 일치하는 데이터를 요청하는 조회를 수행하는 경우 인덱싱된 데이터 구조를 사용하여 조회 프로세스를 가속화할 수 있습니다. 모든 문서를 차례로 스캔하는 대신, IBM Cloudant는 인덱스 관련 파트(즉, 20세기 서적의 섹션)로 이동하여 훨씬 더 빨리 데이터를 검색할 수 있습니다.

IBM Cloudant 조회 인덱스에는 두 가지 유형의 인덱스인 type=json 및 type=text가 포함됩니다. 이 색인들은 이 강좌의 뒷부분에서 소개할 두 가지 기본 색인 기술에 의해 뒷받침됩니다.

인덱스는 데이터베이스의 POST 엔드포인트에 대한 일부 JSON을 게시(_index)할 때 정의됩니다.

인덱스 오브젝트에는 인덱싱할 문서 속성을 지정하는 필드 배열이 포함되어 있습니다. 일반적으로, 인덱싱이 필요한 필드는 데이터를 검색하는 데 사용할 조회의 selector에서 사용되는 속성과 동일합니다. 즉, 날짜 필드를 기준으로 조회해야 하는 경우 날짜 필드를 인덱싱해야 합니다.

인덱스의 name 은 선택적이지만 우수 사례이며 이 규칙을 따릅니다. IBM Cloudant에게 질문을 하고 사용할 인덱스의 이름을 지정하는 것이 좋습니다. 이 사례에서는 IBM Cloudant 사용 가능한 인덱스에서 사용할 인덱스를 선택하지 않아도 되며, 어떤 인덱스가 무엇인지 쉽게 기억할 수 있도록 합니다.

대시보드에서 books 데이터베이스에 대한 인덱스를 작성합니다. 데이터베이스를 선택한 후 메뉴에서 문서 설계 탭 및 조회 인덱스를 선택하십시오.

special 기존 인덱스는 측면에 나열됩니다: 문서의 _id 를 기반으로 하는 기본 인덱스를 나타내는 A 인덱스가 있어야 합니다.

JSON으로 인덱스 정의를 완료하십시오.

완료되면 Create Index를 클릭하십시오.

단추를 클릭하면 POST 요청이 _index 엔드포인트로 전송됩니다(다른 API 호출은 기존 인덱스를 업데이트 및 삭제하는 데 사용 가능함).

인덱스는 백그라운드에서 IBM Cloudant에 의해 비동기식으로 빌드됩니다. 대형 데이터베이스의 경우 IBM Cloudant에서는 처음 인덱스를 구성하는 데 약간의 시간이 걸릴 수 있습니다. 인덱스는 초기 빌드가 준비될 때까지 데이터베이스를 사용할 수 없습니다.

20세기의 서적에 대한 조회를 반복할 수 있습니다. 이번에는 use_index 필드를 사용하여 인덱스 이름을 지정합니다. 응답이 리턴됩니다. 이때 인덱스로 구동됩니다. 소형 데이터베이스에 대한 속도가 향상되지는 않지만 데이터 크기 및 조회 볼륨이 증가할 때 이점을 확실하게 알게 됩니다. 인덱싱은 애플리케이션이 확장될 때 조회 성능을 유지하는 데 도움이 됩니다.

IBM Cloudant에 2차 인덱스를 작성하도록 지시하면, 차례로 모든 문서를 확인하고 디스크에 새 데이터 구조를 작성하는 백그라운드 태스크를 시작합니다. 인덱스는 다음과 같습니다. 색인은 키(색인해야 하는 속성)를 해당 키가 들어 있는 문서( _id )와 쌍으로 연결하는 균형 트리입니다.

인덱스를 사용하면 전체 데이터베이스를 다시 스캔하지 않고도 알려진 키와 키 범위를 효율적으로 조회할 수 있습니다.

인덱스 시간에 사용할 수 있는 또 다른 트릭은 부분 필터입니다. 선택적으로 인덱스 정의에 부분 필터를 제공할 수 있습니다. 이 IBM Cloudant 조회 선택기는 인덱스 시간에 실행되어 어떠한 문서의 데이터가 인덱스로 지정되고, 무시되는지를 결정합니다.

이 예에서는 선택기는 주말에 속하는 날짜만 인덱스로 지정될 수 있도록 사용됩니다. 인덱스가 작을 수록 더 빠르고 효율적입니다. 인덱싱할 데이터의 서브세트만 필요한 유스 케이스가 있는 경우 인덱스 시간에 부분 필터 선택기를 사용하면 인덱스가 더욱 작아지고 효율적이 될 수 있습니다. 예를 들어, 완료된 주문만 인덱싱하거나 만료된 계정만 인덱싱하거나 공개된 블로그 게시물만 인덱싱할 수 있습니다.

요약하면, _index 엔드포인트를 사용하여 인덱스를 정의하고 선택적 부분 필터를 조회 시간에 적용하여 더 작고 드문 인덱스를 작성할 수 있습니다.

이 파트의 끝입니다. 다음 파트는 MapReduce입니다.

MapReduce 동영상 스크립트

IBM Cloudant 오신 것을 환영합니다. 이 과정은 17개의 비디오 시리즈로 구성되어 있으며, IBM Cloudant 대한 개요를 제공합니다.

본 동영상은 파트 12 - MapReduce입니다.

_find 및 _index 엔드포인트의 조합이 JSON 문서의 컨텐츠에 대해 조회를 수행할 수 있도록 하는 방법을 살펴보았습니다. 애플리케이션이 확장될 때 조회 스케일을 작성하기 위해 2차 인덱스를 지원합니다.

이 파트에서는 MapReduce라고 하는 2차 인덱스를 구성하는 다른 방법을 소개합니다.

MapReduce는 CouchDB에서 2차 인덱스를 구성하는 유일한 방법이었으며 여전히 문서 본문에서 데이터를 조회하는 일반적인 방법입니다.

MapReduce 인덱스를 작성하려면 디자인 문서라고 하는 특수 문서에 랩핑된 JavaScript 함수를 IBM Cloudant에 제공해야 합니다. 디자인 문서의 _id 필드는 _design/으로 시작합니다(예: _design/mydesigndoc).

IBM Cloudant에서 디자인 문서를 수신하면 백그라운드 인덱싱 태스크를 설정하여 데이터베이스의 각 문서를 JavaScript 함수에 차례로 전달합니다. JavaScript 함수에서 생성되는 키-값은 지속되는 인덱스의 기반을 형성합니다.

JavaScript 함수 예제를 살펴봅니다.

함수는 IBM Cloudant 인덱서로 전달되는 문서인 하나의 매개변수를 허용합니다. 함수 호출이 인덱스의 키-값에서 전달하는 매개변수를 생성할 때마다 수행됩니다.

첫 번째 예는 doc.name의 키를 생성하므로, 이 경우 이름 필드에 의한 검색의 인덱스입니다. 값에는 아무 것도 없습니다(널).

두 번째 예제에서는 데이터를 생성하기 전에 미리 처리합니다. 이러한 사전 처리는 문자열을 정리하고, 공백을 줄이고, 텍스트를 자르고, 대문자 및 소문자로 변환하거나, 누락된 데이터에 기본값을 적용하거나, 특정 범위의 값을 제한하는 등의 유용한 방법입니다.

세 번째 예제는 논리를 추가합니다. published 문서만 인덱스로 작성합니다. 이 논리는 IBM Cloudant 쿼리에서 살펴본 부분 필터 선택기와 동일합니다.

인덱스는 비동기식으로 빌드되며 완전히 빌드될 때까지 사용할 수 없습니다. 일단 구축되면, 키, 키 목록, 키 범위, 데이터 집계 등을 선택하는 데 사용할 수 있습니다. 예를 들어, 두 날짜 사이의 주문을 찾고, 월별로 그룹화된 주문의 총 가치를 계산합니다

IBM Cloudant에는 네 개의 기본 제공 감축자가 포함되어 있습니다(또는 none을 계수하는 경우에는 다섯 개).

_count

계산을 수행합니다.

_sum

값을 토털라이징합니다.

_stats

평균, 분산 및 표준 편차를 계산하는 데 적합한 개수 및 합계를 제공합니다.

_approx_count_distinct

키의 고유 값을 대략적으로 계산합니다.

디자인 문서의 MAP 함수는 doc에 전달됩니다. 함수는 데이터베이스에서 문서당 한 번 호출됩니다. emit 함수에서 생성(MAP)하는 모든 키-값 쌍은 인덱스를 작성합니다.

KEY는 날짜 등에서 선택(select)할 사항입니다.

VALUE는 보고해야 하는 항목(예: 총 매출액)입니다.

감축자는 _sum이므로 일치하는 키(예: 동일한 날짜의 주문)에 대해 VALUE의 총계가 계산됩니다.

IBM Cloudant MapReduce 정의가 어떻게 이루어지는지 확인해 보세요.

MapReduce 보기가 빌드되면 인덱스에 저장된 각 KEY-VALUE 쌍을 보기 위해 조회될 수 있습니다.

또는 감축자가 설정되면 결과 세트는 각 키의 값별로 그룹화될 수 있습니다. 이 경우, 매일 매출을 합산합니다.

보기는 개별 키(예: 특정 날짜의 매출), 모든 키 또는 키 범위(예: 두 날짜 사이)에 대해 조회될 수 있습니다.

MapReduce 보기는 비동기식으로 빌드되며 대형 데이터 세트를 준비하는 데 약간의 시간이 소요될 수 있습니다.

몇 가지 팁을 확인해 보세요:

완료된 주문만을 처리하는 것과 같이 의미가 있는 데이터만 포함하려면 JavaScript의 로직을 사용하십시오. 인덱싱된 키가 문자열일 필요는 없습니다. 공통 패턴은 배열 키(예: 년, 월, 일)를 사용하는 것입니다. 이러한 인덱스 키를 사용하면 배열의 요소별로 조회 시간을 그룹화할 수 있습니다. 예를 들어, 연도별 주문, 연도 및 월별 주문, 연도 및 월별 및 일별 주문을 그룹화할 수 있습니다. 사용자가 세부사항을 드릴 다운할 수 있는 요약 보고서에 대해 적합합니다. 값은 문자열, 숫자 또는 소형 오브젝트(문서의 서브세트 포함)가 될 수 있습니다. include_docs=true를 추가하는 대신 오브젝트를 사용할 수 있습니다. 이는 결과 세트의 문서 본문도 리턴합니다.

요약하면, MapReduce는 데이터를 선택하고 집계할 수 있는 인덱스를 정의하는 하위 레벨 수단입니다.

JavaScript 로직을 사용하여 인덱스로 만들 데이터를 결정하십시오. 키-값을 생성하여 인덱스가 형성되는 방법을 선택하십시오.

기본 제공 reducer로 데이터를 요약합니다. 많은 데이터로부터 간결한 보고서를 효율적으로 생성하십시오.

MapReduce는 애플리케이션이 반복해서 수행해야 하는 상용구 조회에 유용합니다. 데이터 탐색을 위한 일회성의 임시 조회에 적합하지 않습니다.

이 파트의 끝입니다. 다음 파트는 날짜입니다.

날짜 동영상 스크립트

IBM Cloudant 오신 것을 환영합니다. 이 과정은 17개의 비디오 시리즈로 구성되어 있으며, IBM Cloudant 대한 개요를 제공합니다.

본 동영상은 파트 13 - 날짜입니다.

이 과정의 앞부분에서 JSON은 기본적으로 문자열, 숫자, 부울, 오브젝트 및 배열만 모델링한다는 것을 알았습니다. 일반적인 유스 케이스는 데이터베이스에 날짜 또는 날짜 및 시간 값을 저장하는 것입니다. IBM Cloudant 사용하여 이를 달성할 수 있는 방법에 대한 몇 가지 아이디어를 확인해 보세요.

시간을 표시하는 ISO-8601문자열 형식은 y-m-dTh:m:s.msTIMEZONE 년, 월, 일, 'T' 문자, 시, 분, 초, 밀리초 및 시간대로 구성됩니다.

다른 지역에서 데이터를 수집하는 경우에도 항상 UTC 시간대로 날짜를 저장하는 것이 좋습니다. 이 양식에 저장된 날짜는 프론트 엔드의 로컬 시간대로 쉽게 변환될 수 있습니다. 일반적으로 각 사용자의 데이터를 "동일한 단위"로 저장하는 것이 중요합니다.

이 문자열 형식은 날짜 및 시간 순서로 정렬되며(가장 중요한 날짜 단위가 문자열의 앞에 있으므로) MapReduce 함수에서 쉽게 구문 분석될 수 있습니다.

다른 옵션은 1970년 1월 1일 이후 밀리초 수를 저장하는 것입니다. 또한 이 옵션은 날짜 및 시간을 표시하는 시스템으로 읽을 수 있는 표준 방법입니다.

MapReduce 함수에서도 구문 분석될 수 있으며 다른 시간소인에서 하나만 가져오면 되므로 다른 두 개의 날짜를 비교하는 데 편리합니다.

요약하자면, JSON에는 기본 날짜 형식이 존재하지 않으므로 원하는 방식으로 날짜와 시간을 저장할 수 있습니다. ISO-8601은 컴팩트하고, 읽을 수 있으며, 시간소인(1970년 이후의 밀리초)을 표시하므로 올바르게 정렬됩니다.

컴포넌트 파트 중 하나에서 IBM Cloudant 조회를 사용해야 하는 경우 문서에서 명시적으로 구분되어야 합니다.

이 파트의 끝입니다. 다음 파트는 Replication입니다.

복제 동영상 스크립트

IBM Cloudant 오신 것을 환영합니다. 이 과정은 17개의 비디오 시리즈로 구성되어 있으며, IBM Cloudant 대한 개요를 제공합니다.

본 동영상은 14 - 복제입니다.

복제는 IBM Cloudant의 핵심 기능입니다. 한 데이터베이스(소스)에서 다른 데이터베이스(대상)로 데이터를 전송합니다.

소스 데이터베이스와 대상 데이터베이스는 동일한 IBM Cloudant 서비스에 있거나, 지리적으로 분리되어 있을 수 있습니다. 예를 들어, 유럽에 있는 데이터베이스를 복제하는 IBM Cloudant 가 있습니다.

IBM Cloudant 복제 프로토콜은 Apache CouchDB와 공유되므로, 복제는 데이터를 클라우드 기반 데이터베이스에서 고유 위치에 있는 CouchDB로 복사하는 엔터프라이즈에서 종종 사용됩니다.

또한 Node.js 스택 또는 웹 브라우저에서 실행되는 JavaScript 기반 CouchDB 복제인 PouchDB는 어느 방향에서든 IBM Cloudant 또는 CouchDB 간에 데이터를 복제할 수 있습니다.

IBM Cloudant 동기화 라이브러리는 IBM Cloudant 서비스와 데이터를 동기화하는 원시 iOS 또는 Android 앱입니다.

복제는 원본에서 대상으로의 단방향 작업으로, 모든 데이터(삭제, 충돌, 첨부 파일, 문서)를 이동하며, 다음 두 가지 방법 중 하나로 트리거할 수 있습니다

1. 소스의 모든 데이터가 대상에 도달할 때까지 실행한 후 중지하십시오.
2. 하나와 동일하지만 복제는 계속해서 영원히 실행되므로 새 데이터가 도착할 때 소스에서 대상으로 새 데이터를 전송합니다.

마지막으로 중지된 위치에서 복제를 재개할 수도 있습니다. IBM Cloudant은(는) 마지막으로 알려진 위치에서 기존 복제를 재개할 수 있도록 복제 당사자 간에 checkpoints을(를) 기록합니다.

IBM Cloudant 대시보드에는 복제 탭이 포함되어 있습니다. 복제는 인증 정보를 포함하는 소스 및 대상 데이터베이스를 지정하고 이 복제가 한 번 또는 연속 오퍼레이션인지 여부를 지정하여 시작됩니다.

또한 복제에 이름을 지정할 수 있으며 복제 작업이 어떤 것인지 추적하는 데 편리합니다.

이제 실습할 시간입니다.

1. IBM Cloudant 대시보드로 이동하십시오.
2. books2라는 데이터베이스를 작성하십시오.
3. books에서 books2로 연속 복제를 시작합니다.
4. books2 데이터베이스를 방문하여 books의 문서가 books2에 있는지 확인하십시오.
5. books 데이터베이스에 문서를 추가하십시오.
6. books2 데이터베이스로 변경되는지 확인하십시오.

IBM Cloudant 데이터베이스에서 온프레미스 CouchDB 인스턴스로 데이터를 이동하는 데 복제를 사용할 수 있습니다. 복제는 IBM Cloudant 또는 CouchDB에서 제어될 수 있습니다. 예를 들어, IBM Cloudant에게 CouchDB로 변경사항을 전송하도록 요청하거나 CouchDB에게 IBM Cloudant에서 변경사항을 가져오도록 요청할 수 있습니다. 복제 제어기에는 두 HTTP API의 네트워크 가시성이 있어야 합니다.

또한 PouchDB는 동일한 복제 프로토콜을 사용하므로 PouchDB 및 IBM Cloudant에(서) 데이터를 전송하는 데 사용할 수 있습니다. 이 경우 PouchDB가 복제 제어기가 될 가능성이 높습니다.

PouchDB는 일반적으로 오프라인 첫 번째 앱을 작성하는 데 사용됩니다. 이러한 앱은 인터넷에 연결되어 있지 않은 경우에도 데이터를 수집한 다음 다시 온라인으로 전환될 때 IBM Cloudant에 데이터를 작성하여 사용자에게 항상 서비스를 제공합니다.

복제는 항상 필요하지 않습니다. 애플리케이션이 데이터를 저장한 다음 나중에 IBM Cloudant에 작성해야 하는 경우에는 엄밀히 말해 복제가 필요하지 않습니다. 필요한 것은 데이터가 디바이스에 저장되고, 연결이 복원될 때 대량으로 IBM Cloudant에 작성되는 것입니다.

복제는 단방향 오퍼레이션이므로 다른 영역의 두 IBM Cloudant 인스턴스 간에 기본-기본 설정이 필요한 경우 반대 방향으로 두 개의 복제가 필요합니다.

런던 쪽에서 발생하는 변경사항은 달라스로 전송되며 그 반대도 마찬가지입니다.

세트 IBM Cloudant 서비스 주변의 링에 플로우되는 데이터와 함께 좀 더 복잡한 토폴로지가 가능합니다.

요약하면, IBM Cloudant 복제는 소스 데이터베이스에서 대상 데이터베이스로 데이터를 복사하는 메커니즘입니다.

복제는 일회성 또는 연속적일 수 있으며, 선택적으로 JavaScript 함수 또는 IBM Cloudant 조회 선택기를 사용하여 필터링하고 이전 복제가 중지된 위치에서 재개할 수 있습니다.

이 파트의 끝입니다. 다음 파트는 Partitioned databases입니다.

파티션된 데이터베이스 동영상 스크립트

IBM Cloudant 오신 것을 환영합니다. 이 과정은 17개의 비디오 시리즈로 구성되어 있으며, IBM Cloudant 대한 개요를 제공합니다.

본 동영상은 파트 15 - 파티션된 데이터베이스입니다.

IBM Cloudant는 논의될 토론인 분산 데이터베이스입니다. 많은 스토리지 노드가 IBM Cloudant 서비스를 구성하고 데이터베이스의 문서가 shards라는 그룹의 노드에 분배되어 있습니다. 단일 데이터베이스는 sharded 또는 여러 조각으로 나뉩니다.

일반 IBM Cloudant 데이터베이스에서 문서에는 알고리즘으로 샤드가 할당되고 문서는 효율적으로 샤드 주변에 무작위로 분배됩니다.

파티션된 데이터베이스에서 파티션 키를 제공하여 문서가 저장되는 샤드를 정의합니다.

분할된 데이터베이스는 동일한 PUT /<database name> API 호출로 생성되지 않고, 추가적인 쿼리 문자열 매개변수( partitioned=true )를 통해 생성됩니다.

첫 번째 예에서 제품 데이터베이스는 파티션된 데이터베이스로 작성되고, 두 번째 예에서 표준으로 파티션되지 않은 데이터베이스로 작성됩니다.

파티션된 데이터베이스에 문서를 추가하는 경우, 문서 _ID를 제공해야 합니다. (자동 생성 문서 _ID는 존재하지 않음). _id 문서에는 쉼표로 구분되는 두 파트가 있습니다.

파티션 키

문서를 저장할 파티션을 정의하는 문자열입니다.

문서 키

파티션 내에서 문서를 고유하게 식별하는 문자열입니다.

첫 번째 예제에서 책은 제품 데이터베이스의 책 파티션에 추가됩니다.

그런 다음, 다른 문서를 DVD 파티션에 추가하고 하우스홀드 파티션에 세 번째 문서를 추가합니다.

이 영향으로 파티션 키를 공유하는 문서가 데이터베이스의 동일한 샤드에 상주합니다. 동일한 파티션에 있는 문서는 문서 키 순서로 함께 저장됩니다.

데이터를 검색할 때 이점이 있습니다. 단일 파티션에서 IBM Cloudant 조회, MapReduce 요청 및 검색을 지시할 수 있습니다. 이 예에서는 IBM Cloudant 조회 선택기가 book 파티션으로 전송됩니다. 이 조치는 IBM Cloudant 인프라의 일부만을 실행함을 의미합니다(서적 파티션을 호스팅하는 샤드만 사용되고, 나머지 클러스터는 유휴 상태임).

이 시나리오에서는 더 빠른 조회 성능, 저렴한 조회 비용 및 향상된 확장성을 제공합니다.

파티션된 조회 성능을 높이려면 파티션 키를 선택해야 합니다.

데이터 세트 내에서 반복되는 값이 있어야 합니다. 예를 들어, book 파티션에 여러 항목이 있습니다. 많은 파티션이 필요합니다. 카테고리가 몇 개만 있는 경우에는 카테고리는 파티션 키의 올바르지 않은 선택입니다. 예를 들어, IoT 애플리케이션의 deviceId 또는 전자 상거래 시스템의 orderId와 같은 많은 값이 있어야 합니다. 애플리케이션이 만들고 있는 조회와 일치해야 합니다. 가장 일반적인 유스 케이스가 제품 카테고리 내에서 검색 중인 경우 카테고리별 파티셔닝이 적합할 수 있습니다. 핫 파티션 금지 - 트래픽이 파티션 전반에 균등하게 분산되어야 합니다. 파티션 키를 선택하여 일부 파티션에 도달하는 트래픽이 크게 증가할 경우 이 시나리오에서는 파티션 키를 선택하지 않을 수 있습니다.

요약하면, 파티션된 데이터베이스는 partitioned=true 플래그를 사용하여 작성되며 문서에는 파티션 키 및 문서 키가 쉼표로 결합되는 두 파트의 ID가 있습니다.

동일한 파티션의 문서는 동일한 데이터베이스 샤드의 문서 키 순서로 저장됩니다. 이 스토리지의 메소드를 알고 있으면 더욱 빠르고 더욱 경제적으로 실행되는 단일 파티션에 지시된 조회를 수행할 수 있습니다.

파티션된 데이터베이스에서 파티션 간의 조회는 계속해서 가능합니다. 2차 인덱스를 작성하는 경우 목적이 파티션당인지 아니면 글로벌 범위인지를 선택합니다.

이 파트의 끝입니다. 다음 파트는 IBM Cloudant 검색입니다.

IBM Cloudant 동영상 스크립트 검색

IBM Cloudant 오신 것을 환영합니다. 이 과정은 17개의 비디오 시리즈로 구성되어 있으며, IBM Cloudant 대한 개요를 제공합니다.

본 동영상은 파트 16 - IBM Cloudant 검색입니다.

이 파트에서 간단하게 탐색하는 IBM Cloudant 검색이라고 하는 IBM Cloudant에서 조회하고 인덱싱할 수 있는 또 다른 방법이 있습니다.

IBM Cloudant 검색은 다른 오픈 소스 프로젝트인 Apache Lucene에 빌드되며, 이는 Elasticsearch를 포함하는 많은 제품의 검색 기능을 구동합니다.

이는 주로 텍스트의 블록이 인덱싱되기 전에 사전 처리되는 무료 텍스트 검색을 위해 설계되었습니다. 대소문자, 구두점, 일반적인 불용어 제거 및 공통 언어별 단어 어미 잘라내기가 해당됩니다. 예를 들면, farmer becomes farm 및 farms becomes farm입니다.

이 텍스트 처리는 검색 전에 조회 시 선택한 분석기에서 수행됩니다. 이전에는 패싯이라고 하는 기술을 사용하는 일부 집계 기능도 허용되었습니다.

IBM Cloudant 검색 인덱스는 JavaScript 함수를 제공하여 작성됩니다. MapReduce와 같지 않습니다. 이번에는 생성 함수가 필드의 이름, 데이터 자체 및 일부 옵션을 예상하는 인덱스 함수로 대체되는 점이 다릅니다.

이 예제에서 문서 이름과 제목은 기본 옵션으로 인덱싱됩니다. 카테고리는 패싯(집계 기능)을 위해 지정되고 ISBN은 인덱스에 저장되지만 검색 자체를 위해서는 인덱싱되지는 않습니다. 때때로 조회 시 include_docs=true를 수행하지 않고 인덱스에 일부 항목을 저장하는 것이 좀 더 효율적입니다.

Lucene에는 로직, 퍼지 일치, 범위 및 용어 부스팅과 관련된 절의 조합과 일치하는 조회를 작성하는 자체 조회 언어가 있습니다.

다음 예를 참조하십시오.

• 제목이 gastby와 일치하고 작성자가 fitz로 시작하는 문서를 찾습니다. 별표 와일드 카드를 확인하십시오.
• author가 austen to dickens 범위에 있는 문서를 찾으십시오. 이 예에서는 문자열 필드에 대한 범위 조회를 표시합니다.
• 가격이 0 - 100이고(AND) 연도가 19th century이거나 작가가 charles dickens와 일치하는 문서를 찾으십시오. . 이 예에서는 로직이 조회로 빌드될 수 있는 방법을 보여줍니다.

IBM Cloudant 검색은 자유 텍스트 검색에만 유용합니다. 또한 검색할 속성을 알고 있는 경우에도 유용합니다. 그러나 매번 다른 속성 조합을 사용하여 조회가 다양합니다. 이 유연성은 고정 순서 MapReduce 인덱스로 구현하기가 어렵습니다.

패싯은 집계의 한 형태입니다. 인덱스 타임에 패싯할 개별 인덱스 필드를 지정하고 조회 시 매개변수를 사용하여 집계를 활성화합니다.

두 가지 용도로 사용됩니다.

결과 세트의 각 카테고리에 속하는 제품 수와 같은 결과 세트의 반복 값 계산. 또는 각 가격 범위의 제품 수와 같이 숫자 범위의 항목 수 계산. 이러한 두 가지 양식으로 된 수는 검색의 범위를 좁히기 위해 기존의 검색을 추가로 필터링하는 수단으로 프론트 엔드 사용자에게 제공될 수 있습니다. 예를 들어, 고객은 Fender를 검색하고 Amps 를 클릭한 후 under $500의 가격 범위를 클릭합니다. 이 검색 및 필터링은 모두 IBM Cloudant 검색으로 구동될 수 있습니다.

요약하면, IBM Cloudant 검색 인덱스가 제공된 JavaScript 함수로 정의됩니다. Apache Lucene을 기반으로 하며 자유 텍스트 검색 일치에 주로 사용되지만 조회 언어는 고정된 인덱스 필드 세트에서 유연한 조회를 작성하는 데 유용합니다. 또한 드릴 다운 사용자 인터페이스에 적합한 일부 강력한 계수 집계가 있습니다.

IBM Cloudant 검색은 또한 type=text IBM Cloudant 조회 인덱스를 구동하므로 _find API를 사용하여 해당 기능의 서브세트가 표시됩니다.

이 파트의 끝입니다. 다음 파트는 Under the hood입니다.

Under the hood 동영상 스크립트

IBM Cloudant 오신 것을 환영합니다. 이 과정은 17개의 비디오 시리즈로 구성되어 있으며, IBM Cloudant 대한 개요를 제공합니다.

이 영상은 17부 - 내부 이야기 입니다.

IBM Cloudant 서비스의 구성 방법 살펴보기: 이 개요는 CouchDB 2 및 3에 맵핑되는 IBM Cloudant 서비스에 적용됩니다. CouchDB 4는 다른 기술 위에 구축되어 있습니다.

IBM Cloudant는 스토리지 노드의 클러스터 주변에 저장된 데이터가 있는 분산 데이터베이스입니다. IBM Cloudant 서비스를 노드의 링으로 표현합니다. 이 경우에는 12입니다. 모든 노드는 들어오는 API 호출을 처리 할 수 있으며 모든 노드는 클러스터에 있는 데이터베이스의 샤드 및 관련 2차 인덱스와 같은 일부 데이터를 저장해야 합니다.

데이터가 IBM Cloudant에 작성되면 링의 노드 중 하나가 요청을 처리합니다. 작업은 데이터의 세 개의 사본이 세 개의 스토리지 노드에 저장되도록 지시하는 것입니다. 데이터는 IBM Cloudant에 삼중으로 저장되므로, 데이터베이스의 각 샤드는 종종 지역의 가용성 구역에 여러 번 저장됩니다.

API를 호출하여 데이터를 작성하고 응답을 다시 받는 경우 데이터를 세 개의 스토리지 노드 중 적어도 두 개에 작성합니다. 데이터가 디스크로 비워집니다. 데이터가 비워지도록 메모리에 캐시되지 않습니다. 이 기술은 너무 위험하고 데이터 손실이 발생하기 쉽다고 생각합니다.

데이터베이스를 만들면 클러스터 주위에 퍼져있는 많은 데이터베이스 샤드(기본적으로 16 개)가 만들어집니다. 각 샤드의 사본이 세 개 존재하며, 이 사본은 48개의 샤드 사본과 같습니다.

이 활동을 볼 수 없습니다. 활동은 데이터베이스를 작성할 때 투명하게 처리됩니다.

유지보스를 위해 노드가 중지되거나 재부팅해야 하는 경우 어떻게 됩니까? 나머지 클러스터는 정상적으로 계속됩니다. 대부분의 샤드에는 여전히 세 개의 데이터 사본이 있지만 일부는 두 개만 있습니다. API 호출은 계속 정상적으로 작동하며, 두 개의 데이터 사본만 작성됩니다.

두 개의 노드가 작동 중지되더라도 대부분의 샤드에는 계속해서 세 개의 사본이 있습니다. 일부는 두 개, 일부는 한 개가 있습니다. HTTP 응답 코드는 두 노드 확인의 쿼럼에 도달하지 않았음을 반영하지만 작성은 계속됩니다.

같은 이야기입니다. 실패한 노드로 서비스가 계속됩니다. 하나의 실패한 노드 또는 더 많은 실패한 노드에서

살아남을 수 있습니다. 각 노드의 사본이 존재하면 API가 계속 작동합니다.

노드가 리턴하면 피어에서 누락된 데이터를 발견한 후 서비스로 리턴하며, API 호출을 처리하고 데이터에 대한 조회에 응답합니다.

이 구성의 특성은 IBM Cloudant 결과적 일관성을 유지하는 것입니다. 모든 노드가 요청을 처리할 수 있습니다. 데이터는 관계형 데이터베이스에서 볼 수 있는 일종의 잠금 없이 노드 주변에 분산됩니다.

IBM Cloudant 일관성보다 가용성을 중시: 일관성을 보장할 수 없기 때문에 작동 중지되는 것보다 작동하여 API 호출에 응답하는 것이 좋습니다. (관계형 데이터베이스는 종종 반대로 구성됩니다. 이는 일관된 방식으로 작동하거나 전혀 작동하지 않습니다.) 개발자가 결과적 일관성을 유지하게 되면 앱이 짧은 시간 내에 read its writes 않아야 합니다. 업데이트한 문서보다 이전 버전의 문서를 볼 수 있는 작은 시간 창이 있을 수 있습니다. 결과적으로 데이터는 클러스터 주변을 플로우합니다. 대부분의 경우, 쿼럼 메커니즘은 일관성의 환상을 제공하지만 이에 의존하지 않는 것이 좋습니다.

CouchDB 4에서는 해당 코드 버전을 기반으로 하는 IBM Cloudant 서비스에서 다른 일관성 모델이 사용됩니다.

데이터 모델이 짧은 시간 창에서 계속해서 문서를 업데이트해야 하는 경우 동일한 개정 번호에 대한 다중 쓰기가 허용될 수 있습니다. 이러한 쓰기는 충돌로 알려진 개정 트리의 분기로 이어집니다. 이 예제에서 개정 2는 두 가지 다른 방법으로 수정되어 두 개의 개정 3s가 발생했습니다. 프로그래밍 방식으로 충돌을 정리할 수는 있지만 극단적인 상황에서는 성능 문제를 발생시킬 수 있으므로 피해야 합니다.

복제를 사용하고 문서가 다른 방법으로 수정된 후 충돌하는 개정이 복제를 사용하여 병합되는 경우에도 충돌이 발생할 수 있습니다. IBM Cloudant에서는 이 시나리오에서 데이터를 버리지 않습니다. winning 의 개정판이 선택되었지만, 낙선된 개정판에 액세스할 수 있으며, 새로운 개정판을 선택하거나, 원치 않는 개정판을 삭제하거나, 필요한 조치를 취함으로써 충돌을 해결할 수 있습니다. 충돌은 오류 조건이 아니며 이는 잠금 없이 수정할 수 있는 데이터의 연결이 끊긴 사본을 보유한 부수적인 효과입니다. IBM Cloudant에서는 충돌 변경사항을 버리지 않고 충돌을 저장하여 충돌을 처리하도록 선택합니다.

문서가 충돌하는지 확인하려면 단일 문서의 페치에 ?conflicts=true를 추가하면 됩니다. 충돌하는 개정이 _conflicts 배열에 나열됩니다.

원하지 않은 개정은 일반 DELETE 오퍼레이션을 사용하여 제거할 수 있으며, 삭제할 개정의 rev 토큰을 지정합니다. 대량 API는 동일한 문서에서 여러 개의 충돌을 제거하는 경우에도 충돌하는 개정을 제거하는 데 유용합니다.

요약하자면, IBM Cloudant은(는) 여러 샤드로 구분된 데이터베이스를 저장하는 분산 서비스이며, 각 샤드의 세 개의 사본은 스토리지 노드의 링 주위에 분산됩니다. IBM Cloudant은(는) 결국에는 일관적이며, 강력한 일관성을 통해 높은 가용성을 제공합니다.

충돌을 일으키지 않도록 반복해서 동일한 문서에 작성하지 마십시오 복제 상황에서는 충돌이 불가피한 경우도 있습니다.

결과적 일관성 수용- IBM Cloudant 일관성을 유지하려고 하지 마십시오.

IBM Cloudant CouchDB 4를 기반으로 하는 제품에는 다른 일관성 모델이 있을 수 있습니다.

이제 이 과정이 끝났습니다. 자세한 정보는 IBM Cloudant 와 블로그를 참조하세요.