IBM Cloudant에 연결

IBM Cloudant에 액세스하려면 IBM Cloud® 계정이 있어야 합니다.

HTTP API

IBM Cloudant에 대한 모든 요청은 웹을 통해 전달됩니다. 이 문장은 웹과 대화할 수 있는 모든 시스템이 IBM Cloudant와 대화할 수 있음을 의미합니다. 모든 IBM Cloudant용 특정 언어 라이브러리는 단지 사용자가 단순한 API에 대해 작업할 수 있도록 도움을 주기 위해 몇 가지 편의성과 언어적 편리성을 제공하는 랩퍼에 불과합니다. IBM Cloudant 작업용 도구로 원시 HTTP 라이브러리를 선택하는 사용자도 많습니다.

IBM Cloudant가 HTTP를 사용하는 방법에 대한 자세한 정보는 API 참조의 HTTP를 참조하십시오.

IBM Cloudant는 다음 HTTP 요청 메소드를 지원합니다.

GET

지정된 항목을 요청합니다. 보통 HTTP 요청과 마찬가지로, URL의 형식이 리턴되는 항목을 정의합니다. IBM Cloudant의 경우 이 정의에는 정적 항목, 데이터베이스 문서, 구성 및 통계 정보가 포함될 수 있습니다. 대부분의 경우 정보는 JSON 문서 양식으로 리턴됩니다.

HEAD

HEAD 메소드는 응답의 본문 없이 GET 요청의 HTTP 헤더를 검색합니다.

POST

데이터를 업로드합니다. IBM Cloudant의 API에서 POST 메소드는 값을 설정하고, 문서를 업로드하고, 문서 값을 설정하고, 몇 가지 관리 명령을 시작하는 데 사용됩니다.

PUT

특정 리소스를 "저장"하는 데 사용됩니다. IBM Cloudant의 API에서 PUT은 데이터베이스, 문서, 보기, 디자인 문서를 포함한 새 오브젝트를 작성하는 데 사용됩니다.

DELETE

문서, 보기 및 디자인 문서를 포함한 지정된 리소스를 삭제합니다.

COPY

문서와 오브젝트를 복사하는 특별한 방법입니다.

클라이언트(예: 일부 웹 브라우저)에서 HTTP 메소드의 사용을 지원하지 않을 경우 POST 요청 헤더가 실제 HTTP 메소드로 설정된 X-HTTP-Method-Override를 대신 사용할 수 있습니다.

{
    "error":"method_not_allowed",
    "reason":"Only GET,HEAD allowed"
}

JSON

IBM Cloudant는 JSON(JavaScript Object Notation) 인코딩을 사용하여 문서를 저장하므로, JSON으로 인코딩된 모든 항목은 문서로 저장할 수 있습니다. 미디어를 포함하는 파일, 이미지와 같은 동영상 및 오디오, BLOB(Binary Large Object)이라고 합니다. BLOB은 문서와 관련된 첨부 파일로 저장할 수 있습니다.

JSON에 대한 자세한 정보는 JSON 안내서에서 찾을 수 있습니다.

분산 시스템

IBM Cloudant의 API를 통해 클러스터라고 불리는 여러 시스템의 협업과 상호작용을 할 수 있습니다. 클러스터에 속한 시스템들은 동일한 데이터 센터에 있어야 하지만 데이터 센터 내의 "팟(Pod)"은 서로 다를 수 있습니다. 서로 다른 팟(Pod)을 사용하면 IBM Cloudant의 고가용성 특성이 향상됩니다.

클러스터링의 장점은 추가 컴퓨팅 능력이 필요한 경우 시스템만 추가하면 된다는 점입니다. 이 방법은 일반적으로 기존의 한 시스템을 확장하거나 업그레이드하는 것보다 비용 효율적이며 결함에 대한 내성이 더 높습니다.

IBM Cloudant와 분산 시스템 개념에 대한 자세한 정보는 CAP 정리 안내서를 참조하십시오.

복제

복제 는 IBM Cloudant이 뒤에 오는 프로시저입니다. CouchDB, PouchDB및 기타 분산 데이터베이스 복제는 컨텐츠가 동일해지도록 두 데이터베이스의 상태를 동기화합니다.

복제는 지속적으로 수행할 수 있습니다. 이는 소스 데이터베이스가 변경될 때마다 대상 데이터베이스가 업데이트됨을 의미합니다. 연속 복제는 데이터 백업, 여러 데이터베이스의 데이터 집계 또는 데이터 공유에 사용할 수 있습니다.

그러나 연속 복제는 모든 소스 데이터베이스 변경사항에 대해 테스트가 수행됨을 의미합니다. 이 테스트는 지속적인 내부 호출을 필요로 하며, 이는 성능 또는 데이터베이스 사용 비용에 영향을 줄 수 있습니다.

