Introducing Ottoman v2.0: An ODM for Node.js & Couchbase

카우치베이스 팀을 대표하여오스만 2.0의 정식 출시를 발표하게 되어 정말 기쁩니다.

오스만 는 카우치베이스에 저장된 JSON 문서를 네이티브 자바스크립트 객체에 매핑하는 카우치베이스 및 Node.js용 객체 문서 매퍼(ODM) 라이브러리입니다. Ottoman은 다음에 의해 구동됩니다. 카우치베이스 Node.js SDK 자바스크립트 및 타입스크립트를 기본적으로 지원합니다.

일반적인 웹 애플리케이션은 프론트엔드, 백엔드, 데이터 저장소로 구성됩니다. Ottoman은 백엔드의 구성 요소로 클라이언트 애플리케이션 프레임워크와 카우치베이스데이터 저장소를 클릭합니다.

Couchbase에 ODM이 필요한 이유

대부분의 클라이언트-서버 애플리케이션은 데이터 액세스를 관리할 수 있는 일종의 추상화가 필요합니다. '데이터 액세스'라는 용어가 사소하게 들릴 수 있고 기본적인 CRUD(생성, 읽기, 업데이트 및 삭제) 작업으로 오해할 수 있지만 이는 완전히 정확하지 않습니다.

최신 애플리케이션에서 데이터 관리는 단순히 데이터에 액세스하는 것부터 다양한 사용자와 시스템의 요구에 맞게 데이터를 변환, 유효성 검사 및 모델링하는 것까지 다양합니다. 다국어 데이터베이스와 관련 데이터 액세스 패턴을 선택할 수도 있지만, 어느 쪽이든 데이터의 품질은 깨끗하고 합법적이어야 합니다.

관계형 데이터베이스에 익숙한 사용자라면 이러한 데이터베이스와 함께 기본적으로 제공되는 스키마 및 제약 조건에 이미 익숙하고 데이터 무결성을 보장한다고 주장할 수 있습니다. 하지만 데이터 구조가 유동적인 Couchbase와 같은 NoSQL 데이터베이스를 사용할 때는 이러한 점이 어려울 수 있습니다.

이러한 경우 스키마 정의, 데이터 모델 구축, 데이터 유효성 검사, 제약 조건 확인, 관계 관리 등을 수행해야 하는 자체 '스키마 관리자' 라이브러리를 구축해야 하는 것처럼 느껴질 수 있습니다. 이런 것을 직접 구축하는 것은 금방 손에서 벗어날 수 있습니다. 이러한 시스템은 유지 관리 및 확장이 어려울 뿐만 아니라 오류가 발생하기 쉽고 시간이 많이 소요되어 결과물이 지연되고 데이터 품질이 저하될 수 있습니다.

위의 모든 것을 이미 포괄하는 라이브러리를 찾는 것이 필수적입니다. Ottoman과 같은 ODM을 사용하면 이 모든 것이 쉬워집니다.

Ottoman으로 Node.js 개발을 쉽게 만드는 방법

Ottoman이 개발팀에 어떤 도움을 주는지 이해하기 위해 Ottoman 2.0의 새로운 기능을 자세히 살펴보세요.

이 블로그의 예는 여행 샘플 데이터 세트에 대한 설명용으로만 제공됩니다. 또한 이 블로그는 사용자가 다음에 대한 기본적인 지식이 있다고 가정합니다. Couchbase 7.0의 범위 및 컬렉션.

스키마 및 데이터 모델

JSON 문서의 카우치베이스 서버 7.0은 범위와 컬렉션으로 구성할 수 있어 최종 사용자에게 멀티테넌트 마이크로서비스 기반 애플리케이션을 구축할 수 있는 기능을 제공합니다.

Ottoman에서 데이터 모델은 문서가 어느 범위와 컬렉션에 저장되는지 지시하고 해당 문서에 액세스할 수 있는 다양한 방법을 제공합니다. 반면 스키마는 문서의 형태를 정의합니다.

자세히 살펴보겠습니다. 스키마 그리고 모델 를 간단한 예로 설명합니다.

아래 코드 예제에서는 몇 가지 제약 조건과 기본값이 지정된 5개의 필드가 있는 항공사 스키마를 정의합니다. 예를 들어 국가 필드는 다음 값만 가질 수 있습니다. 미국 그리고 캐나다 는 문서를 만들 때 필요합니다. 반면 용량은 최대 값을 가질 수 있는 숫자입니다. 1000를 지정합니다.

