대상으로 할 API 이해

다음을 사용할 수 있습니다 Java™, Python, Go 또는 Node.js 또는 기타 사용 사례별 언어 또는 플랫폼을 사용할 수 있습니다. 이러한 언어 중 하나는 도구에 대해 예상하는 규칙에 따라 IBM Cloudant 액세스를 원활하게 통합하는 편리한 클라이언트 측 라이브러리와 함께 제공될 가능성이 높습니다. 이러한 언어는 프로그래머 효율성에 매우 좋지만 API를 보기에서 숨깁니다.

이 추상화는 사용자가 원하는 것이며, 클라이언트 라이브러리를 사용하는 이유의 전부는 반복되고 지루한 보일러 플레이팅을 저장하는 것입니다. 하지만 문제를 해결하거나 보고할 때는 해당 API의 기본 원리를 이해하는 것이 매우 중요하다는 점을 명심해야 합니다. 의심되는 문제점을 IBM Cloudant에 보고할 때 문제점을 재현할 수 있는 방법을 제공할 수 있으면 지원하는 데 도움이 됩니다.

이 요청은 애플리케이션 Java™ 소스의 많은 청크를 그대로 잘라서 지원 티켓이 붙여넣는 것을 의미하지 않습니다. 아마 빌드하지 못할 것이기 때문입니다. 또한 클라이언트 측 코드는 문제점이 있을 수 있는 위치(클라이언트 측 또는 IBM 측)에 대해 불확실성을 유발합니다.

대신, IBM Cloudant 의 지원팀은 일반적으로 문제를 재현할 수 있는 일련의 API 호출을 요청하며, 가급적이면 지원팀이 직접 실행할 수 있는 curl 명령어 세트 형태로 제공해 주기를 바랍니다. 또한 이 문제점 해결 접근법을 규칙으로 채택하면 문제가 발생하는 지점을 쉽게 파악할 수 있습니다. 코드가 예기치 않게 작동하는 경우 API에 대한 직접 액세스만 사용하여 문제를 재현해 보십시오.

재현할 수 없다면 IBM Cloudant 서비스 자체에 문제점이 있는 것이 아닙니다.

성능 문제를 조사하는 경우 IBM Cloud®에서 제공하는 로그를 참조하십시오. 로그에 IBM Cloudant가 요청을 빠르게 처리하는 것으로 표시되어 있지만 애플리케이션이 느린 경우 문제점의 근본 원인은 클라이언트 측 애플리케이션 코드에 있습니다. 로깅 및 모니터링에 대한 규칙을 참조하십시오.

공식적으로 지원되는 클라이언트 라이브러리에 문제점이 있다고 의심되는 경우 문제를 보여주는 자체 포함된 작은 코드 예제를 구성해 보십시오. 이 자체 포함된 코드 예제에서는 가능한 적은 수의 다른 종속 항목을 사용하십시오. Java™ 를 사용 중이시라면, 최소한의 테스트 환경을 활용해 라이브러리 문제를 명확히 지적해 주시면 저희에게 큰 도움이 됩니다.

때때로 IBM Cloudant는 지지 증거가 별로 없이 "내 애플리케이션이 느려서 IBM Cloudant가 중단되었음"을 나타내는 지원 티켓을 받습니다. 이 케이스는 대체로 클라이언트 측의 애플리케이션 코드 문제 또는 IBM Cloudant 작동 방식에 대한 오해로 인한 것일 수 있습니다.

항상 그런 것은 아니지만 거의 언제나 그렇습니다.

API를 더 잘 이해하면 특히 성능 측면에서 IBM Cloudant의 작동 방식에 대한 경험을 얻을 수 있습니다. 클라이언트 라이브러리를 사용하는 경우 최소한 특정 함수 호출로 생성되는 HTTP 요청을 찾는 방법을 아는 것을 목표로 해야 합니다. 자세한 정보는 다음 웹 사이트를 참조하십시오.

• IBM Cloudant API 문서
• 로깅 통합
• 로깅 관련 블로그 게시물