연속 복제로 인해 많은 내부 호출이 발생할 수 있습니다. 이러한 호출은 IBM Cloudant 시스템의 멀티 테넌트 사용자의 비용에 영향을 줄 수 있습니다. 연속 복제는 기본적으로 사용 안함으로 설정되어 있습니다.

작업에 적합한 도구 사용

IBM Cloudant는 확장할 수 있고, 내구성이 높으며, 고가용성인 운영 JSON 문서 저장소(HTTP API 사용)입니다. 다음 목적에 적합합니다.

• 항상 연결되는 웹 애플리케이션을 구동합니다.
• 모바일 애플리케이션을 위한 서버 측 데이터 저장소가 됩니다.
• 오브젝트 스토리지에 아카이브하고 원본을 삭제하기 전에 기간이 고정된 데이터베이스에 시계열 데이터를 저장합니다.
• 2차 인덱스에서 조회를 제공하는 동안 JSON으로 애플리케이션 오브젝트를 저장합니다.
• 재해 복구, 추가 용량 또는 사용자에게 좀 더 가까운 위치로의 데이터 이동을 위해 지역에 걸쳐 데이터 세트를 복제합니다.

IBM Cloudant에는 다음 기능이 포함되어 있지 않습니다.

• 대기 시간이 짧은 인메모리 데이터 저장소. 자세한 정보는 IBM Cloud® Databases for Redis를 참조하십시오.
• 데이터 아카이브를 위한 제한 없는 오브젝트 저장소. 자세한 정보는 IBM Cloud Object Storage를 참조하십시오.
• SQL 조회, 저장된 프로시저 및 제한조건과 트리거를 사용하는 관계형 데이터베이스. 자세한 정보는 IBM Cloud Databases for PostgreSQL을 참조하십시오.
• 큐. 자세한 정보는 IBM MQ를 참조하십시오.

자세한 정보는 Best and Worst Practice 블로그를 참조하십시오.

문서 및 데이터베이스 구성

IBM Cloudant 데이터는 데이터베이스 및 문서의 계층 구조로 구성됩니다. 문서는 _id의 고유 ID가 있는 JSON 오브젝트입니다. 데이터베이스는 _id로 문서를 검색할 수 있도록 해주는 1차 인덱스가 포함된 문서의 콜렉션입니다. 또한 오브젝트의 다른 속성으로 문서를 조회할 수 있도록 해주는 선택적 2차 인덱스도 포함될 수 있습니다.

개발자가 프로젝트를 시작할 때 다음과 같은 질문을 해결하도록 노력을 기울이기도 합니다.

• 단일 오브젝트에 배치할 수 있는 데이터의 양은 어떻게 됩니까?
• 동일한 콜렉션에 다른 문서 유형을 저장해야 합니까, 아니면 문서 유형당 하나의 데이터베이스를 저장해야 합니까?

문서에 애플리케이션을 통해 모델링된 오브젝트에 대한 모든 데이터(예: 사용자, 주문 또는 제품)가 포함되는 것이 중요합니다. 이렇게 하면 하나의 API 호출로 데이터베이스에서 전체 오브젝트를 페치할 수 있습니다. IBM Cloudant에는 관계형 데이터베이스와 같은 결합의 개념이 없으므로, 이는 정규화되지 않습니다. 그러나 데이터는 오브젝트 간에 반복될 수 있습니다. 예를 들어, 주문 문서에는 구입한 제품 문서의 서브세트가 포함될 수 있습니다.

동일한 데이터베이스에 여러 오브젝트 유형을 저장하는 것이 일반적입니다. 규칙에 따라 type 속성이 오브젝트 유형을 선언하는 데 사용됩니다. 이 옵션은 여러 오브젝트 유형을 리턴하는 조회를 수행해야 하거나 데이터베이스가 함께 다른 위치에 복제되어야 하는 경우 유용합니다. 그렇지 않으면, 2차 인덱스가 각 오브젝트 유형에 특정하도록 users, orders, products와 같은 별도의 데이터베이스가 좀 더 적합할 수 있습니다.

문서 내에 오브젝트 배열을 저장하는 경우 배열 항목이 실제로 고유한 문서여야 하는지 여부를 고려하십시오. 예를 들어, 제품 및 각 제품평은 별도의 문서에 저장되어야 하지만 사용자 및 해당 사용자의 주문마다 고유한 문서가 있어야 합니다.

계속해서 증가하는 데이터 세트가 있으면 계속해서 증가하는 단일 데이터베이스에 데이터를 저장하지 않을 가능성이 높습니다. 데이터는 이전 데이터를 아카이브하고 완전히 삭제할 수 있는 기간이 고정된 데이터베이스에 가장 완벽하게 저장됩니다. IBM Cloudant 문서를 삭제하면 표식 문서가 남게 되므로, 디스크 공간을 복구하려면 문서 삭제에 의존하지 마십시오. 대신, 전체 데이터베이스 삭제에 의존해야 합니다.