기본적으로 스키마는 "엄격"으로, 데이터베이스에 저장된 문서가 정의된 스키마 구조를 준수해야 하며 정의된 추가 필드는 저장하는 동안 무시된다는 의미입니다. 이 엄격 옵션은 재정의할 수 있습니다. 스키마 옵션 사용.

const airlineSchema = new Schema({ 
  id: { type: String },
  type: { type: String, required: true, default: 'airline' },
  name: { type: String, required: true  },
  country: { type: String, required: true, enum: ['United States', 'Canada']  },
  capacity: { type: Number, max: 1000 } 
})

const 항공사 스키마 = new 스키마({

id: { 유형: 문자열 },

유형: { 유형: 문자열, 필수: true, 기본값: '항공사' },

이름: { 유형: 문자열, 필수: true },

국가: { 유형: 문자열, 필수: true, enum: ['미국', 'Canada'] },

용량: { 유형: 번호, 최대: 1000 }

})

사용하려면 항공사 스키마를 사용하여 모델을 만들어야 합니다:

const airlineModel = model('Airline', airlineSchema, { scopeName: '_default' })

1	const 항공사모델 = 모델('항공사', 항공사 스키마, { 범위 이름: '_default' })

첫 번째 매개변수는 모델 이름이며, 다음을 사용하여 재정의하지 않은 경우 컬렉션 이름이기도 합니다. 모델 옵션.

오스만 문서는 카우치베이스에 저장된 문서에 대한 일대일 매핑을 나타냅니다. 각 문서 는 해당 모델의 인스턴스입니다.

const airlineDocument = new airlineModel({
  id: "10",
  type: "airline",
  name: "MILE-AIR",
  country:"United States"
})

const 항공사문서 = new 항공사모델({

id: "10",

유형: "항공사",

이름: "MILE-AIR",

국가:"미국"

})

전화하여 저장 메서드의 항공사 모델, 내에 문서를 생성하게 됩니다. 항공사 컬렉션 아래에 있는 _기본값 범위를 설정합니다.

타임스탬프

타임스탬프 스키마 옵션 는 오스만에게 자동으로 createdAt 그리고 업데이트된 날짜 날짜/시간을 기본값으로 설정하여 문서를 만들 때마다 현재 날짜/시간으로 설정합니다. 문서가 업데이트될 때마다 업데이트된 날짜 타임스탬프도 업데이트됩니다.

다음은 항공사 스키마에 타임스탬프 옵션을 추가하는 예입니다:

const airlineSchema = new Schema({ 
  id: { type: String },
  type: { type: String, required: true, default: 'airline' },
  name: { type: String, required: true },
  country: { type: String, required: true, enum: ['United States', 'Canada'] },
  capacity: { type: Number, max: 1000 } 
}, { timestamps: true })

const 항공사 스키마 = new 스키마({

id: { 유형: 문자열 },

유형: { 유형: 문자열, 필수: true, 기본값: '항공사' },

이름: { 유형: 문자열, 필수: true },

국가: { 유형: 문자열, 필수: true, enum: ['미국', 'Canada'] },

용량: { 유형: 번호, 최대: 1000 }

}, { 타임스탬프: true })

이 단계(위)는 기본적으로 스키마를 확장하여 두 개의 새 필드를 암시적으로 추가합니다. 필요한 경우 아래 그림과 같이 명시적으로 호출하고 이름을 재정의할 수도 있습니다:

const airlineSchema = new Schema({ 
  id: { type: String },
  type: { type: String, required: true, default: 'airline' },
  name: { type: String, required: true },
  country: { type: String, required: true, enum: ['United States', 'Canada']  },
  capacity: { type: Number, max: 1000 } ,
  created_at: { type: Date, default: new Date() },
  updated_at: { type: Date, default: new Date() }
}, { timestamps: { createdAt: 'created_at', updatedAt: 'updated_at' }})

const 항공사 스키마 = new 스키마({

id: { 유형: 문자열 },

유형: { 유형: 문자열, 필수: true, 기본값: '항공사' },

이름: { 유형: 문자열, 필수: true },

국가: { 유형: 문자열, 필수: true, enum: ['미국', 'Canada'] },

용량: { 유형: 번호, 최대: 1000 } ,

created_at: { 유형: 날짜, 기본값: new 날짜() },

updated_at: { 유형: 날짜, 기본값: new 날짜() }

}, { 타임스탬프: { createdAt: 'created_at', 업데이트된 날짜: 'updated_at' }})

불변

필드를 "불변"는 원래 값을 보존하고 지정된 필드에 대한 변형을 방지합니다. 스키마의 타임스탬프 정의에서는 문서가 업데이트될 때마다 created_at 그리고 updated_at 필드가 업데이트됩니다.