문서는 주로 함께 변경되는 데이터를 그룹화해야 함

데이터 모델링을 시작하면 조만간 문서가 구조화되는 방법에 대한 문제에 직면하게 됩니다. 이제 IBM Cloudant 가 어떠한 정규화도 강제하지 않으며, 예를 들어 Postgres 에서 익숙한 유형의 트랜잭션이 없다는 사실을 알게 되셨을 것입니다. 각 문서에 가능한 많이 집어넣고 싶다고 생각할 수 있으며, 이는 HTTP 사용을 줄일 수도 있습니다.

이 관행은 종종 잘못된 생각입니다.

모델이 함께 변경되지 않는 정보를 그룹화하면 업데이트 충돌이 발생할 가능성이 높습니다.

각 사용자와 연관된 주문 세트가 있는 사용자가 있는 상황을 고려하십시오. 한 가지 방법은 사용자 문서에서 주문을 배열로 나타내는 것일 수 있습니다.

{ // DON'T DO THIS
  "customer_id": 65522389,
  "orders": [
    {
      "order_id": 887865,
      "items": [
        {
          "item_id": 9982,
          "item_name": "Iron sprocket",
          "cost": 53.0
        },
        {
          "item_id": 2932,
          "item_name": "Rubber wedge",
          "cost": 3.0
        }
      ]
    }
  ]
}

주문을 추가하려면 전체 문서를 페치하고, JSON을 역마샬링하고, 항목을 추가하고, 새 JSON을 마샬링하고, 이를 업데이트로 다시 보내야 합니다. 한 사용자만 이를 수행한다면 한동안 작동할 수 있습니다. 문서가 동시에 업데이트되거나 복제되는 경우 업데이트 충돌이 발생할 수 있습니다.

대신, 고객 ID를 참조하여 주문을 고유한 문서 유형으로 구분하여 보관하십시오. 이제 모델은 변경 불가능합니다. 주문을 추가하려면 데이터베이스에 새로운 주문 문서를 생성하는데, 이 과정에서 충돌이 발생하지 않습니다.

특정 고객에 대한 모든 주문을 검색할 수 있도록 나중에 설명하는 보기를 사용할 수 있습니다.

가능하면 기존 문서의 일부에 대한 업데이트에 의존하는 구성을 피하십시오. 부적절한 데이터 모델은 일단 실제 운영 환경에 배포된 후에는 변경하기가 어려운 경우가 많습니다.

이전 패턴은 파티션된 데이터베이스를 사용하여 효율적으로 해결할 수 있으며, 이는 나중에 자세히 설명됩니다.

자세한 정보는 다음 문서를 참조하십시오.

• 데이터 모델링에 대한 IBM Cloudant 안내서
• 데이터베이스 파티션

문서를 작게 유지

IBM Cloudant는 최대 문서 크기를 1MB로 지정합니다. 이 한계는 1MB에 가까운 문서 크기가 좋은 아이디어라는 것을 의미하지는 않습니다. 반대로 한 자릿수 KB를 초과하는 문서를 작성하는 경우 모델을 다시 방문해야 할 수 있습니다. IBM Cloudant의 몇 가지 항목은 문서가 증가함에 따라 성능이 저하됩니다. 예를 들어, JSON 디코딩은 비용이 많이 듭니다.

문서는 주로 함께 변경되는 데이터를 그룹화해야 함 및 문서를 작게 유지 절을 살펴보겠습니다. 업데이트에 의존하는 모델의 최대 볼륨 한계는 문서 크기의 컷오프인 1MB라는 점을 강조할 필요가 있습니다. 이 크기는 사용자가 원하는 크기가 아닙니다.

첨부 파일 사용 안함

IBM Cloudant는 CouchDB에서 상속된 오래된 기능인 첨부 파일을 문서와 함께 저장하는 기능을 지원합니다. 웹 애플리케이션의 백엔드로 IBM Cloudant 를 사용하는 경우, 데이터와 함께 작은 아이콘이나 CSS, JavaScript 파일과 같은 기타 정적 리소스도 저장할 수 있습니다.