JSON은 날짜 또는 시간소인을 저장하기 위한 기본 방법을 제공하지 않습니다. 나중에 조회할 경우 날짜 형식을 신중하게 선택하십시오.

최대 문서 크기는 1MB이지만, 문서의 크기는 해당 크기보다 훨씬 작아야 합니다(일반적으로 크기가 작은 KB임).

자세한 정보는 다음 블로그 게시물을 참조하십시오.

• Optimal IBM Cloudant Indexing
• Time-series Data Storage
• Partitioned databases - data design

1차 인덱스를 최대한 활용

IBM Cloudant에는 문서의 _id 속성에 대한 1차 인덱스가 있습니다. 이 인덱스를 사용하면 _id (GET /db/id) 또는 _ids (GET /db/_all_docs?startkey="a"&endkey="z")의 범위에서 문서를 검색할 수 있습니다. 기본 키에 데이터를 저장하고 각 _id가 고유한지 확인하여, 1차 인덱스를 사용하여 2차 인덱싱을 수행하지 않고 문서 및 문서 범위를 페치할 수 있습니다. 다음과 같은 아이디어 목록을 참조하십시오.

• 조회하는 데 유용한 오브젝트에 고유한 항목이 있는 경우 _id 필드로 이를 사용하십시오(예: bob.smith@gmail.com, isbn9780241265543 또는 oakland,ca).
• 오브젝트에 계층 구조가 포함된 경우 _id에 해당 계층 구조를 모델링하십시오(예: usa:ca:oakland 또는 books:fiction:9780241265543). 계층 구조는 가장 큰 값에서 가장 작은 값으로 이동하므로 1차 인덱스를 사용하여 2차 인덱싱 없이 usa의 모든 도시 또는 usa:ca의 모든 도시를 찾을 수 있습니다.
• 시계열 데이터를 저장하는 경우 _id 시작 시 인코딩 시간은 시간별로 1차 인덱스를 정렬합니다(예: 001j40Ox1b2c1B2ubbtm4CsuLB4L35wQ).
• 파티셔닝된 데이터베이스는 동일한 파티션 키를 함께 공유하는 문서를 그룹화합니다. 파티션 키에는 많은 값이 있어야 하며 애플리케이션 트래픽 중 많은 비율이 일부 파티션으로 이동하지 않도록 핫 스팟이 포함되면 안 됩니다.

자세한 정보는 다음 블로그 게시물을 참조하십시오.

• Time-sortable _ids
• Introduction to partitioned databases

조회 및 2차 인덱스

IBM Cloudant를 사용하면 조회가 일치하는 문서 및 책갈피의 배열을 리턴하는 단일 데이터베이스에 대해 실행될 수 있으며, 다음 블록의 검색 결과에 액세스할 수 있습니다. 더 나은 조회 성능의 달성은 조회가 적합한 2차 인덱스를 통해 지원되는지 여부에 따라 달라집니다. 인덱스를 사용하면 데이터베이스의 모든 문서를 조사하지 않고도 조회에 응답할 수 있으며, 이에 따라 더욱 빠르게 성능이 구현됩니다.

다음 팁을 참조하십시오.

• 데이터 세트의 양이 느린 오퍼레이션을 노출할 정도로 많기 전까지는 조회의 성능을 측정하는 데 어려움을 겪기도 합니다. 프로덕션 상태에 이르기 전에 인덱싱 및 조회 성능을 테스트할 수 있도록 충분한 실제 데이터를 생성하십시오.
• IBM Cloudant는 인덱스 없이 데이터를 사용자에게 리턴할 수 있으나, 사용자는 프로덕션 워크로드에 대해 이 데이터에 의존하면 안 됩니다. 결과 세트에 경고가 포함된 경우 No matching index found. Create an index to optimize query time, 그런 다음 인덱싱 전략을 다시 방문해야 합니다. 설명 기능을 사용하여 각 조회에 선택되는 인덱스를 확인하십시오.
• 동일한 데이터베이스에 여러 개의 오브젝트 유형을 사용하면 고정된 속성에 대한 몇 가지 인덱스로 많은 유스 케이스를 제공할 수 있습니다. 자세한 정보는 Optimal IBM Cloudant Indexing을 참조하십시오.
• 애플리케이션의 조회와 일치하는 인덱스가 명확해지도록 인덱스에 의미 있는 이름을 제공하고 조회 시간에 인덱스 이름을 지정하십시오.

자세한 정보는 다음 블로그 게시물을 참조하십시오.

• 샘플 데이터 생성
• Optimal IBM Cloudant Indexing