그러나 이상적으로는 다음과 같이 created_at 필드를 수정할 수 있습니다. 문서가 언제 생성되었는지 추적하는 데 사용되기 때문입니다. 이때 불변 옵션이 유용합니다.

const airlineSchema = new Schema({ 
  id: { type: String },
  type: { type: String, required: true, default: 'airline' },
  name: { type: String, required: true  },
  country: { type: String, required: true, enum: ['United States', 'Canada'] },
  capacity: { type: Number, max: 1000 } ,
  created_at: { type: Date, default: new Date(), immutable: true},
  updated_at: { type: Date, default: new Date() }
}, { timestamps: { createdAt: 'created_at', updatedAt: 'updated_at' } })

const 항공사 스키마 = new 스키마({

id: { 유형: 문자열 },

유형: { 유형: 문자열, 필수: true, 기본값: '항공사' },

이름: { 유형: 문자열, 필수: true },

국가: { 유형: 문자열, 필수: true, enum: ['미국', 'Canada'] },

용량: { 유형: 번호, 최대: 1000 } ,

created_at: { 유형: 날짜, 기본값: new 날짜(), 불변: true},

updated_at: { 유형: 날짜, 기본값: new 날짜() }

}, { 타임스탬프: { createdAt: 'created_at', 업데이트된 날짜: 'updated_at' } })

불변 필드를 업데이트하고 싶은 경우가 있습니다. 문서를 작성 중인데 불변 필드에 기본값이 없거나 다른 이유로 업데이트가 불가피한 경우 특히 그렇습니다. 이러한 경우 추가 옵션을 전달할 수 있습니다, new : true를 클릭하고 돌연변이 연산으로 이동합니다.

이 단계에서는 항공사 스키마 에 불변 필드 접점이 있고 모델 연산을 사용하는 경우 찾기 및 업데이트 on 항공사모델.

await airlineModel.findOneAndUpdate(
  { contact: { $like: '123456' } }, 
  { contact: '45678' }, 
  { new: true}
)

기다림 항공사모델.찾기 및 업데이트(

{ 연락처: { $같은: '123456' } },

{ 연락처: '45678' },

{ new: true}

)

후크

후크 는 이벤트가 트리거되기 전(프리훅) 또는 이벤트가 트리거된 후(포스트훅)에 동작할 수 있는 미리 정의된 이벤트와 함께 작성하고 등록하는 미들웨어 비동기 함수입니다.

훅은 모델을 정의하기 전에 정의해야 하므로 워크플로에서 스키마 정의와 함께 훅을 정의하는 것이 항상 좋은 습관입니다.

앞서 우리는 updated_at 필드는 변이 시 업데이트됩니다. 내부적으로는 업데이트 이벤트를 수신하는 프리훅의 도움으로 이 작업을 수행합니다.

airlineSchema.pre('update', (doc) =&gt; {   
  doc[updatedAt] = typeof currentTime === 'function' 
    ? currentTime() 
    : currentTime
  return doc
})

항공사 스키마.pre('update', (doc) => {

doc[업데이트된 날짜] = typeof currentTime === 'function'

? currentTime()

: currentTime

반환 doc

})

일반적으로 후크는 이벤트 이름 를 첫 번째 인수로 지정하고 그 뒤에 호출될 콜백 함수를 지정합니다. 이벤트를 유효성 검사, 저장, 업데이트 및 제거하기 위해 훅을 등록할 수 있습니다.

훅을 등록할 때 고려할 수 있는 몇 가지 사용 사례는 다음과 같습니다:

- 로깅
- 리소스 정리
- 알림 보내기
- 기타 관련 문서 업데이트

플러그인

오스만 사용의 주요 이점 중 하나는 반복 작업을 할 필요가 없기 때문에 민첩한 개발이 가능하다는 점입니다. 오히려 시간과 노력을 절약할 뿐만 아니라 디버그 및 유지 관리가 쉬운 코드를 생성하는 플러그 가능한 구성 요소를 빌드하고 사용하게 됩니다.

플러그인 는 특정 기능을 컴포넌트화하여 한 번 빌드한 후 여러 스키마에 적용할 수 있도록 함으로써 후크의 동작을 확장합니다.

이 시점에서 모든 스키마에 다음과 같은 필드가 있다고 가정합니다. 이름로 설정하고 문서가 저장될 때마다 값을 소문자로 변경하려고 합니다. 저장 이벤트의 사전 후크를 사용하여 이 작업을 수행할 수 있지만 모든 스키마에 적용해야 한다는 요구 사항도 있습니다. 이 사용 사례는 플러그인을 사용할 수 있는 경우입니다.