특히 이미지 및 비디오와 같은 더 큰 자산을 살펴보는 경우에는 현재 IBM Cloudant에서 첨부 파일을 사용하기 전에 몇 가지 사항을 고려해야 합니다.

1. IBM Cloudant는 블록 저장소로 비용이 많이 듭니다.
2. IBM Cloudant의 내부 구현은 대량의 2진 데이터를 처리하는 데 효율적이지 않습니다.

따라서 느리고 비용이 많이 듭니다.

IBM Cloudant는 소규모 자산 및 가끔 사용하는 경우에 적합합니다. 일반적으로 IBM Cloudant 문서와 함께 2진 데이터를 저장해야 하는 경우에는 이 목적에 더 맞는 별도의 솔루션을 사용하는 것이 좋습니다. IBM Cloudant 문서에는 첨부 파일의 메타데이터 만 저장하면 됩니다. 예, 이는 사용자가 선택한 적절한 블록 저장소에 첨부 파일을 업로드하려면 일부 추가 코드를 작성해야 함을 의미합니다. 첨부 파일에 대한 토큰 또는 URL을 IBM Cloudant 문서에 저장하기 전에 성공했는지 확인하십시오.

데이터베이스는 더 작고, 저렴하고, 빠르고, 복제하기 쉽습니다. 자세한 정보는 다음 웹 사이트를 참조하십시오.

• 첨부 파일에 대한 IBM Cloudant 문서
• IBM Cloudant 첨부 파일 분리하기 Object Storage

적은 수의 데이터베이스가 많은 것보다 나음

가능한 경우 IBM Cloudant 계정당 데이터베이스 수를 500개 이하로 제한하십시오. 이 특정 수는 매직 넘버가 아니지만(IBM Cloudant는 더 많이 안전하게 처리할 수 있음) 계정에 있는 많은 수의 데이터베이스에 부정적인 영향을 받는 몇 가지 유스 케이스가 있습니다.

복제자 스케줄러에는 실행할 준비가 되어 있는 제한된 수의 동시 복제 작업이 있습니다. 데이터베이스 수가 증가함에 따라 계정에 포함된 모든 항목을 복제하려고 하면 복제 대기 시간이 늘어날 수 있습니다.

동전의 이면은 운영 측면입니다. IBM Cloudant 운영 팀에서는 계정을 이동하기 위해 복제에도 의존합니다. 데이터베이스 수를 줄이면 계정을 한 위치에서 다른 위치로 이동해야 하는 경우 도움이 됩니다.

그렇다면 언제 단일 데이터베이스를 사용하고 보기를 사용하여 여러 문서 유형을 구분해야 하며 언제 다중 데이터베이스를 사용하여 데이터를 모델링해야 합니까? IBM Cloudant는 여러 데이터베이스에 걸쳐 보기를 연합할 수 없습니다. “조인”하거나 함께 쿼리할 수 없는, 서로 관련이 없는 데이터가 있다면, 해당 데이터는 여러 데이터베이스에 분산 저장할 대상이 될 수 있습니다.

계속 증가하는 데이터 세트(예: 로그, 센서 표시값 또는 기타 유형의 시계열)가 있는 경우 계속 증가하는 단일 데이터베이스를 작성하는 것도 좋지 않습니다. 이러한 종류의 유스 케이스에는 타임박싱(time-boxing)이 필요하며, 이는 나중에 자세히 다룹니다.

‘사용자별 데이터베이스’라는 안티패턴은 마치 전염병처럼 피해야 한다

IBM Cloudant 를 기반으로 다중 사용자 서비스를 구축하는 경우, 각 사용자가 애플리케이션 계정 하위의 별도 데이터베이스에 자신의 데이터를 저장하도록 허용하고 싶은 유혹이 들 수 있습니다. 사용자 수가 적은 경우에는 일반적으로 잘 작동합니다.