이 경우 필드 이름과 관련된 값을 소문자로 변환하는 '소문자' 플러그인을 정의하고 있습니다:

const lowercase = (schema) =&gt; {
  schema.pre('save', (doc) =&gt; {   
    doc['name'] = doc['name'].toLowerCase()
    return doc
 })
}

const 소문자 = (스키마) => {

스키마.pre('저장', (doc) => {

doc['name'] = doc['name'].toLowerCase()

반환 doc

})

}

그런 다음 스키마에 플러그인을 사용하도록 지시합니다:

airlineSchema.plugin(lowercase)

1	항공사 스키마.플러그인(소문자)

플러그인을 전역에 등록하여 여러 프로젝트에서 사용할 수 있도록 할 수도 있습니다.

사용자 지정 스키마 유형

기본적으로 Ottoman은 다음과 같은 기능을 제공합니다. 기본 스키마 유형 문자열, 숫자, 부울, 날짜, 배열 등과 같은 데이터 타입을 사용할 수 있습니다. 하지만, 어떤 경우에는 복잡한 사용자 지정 스키마 유형 재사용이 가능하고 잘 정의되어 있습니다.

예를 들어, 다음과 같이 추가하고 싶다고 가정해 보겠습니다. 웹사이트_URL 를 항공사 스키마. 어떤 선택지가 있나요? 사용할 수 있는 유일한 선택은 문자열입니다. 문자열을 선택하는 것이 잘못된 것은 아니지만 한 가지 주의해야 할 점은 웹사이트_URL 가 잘 형성되어 있습니다. 이것은 사용자 정의 스키마 유형을 사용해야 하는 일반적인 사용 사례입니다.

사용자 정의 스키마 유형을 만드는 과정은 3단계로 이루어집니다:

1. 사용자 지정 스키마 유형을 정의합니다:

class LinkType extends IOttomanType {
  constructor(name) {
    super(name, 'Link')
  }
  cast(value) {
    if(!isLink(String(value))) {
      throw new ValidationError(`Field ${this.name} only allows Link`)
    }
    return String(value)
  }
}

function isLink(value) {
  const regExp = new RegExp(
    /[-a-zA-Z0-9@:%._\+~#=]{1,256}\.[a-zA-Z0-9()]{1,6}\b([-a-zA-Z0-9()@:%_\+.~#?&amp;//=]*)?/gi
  )
  return regExp.test(value)
}

클래스 링크 유형 확장 IOttomanType {

생성자(이름) {

super(이름, '링크')

}

캐스트(값) {

만약(!isLink(문자열(값))) {

throw new 유효성 검사 오류(`필드 ${이.이름} 만 허용 링크`)

}

반환 문자열(값)

}

함수 isLink(값) {

const regExp = new RegExp(

/[-a-zA-Z0-9@:%._\+~#=]{1,256}\.[a-zA-Z0-9()]{1,6}\b([-a-zA-Z0-9()@:%_\+.~#?&//=]*)?/gi

)

반환 regExp.테스트(값)

}

기능 isLink 에는 URL이 제대로 형성되었는지 확인하는 로직이 포함되어 있습니다.

2. 사용자 지정 스키마 유형을 등록합니다:

var LinkTypeFactory = (name) =&gt; new LinkType(name)
    registerType(LinkType.name, LinkTypeFactory)

1 2	var 링크타입팩토리 = (이름) => new 링크 유형(이름) 등록 유형(링크 유형.이름, 링크타입팩토리)

3. 사용자 지정 스키마 유형을 사용합니다:

const airlineSchema = new Schema({ 
  id: { type: String },
  type: { type: String, required: true, default: 'airline' },
  name: { type: String, required: true },
  country: { type: String, required: true, enum: ['United States', 'Canada']  },
  capacity: { type: Number, max: 1000 },
  created_at: { type: Date, default: new Date(), immutable: true},
  updated_at: { type: Date, default: new Date() },
  website_url: { type: LinkType } 
}, { timestamps : { createdAt: 'created_at', updatedAt: 'updated_at' } })

const 항공사 스키마 = new 스키마({

id: { 유형: 문자열 },

유형: { 유형: 문자열, 필수: true, 기본값: '항공사' },

이름: { 유형: 문자열, 필수: true },

국가: { 유형: 문자열, 필수: true, enum: ['미국', 'Canada'] },

용량: { 유형: 번호, 최대: 1000 },

created_at: { 유형: 날짜, 기본값: new 날짜(), 불변: true},

updated_at: { 유형: 날짜, 기본값: new 날짜() },

웹사이트_URL: { 유형: 링크 유형 }

}, { 타임스탬프 : { createdAt: 'created_at', 업데이트된 날짜: 'updated_at' } })

이제 문서를 만들거나 업데이트할 때마다 문서가 자동으로 생성됩니다, 웹사이트_URL 는 잘 구성된 URL에 대해 유효성을 검사합니다.

사용자 지정 유효성 검사기

필드의 무결성을 검사할 때 기본, 최소, 최대 또는 스키마 유형과 같은 기본 제약 조건을 사용하는 것 이상의 작업이 필요할 때가 있습니다. 예를 들어 필드 유형을 배열로 선언하고 싶지만 배열의 길이도 제한하고 싶을 수 있습니다. 이럴 때는 사용자 지정 유효성 검사기.

확장해 보겠습니다. 항공사 스키마 를 사용하여 여러 전화번호 배열을 허용하지만 두 개 이상의 전화번호를 허용하지 않도록 설정할 수 있습니다. 먼저, 유효성 검사기를 등록하려면 추가 유효성 검사기 메서드를 사용합니다:

addValidators({
  phoneLength: (value) =&gt; {
    if(value.length &gt; 2) {
      throw new Error(`Only two phone numbers are allowed at the maximum.`)
    }
  }
})

const airlineSchema = new Schema({ 
  id: { type: String },
  type: { type: String, required: true, default:'airline' },
  name: { type: String, required: true  },
  country: { type: String, required: true, enum: ['United States', 'Canada']  },
  capacity: { type: Number, max: 1000 },
  created_at: { type: Date, default: new Date(), immutable: true },
  updated_at:{ type: Date, default: new Date() },
  website_url: { type: LinkType } ,
  phone_number: [{ type: String, validator: 'phoneLength' }]
}, { timestamps : { createdAt: 'created_at', updatedAt: 'updated_at' } })

추가 유효성 검사기({

전화 길이: (값) => {

만약(값.길이 > 2) {

throw new 오류(`Only 두 전화 숫자 는 허용됨 에서 의 최대.`)

}

})

const 항공사 스키마 = new 스키마({

id: { 유형: 문자열 },

유형: { 유형: 문자열, 필수: true, 기본값:'항공사' },

이름: { 유형: 문자열, 필수: true },

국가: { 유형: 문자열, 필수: true, enum: ['미국', 'Canada'] },

용량: { 유형: 번호, 최대: 1000 },

created_at: { 유형: 날짜, 기본값: new 날짜(), 불변: true },

updated_at:{ 유형: 날짜, 기본값: new 날짜() },

웹사이트_URL: { 유형: 링크 유형 } ,

전화 번호: [{ 유형: 문자열, 유효성 검사기: '전화 길이' }]

}, { 타임스탬프 : { createdAt: 'created_at', 업데이트된 날짜: 'updated_at' } })

참조

NoSQL 데이터베이스의 세계에서 "문서 디자인"이라고도 하는 데이터 모델링은 데이터 관리의 필수적인 부분입니다. 관계형 데이터베이스에서 데이터는 테이블에 저장되며 테이블 간의 관계는 외래 키라고도 하는 참조 키로 관리됩니다.

Couchbase에서는 유사한 유형의 데이터가 동일한 컬렉션 내에 저장되며, 문서 키(또는 간단히 "키")를 사용하여 다른 문서를 참조합니다. 이러한 방식으로 문서를 설계하면 Ottoman은 스키마 설계 중에 문서를 참조할 수 있는 수단을 제공할 뿐만 아니라 다음을 사용하여 자동으로 문서를 채웁니다. 채우기 메서드.

이 기능을 더 잘 이해하기 위해 다음과 같이 정의하여 경로를 생성하겠습니다. 경로 스키마 및 routeModel. 경로에는 항공사 필드를 사용하는 항공사 모델을 나타내는 ref 키워드를 입력합니다.

const routeSchema = new Schema({
  id: { type: String } ,
  airline: { type: String, ref: 'Airline' },
  destination_airport: { type: String },
  source_airport: { type: String },
  stops: { type: Number },
  type: { type: String }
})
  
const routeModel = model('Route', routeSchema, { scopeName: "_default" })

const 경로 스키마 = new 스키마({

id: { 유형: 문자열 } ,

항공사: { 유형: 문자열, ref: '항공사' },

목적지_공항: { 유형: 문자열 },

source_airport: { 유형: 문자열 },

멈춤: { 유형: 번호 },

유형: { 유형: 문자열 }

})

const routeModel = 모델('경로', 경로 스키마, { 범위 이름: "_default" })

아래에서 경로 문서를 생성하는데, 이 문서에는 항공사 id 10.

const routeDocument = new routeModel({
  id: "route1",
  type: "route",
  source_airport: "LAX",
  destination_airport: "DFW",
  stops: 0,
  airline: "10"
})

const 경로 문서 = new routeModel({

id: "route1",

유형: "경로",

source_airport: "LAX",

목적지_공항: "DFW",

멈춤: 0,

항공사: "10"

})

전화하여 저장 메서드의 routeModel 내에서 문서를 생성하면 경로 컬렉션 아래에 있는 _기본값 범위를 설정합니다.

마지막으로 문서를 검색하고 문서를 채웁니다.

const laxRouteDocument = await routeModel.findOne( { source_airport: 'LAX' } )
await laxRouteDocument._populate('airline')

1 2	const laxRouteDocument = 기다림 routeModel.findOne( { source_airport: 'LAX' } ) 기다림 laxRouteDocument._populate('항공사')

아래와 같이 항공사 데이터가 포함된 경로 문서를 검색합니다:

{
  "id": "route1",
  "type": "route",
  "source_airport ": "LAX",
  "destination_airport": "DFW",
  "stops": "0",
  "airline": { 
    "id": "10",
    "type": "airline",
    "name": "MILE-AIR",
    "country": "United States"
  }
}

{

"id": "route1",

"type": "경로",

"소스_공항 ": "LAX",

"목적지_공항": "DFW",

"stops": "0",

"항공사": {

"id": "10",

"type": "항공사",

"name": "MILE-AIR",

"country": "미국"

}

쿼리 빌더

Ottoman에는 Couchbase에서 지원하는 많은 복잡한 작업을 처리하는 매우 풍부한 API가 있습니다. SQL++ 쿼리 언어 (이전에는 N1QL로 알려졌으나 아래에서 사용됨).

쿼리 빌더 가 백그라운드에서 N1QL 문을 생성합니다. 쿼리 빌더를 사용할 때는 세 가지 모드 옵션이 있습니다:

색인

색인 는 Couchbase 데이터베이스에서 문서에 액세스하는 데 중요한 역할을 합니다.

올바른 인덱스가 없으면 성능이 저하될 수 있습니다. 따라서 문서 디자인(즉, 데이터 모델)과 이에 대해 사용할 쿼리를 미리 파악하는 것이 필수적입니다. 인덱스 구축은 데이터 작업 시 중요한 단계입니다. Ottoman은 스키마와 연결할 수 있는 세 가지 유형의 인덱스를 제공합니다.

인덱스 유형 #1: NIQL

N1QL 인덱스는 Ottoman에서 사용하는 기본 인덱스 유형이며, 때때로 GSI 또는 글로벌 보조 인덱스라고도 합니다. 부트스트랩 프로세스 중에 Ottoman은 자동으로 여러 개의 보조 인덱스를 생성하여 기본 작업 중 일부를 즉시 효율적으로 수행할 수 있도록 합니다. 이것은 가장 추천 인덱스 유형.

airlineSchema.index.findByName = {
  by: 'name',
  type: 'n1ql' 
}

항공사 스키마.색인.findByName = {

by: 'name',

유형: 'n1ql'

}

인덱스 유형 #2: Refdoc

refdoc 인덱스 유형은 고유성이 보장되어야 하는 특정 요구 사항을 관리합니다. refdoc 인덱스를 고려하기 전에 알아야 할 몇 가지 중요한 사항이 있습니다:

- Refdoc 인덱스는 Couchbase 데이터베이스가 아닌 Ottoman에서 엄격하게 관리합니다. 즉, Ottoman 외부에서 문서를 업데이트하면 refdoc 인덱스가 동기화되지 않게 됩니다.
- Refdoc 인덱스는 인덱싱 중인 문서의 키에 대한 참조를 포함하는 추가 바이너리 문서를 생성합니다. 간단히 말해, refdoc 인덱스를 사용하는 문서를 만들 때마다 추가 문서가 표시됩니다.

예를 들어 다음 사항을 보장하고 싶다고 가정해 보겠습니다. 웹사이트_URL in 항공사 스키마 는 고유합니다. 아래와 같이 refdoc 인덱스를 생성합니다:

airlineSchema.index.findByUrl = {
  by: website_url,
  type: 'refdoc'
}

항공사 스키마.색인.findByUrl = {

by: 웹사이트_URL,

유형: 'refdoc'

}

refdoc 인덱스의 일반적인 모범 사례는 주의를 기울이고 Ottoman을 통해 데이터 변형을 엄격하게 처리하는 것입니다.

색인 유형 #3: 조회수

이 인덱스 유형은 더 이상 사용되지 않으며 곧 제거될 예정입니다. 이 인덱스 유형은 이전 버전과의 호환성만을 위해 존재합니다. 이 인덱스의 사용은 강력히 권장하지 않음.

Lean

Ottoman은 컬렉션에서 문서를 검색하는 여러 가지 모델 메서드를 제공합니다. 이러한 메서드는 다음과 같습니다. 찾기, findById, findOne등

그리고 찾기 메서드가 가장 많이 사용되며 지정된 검색 조건에 따라 여러 문서를 반환합니다. 컬렉션에서 한 번에 많은 수의 문서를 검색하면 작은 문서 집합으로 작업할 때는 보이지 않을 수 있는 성능 오버헤드가 발생합니다. 이러한 오버헤드는 주로 지정된 모든 모델 메서드가 많은 오스만 내부 변경 상태 추적 정보를 포함하는 오스만 문서 클래스의 인스턴스를 반환하기 때문입니다.

린 옵션 활성화 는 오스만에게 전체 오스만 문서 인스턴스화를 생략하고 대신 일반 자바스크립트 객체(POJO)만 반환하도록 지시합니다.

이렇게 하면 성능이 향상될 수 있지만 변경 추적, 유효성 검사, 후크 및 저장, 제거 등과 같은 일반적인 모델 메서드와 같은 Ottoman의 기본 제공 기능에 대한 절충안입니다. 따라서 다음을 사용하는 것이 좋습니다. 린 극도의 주의와 경각심을 가지고 있습니다.

const result =  await airlineMode.find( { name: { $like: 'american' } }, { lean: true }  )

1	const 결과 = 기다림 항공사 모드.찾기( { 이름: { $같은: '미국' } }, { 린: true } )

그리고 결과 객체는 위 예제에서 이름이 다음과 같은 모든 항공사 문서를 갖게 됩니다. 미국를 사용할 수 있지만, 이 모든 문서는 일반 자바스크립트가 됩니다(즉, 오스만 문서와 관련된 모든 마법을 잃게 됩니다).

모델 메서드

오스만 모델은 다음과 함께 배송됩니다. 몇 가지 도우미 메서드 다양한 용도로 사용할 수 있습니다. 다음은 가장 자주 사용되는 모델 방법 중 일부입니다:

찾기: 찾기 는 백그라운드에서 쿼리 서비스를 사용하는 일반적인 방법으로, 제공된 필터 조건에 따라 Couchbase 컬렉션에서 하나 이상의 문서를 검색하는 데 사용됩니다. 효율적인 사용 방법 찾기 는 적절한 보조 인덱스(즉, N1QL 인덱스)의 생성을 보장합니다.

다음 찾기 작업은 국가가 미국인 모든 항공사 문서를 반환하고 대소문자 구분을 무시합니다.

const docs = await airlineModel.find({ country: "United States" }, { ignoreCase: true })

1	const 문서 = 기다림 항공사모델.찾기({ 국가: "미국" }, { 무시 케이스: true })

findOneAndUpdate: 찾기 는 전달된 필터 조건에 따라 단일 문서를 생성하고 제공된 새 값으로 문서를 업데이트합니다. 옵션 전달하기 업서트 : true 는 일치하는 문서를 찾을 수 없는 경우 새 문서를 생성하도록 합니다.

await airlineModel.findOneAndUpdate({ id: "10" }}, { country: "Canada" }, { upsert: true })

1	기다림 항공사모델.찾기 및 업데이트({ id: "10" }}, { 국가: "Canada" }, { 업서트: true })

대량 작업: 한 번에 두 개 이상의 문서를 변경해야 하는 경우가 있을 수 있습니다. Ottoman은 이 문제를 해결하는 데 도움이 되는 세 가지 모델 메서드를 제공하며, 모두 백그라운드에서 쿼리 서비스를 사용합니다:

- createMany: 한 번의 호출로 여러 문서 생성
- removeMany: 한 번의 통화로 여러 문서를 제거합니다.
- updateMany: 한 번의 통화로 여러 문서 업데이트

모든 대량 작업에 대한 응답 상태는 오류가 발생하지 않는 한 "성공"이 되고, 그렇지 않으면 "실패"가 됩니다.

디버깅

이미 보셨겠지만, 내부적으로 N1QL 쿼리 언어를 사용하는 모델 작업은 꽤 많이 있습니다. N1QL 쿼리를 최적화하고 올바른 인덱스를 구축하는 것은 개발의 필수적인 부분입니다.

이를 위해서는 이러한 모델 작업에서 어떤 종류의 N1QL 쿼리가 사용되고 있는지 파악하는 것이 중요합니다. 디버깅을 지원하는 오스만 를 사용하면 개발 콘솔에 N1QL 문이 인쇄되어 개발자가 효과적으로 분석하고 UI를 사용하여 인덱스 생성 를 적절히 사용합니다.

Ottoman은 Node.js SDK와 어떻게 다른가요?

오스만은 Node.js SDK로 구동되지만, 오스만을 통해서만 사용할 수 있는 특정 기능이 있다는 점에 주목할 필요가 있습니다. 다른 기능을 선택할 때 다음 기능을 고려할 수 있습니다.

기능	오스만	Node.js SDK
스키마, 제약 조건	✅	🚫
유효성 검사기	✅	🚫
참조 채우기	✅	🚫
모델 방법 (find, findOneAndUpdate, findOneAndRemove)	✅	🚫
부트스트랩 (범위, 컬렉션, 인덱스 생성)	✅	🚫
감사 필드(타임스탬프)	✅	🚫
참조 문서 색인	✅	🚫
후크	✅	🚫
플러그인	✅	🚫
불변	✅	🚫
쿼리 빌더	✅	🚫
대량 작업	✅	🚫

오스만 사용의 다른 이점

Ottoman을 사용하여 첫 번째 애플리케이션을 작성할 준비가 되셨기를 바랍니다. 다음은 고객이 Ottoman을 선호하는 주요 이유 중 일부입니다:

적응성
전문 기술이 필요하지 않으며 JavaScript 또는 TypeScript만 알고 있으면 바로 사용할 수 있습니다.

경제성
오픈소스의 모든 이점을 누리세요. 공급업체 종속성, 설비 투자 감소, 독점 라이선스 등이 없습니다.

지원 및 지속 가능성
소프트웨어의 보안 취약점을 검사하고 패치를 적용하는 부담은 저희에게 맡기세요. 서버 릴리스에 맞춰 지속적인 소프트웨어 업데이트를 받고 지원팀과 대규모 개발자 커뮤니티의 전폭적인 지원을 받을 수 있습니다.

민첩성
업계 리더가 되어 애플리케이션을 신속하고 적시에 구축 및 제공하세요. 애플리케이션을 구축할 필요가 없습니다. 데이터 계층 처음부터 다시 시작하세요. 코딩보다는 비즈니스 문제 해결에 시간을 투자하세요. 유지 관리와 읽기가 쉬운 작은 코드 블록을 작성하세요. 코딩이 간단하기 때문에 여러 번 반복해도 코드가 비슷해 보일 것입니다.

데이터 품질
스키마, 유효성 검사기, 제약 조건 및 기타 사용 가능한 모듈을 사용하여 양질의 데이터를 보장하세요. 반복적인 설계 및 개발 과제를 면밀히 관찰하고 세심하게 설계한 결과물인 Ottoman의 배관으로 버그 없는 코드를 생성하세요. Ottoman은 수작업으로 코딩할 경우 어렵고 오류가 발생하기 쉬운 많은 일반적인 문제를 해결합니다.

지금 오스만 시작하기

이제 다음 Node.js 프로젝트에 Ottoman을 고려해야 하는 이유와 시기를 기본적으로 이해했으니, 이제 직접 손을 더럽힐 차례입니다!

다음은 시작하는 데 도움이 되는 몇 가지 유용한 링크입니다:

오스만을 직접 체험해볼 준비가 되셨나요?
여기에서 샘플 프로젝트 시작하기

아룬 비제이라가반

이 문서 공유하기

Platform

Self-Managed

Services

Capabilities

Why Couchbase?

Migrate to Capella

By Use Case

By Industry

By Application Need

Popular Docs

By Developer Role

Quickstart

Resource Center

About

Partnerships

Our Services

Partners: Register a Deal

Ready to register a deal with Couchbase?

Marriott

Ottoman v2.0을 소개합니다: Node.js 및 Couchbase를 위한 ODM

Couchbase에 ODM이 필요한 이유

Ottoman으로 Node.js 개발을 쉽게 만드는 방법

스키마 및 데이터 모델

타임스탬프

불변

후크

플러그인

사용자 지정 스키마 유형

사용자 지정 유효성 검사기

참조

쿼리 빌더

색인

Lean

모델 메서드

디버깅

Ottoman은 Node.js SDK와 어떻게 다른가요?

오스만 사용의 다른 이점

지금 오스만 시작하기

받은 편지함에서 카우치베이스 블로그 업데이트 받기

작성자

게시자 아룬 비제이라가반

댓글 남기기 응답 취소

카우치베이스 카펠라를 시작할 준비가 되셨나요?

구축 시작

카펠라 무료 사용

연락하기