이제 교차 사용자 분석을 도출해야 할 필요성을 추가하십시오. 이를 수행하는 방법은 모든 사용자 데이터베이스를 단일 분석 데이터베이스로 복제하는 것입니다. 문제가 없습니다. 이 앱은 갑자기 성공을 거두었고 사용자 수는 150 - 20,000 범위 내에서 증가했습니다. 단순히 분석 데이터베이스를 최신 상태로 유지하기 위해 20,000개의 복제가 있습니다. 활성-활성 재해 복구 설정에서도 실행하려는 경우 다른 20,000개의 복제를 추가하면 시스템이 작동을 중지합니다.

대신, 사용자 데이터를 더 적은 수의 데이터베이스로 멀티플렉싱하거나 사용자를 데이터베이스 세트, 계정 세트 또는 둘 다로 샤딩하십시오. 이렇게 하면 분석 데이터베이스를 제공하기 위해 복제할 필요가 없지만 IBM Cloudant가 데이터베이스 레벨의 인증만 제공하므로 인증이 더 복잡해집니다.

IBM Cloudant 권한이 "데이터베이스당"이므로 "사용자별 데이터베이스" 접근법이 더 마음에 들 수 있지만 이 패턴이 나타난 것은 사실 사용자의 잘못이 아닙니다.

사용자 정의 JavaScript reduce 함수를 작성하지 않음

IBM Cloudant의 MapReduce 보기는 훌륭합니다. 하지만 강력한 성능에는 큰 책임이 따릅니다. MapReduce 보기의 맵(map) 파트는 증분식으로 빌드되므로 맵의 조잡한 코드는 조회 시간이 아닌 인덱싱 시간에만 영향을 미칩니다. 아쉽게도 reduce 부분은 쿼리 시점에 실행됩니다. IBM Cloudant 은 Erlang에서 내부적으로 구현되는 내장된 reduce 함수 집합을 제공합니다. 이러한 기능은 대규모로 작동하는 반면, 수작업으로 만든 JavaScript 감축은 그렇지 않습니다.

만약 reduce 함수를 작성하고 있는 자신을 발견한다면, 잠시 멈춰서 reduce 함수를 작성할 필요가 없도록 데이터를 재구성할 수 있는지 고려해 보세요. 또는 내장된 감축자에 의존할 수 있습니다.

분할된 데이터베이스에 대한 뷰는 사용자 정의 reduce를 지원하지 않는데, 이는 오직 이러한 뷰만이 제공할 수 있는 쿼리 처리 속도의 상당한 향상을 가져오는 요인 중 하나입니다.

자세한 내용은 감축에 대한 IBM Cloudant 문서를 참조하세요.

계속 증가하는 데이터 세트에 타임박스 데이터베이스 사용

일반적으로 IBM Cloudant에 계속 증가하는 데이터베이스가 있는 것은 좋은 아이디어가 아닙니다. 대용량 데이터베이스는 백업하기 어렵고, 증가함에 따라 좋은 성능을 유지하기 위해 "리샤딩"이 필요하고, 긴 인덱스 빌드 시간으로 어려움을 겪을 수 있습니다.

이 문제점을 완화하는 한 가지 방법은 대신 타임박스 데이터베이스인 공통 패턴을 사용하는 여러 개의 더 작은 데이터베이스를 보유하는 것입니다. 대형 데이터 세트는 각각 시간 창(예: 한 달) 을 표시하는 더 작은 데이터베이스로 분할됩니다.

• orders_2019_01
• orders_2019_02
• orders_2019_02

새 데이터는 이 달의 데이터베이스에 기록되고 히스토리 데이터에 대한 조회는 이전 달의 데이터베이스로 이동할 수 있습니다. 한 달 동안의 데이터에 더 이상 관심이 없는 경우 Object Storage에 아카이브될 수 있으며 월별 IBM Cloudant 데이터베이스가 삭제되고 디스크 공간이 복구됩니다. 자세한 정보는 다음 웹 사이트를 참조하십시오.

• 시계열 데이터 스토리지 블로그