개념 증명은 Couchbase를 평가할 때 시작해야 하는 작업일 수 있습니다.

저희는 그동안 Oracle이나 SQL Server와 같은 관계형 데이터베이스에서 Couchbase로 전환하는 기술적 측면에 대해 많은 블로그를 작성해 왔습니다. 다음은 저희가 게시한 리소스 및 게시물 중 일부입니다:

하지만 이 글에서는 기술적인 세부 사항보다는 전반적인 프로세스에 대해 더 많이 이야기하겠습니다. 성공적인 개념 증명을 만들기 위한 5가지 단계를 살펴보겠습니다. 시작하는 데 도움이 필요하면 다음을 참조하세요. 카우치베이스 솔루션 엔지니어와 상담하기.

개념 증명 단계

이러한 단계는 기존 애플리케이션을 Couchbase로 마이그레이션하는 것뿐만 아니라 Couchbase로 새로운 "그린필드" 애플리케이션을 만들거나 기존 데이터베이스를 완전히 교체하는 것이 아니라 보강하는 경우에도 마찬가지로 작동합니다.

개념 증명을 만들 때는 가능한 한 범위를 작고 단순하게 유지하는 것이 좋습니다. 몇 가지 질문을 해보세요:

  • 필요한 것을 증명/반증하고 다음 단계로 나아가는 데 도움이 되나요?
  • 이 작업을 상당히 빠르게 완료할 수 있나요? 시간이 너무 오래 걸리거나 우선순위가 아닌 경우 작업이 흐지부지될 수 있습니다.
  • 문의하기 카우치베이스 기술 팀원카우치베이스와 잘 맞을까요? 그들의 경험을 바탕으로 고민을 덜 수 있습니다.

사용 사례 및 애플리케이션 선택

사람들에게 Couchbase와 NoSQL에 대해 이야기할 때, 저는 다음과 같이 말합니다. not CouchBase를 엉뚱한 용도로 사용하여 문서 데이터베이스가 망가지고 있습니다.

Couchbase와 같은 분산 데이터베이스의 장점은 다음과 같습니다:

  • 성능 향상
  • 확장성 향상
  • 더 높은 가용성
  • 데이터 민첩성/유연성 향상
  • 운영 관리 개선

애플리케이션이 이러한 특성 중 하나를 활용할 수 있다면 Couchbase를 확인해 볼 가치가 있습니다. 다중 문서 트랜잭션이 필요한 경우에는 Couchbase가 가장 적합하지 않을 수도 있습니다. 하지만 다음 포스팅에서 설명했듯이 데이터 모델링데이터를 조각조각 흩어놓는 대신 중첩할 수 있다면 생각보다 다중 문서 트랜잭션이 많이 필요하지 않을 수도 있습니다.

또한, 카우치베이스 고객과의 대화를 통해 기존 데이터베이스 이상의 필요성을 파악하게 되었습니다. 상호 작용. Marriott 에서는 이를 '룩투북' 비율이라고 부릅니다.

Think about the interaction to transaction ratio in your proof of concept

기존 데이터베이스에 트랜잭션을 기록해야 하는 상황이지만, 트랜잭션으로 이어지는 모든 상호작용을 처리할 수 있는 지연 시간이 짧고 유연하며 확장 가능한 데이터베이스를 원한다면 Couchbase가 적합할 수 있습니다.

Couchbase가 적합한 몇 가지 사용 사례는 다음과 같습니다:

성공 기준 정의

카우치베이스에 적합한 사용 사례가 있다고 결정한 후에는 개념 증명이 성공하기 위해 무엇을 의미하는지 정의해야 합니다.

기준의 예

  • 성능/레이턴시 개선 - 이는 "95번째 백분위수에서 5ms 지연 시간"과 같은 수치로 요약할 수 있습니다.
  • 손쉬운 확장 - 지금 확장하는 것이 얼마나 쉬운가요? 한 사람이 얼마나 많은 시간이 걸리나요? 업그레이드를 하려면 토요일 새벽 2시에 몇 번이나 일해야 하나요?
  • 더 빠른 개발 주기 - 스키마 관리가 스프린트 작업에서 많은 시간을 잡아먹나요? Couchbase를 사용한 개념 증명은 유연한 모델이 시간을 절약할 수 있는지 입증하는 데 도움이 될 수 있습니다.
  • 유지 관리 및 비용

기준이 무엇이든 처음에 정의하는 것이 좋으며, 이를 달성하기 위해 노력할 수 있습니다. "그냥 NoSQL을 사용해 보고 싶어요"와 같은 막연한 목표는 개발자 개인에게는 괜찮지만, 의사 결정권자를 설득하려면 성공 기준을 잘 정의하는 것이 중요합니다.

데이터 이해

에서 다루었듯이 JSON 데이터 모델링 포스트코드를 작성하기 전에 데이터를 이해하는 것이 중요합니다. 무엇을 모델링할 것인지, 애플리케이션이 어떻게 작동해야 하는지 이해해야 합니다.

관계형 데이터베이스에서 문서 데이터베이스로 마이그레이션하는 것은 순전히 기계적인 작업이 아닙니다. 데이터를 마이그레이션할 계획이라면 현재 저장된 방식과 무관하게 데이터가 어떻게 보일지 생각하는 것부터 시작하는 것이 좋습니다. '테이블'이나 '문서'를 사용하지 않고 화이트보드에 그 개념을 그려보세요.

액세스 패턴 파악

이 내용은 JSON 데이터 모델링 포스트. 카우치베이스는 데이터를 저장하는 방식이 매우 유연합니다. 하지만 데이터 액세스도 유연합니다. 모델 설계 시 이를 고려해야 합니다.

해당 블로그 게시물에서 중첩/분리 문서에 대한 몇 가지 경험 법칙을 설명해 드렸습니다. 더 높은 수준에서는 다음과 같이 데이터 액세스에 대해 생각하는 것부터 시작할 수 있습니다:

  • 키/값 - 키를 기반으로 문서를 가져오거나 변경하는 기능입니다. 이는 Couchbase에서 사용할 수 있는 가장 빠르고 지연 시간이 짧은 방법입니다.
  • N1QL 쿼리 - N1QL은 Couchbase에서 사용할 수 있는 JSON 데이터용 SQL입니다. 상상할 수 있는 거의 모든 방식으로 데이터를 쿼리할 수 있습니다. 가장 중요한 것은 다음을 기반으로 데이터를 쿼리할 수 있다는 것입니다. 기타 키보다 중요합니다.
  • 전체 텍스트 검색 - 언어를 인식하는 방식으로 텍스트를 기반으로 쿼리해야 하는 경우. 예를 들어 사용자 중심 검색에 적합합니다.
  • 지도/축소 - 쿼리 결과를 미리 계산하는 순수 함수 작성. N1QL은 M/R에서 많은 작업 부하를 덜어주지만, 일부 특수한 유형의 집계에는 여전히 유용합니다.
  • 지리공간 - 일부 지리적/위치 기반 정보를 기반으로 문서를 쿼리합니다.
  • 분석/보고 - 카우치베이스 애널리틱스(현재 미리 보기)를 사용하면 데이터에 대한 운영 외 액세스를 대폭 색인화할 수 있습니다. 일상적인 사용자에게 영향을 주지 않고 복잡한 보고서를 실행할 수 있습니다.

아키텍처 검토

개념 증명이 끝나면 처음에 만든 기준에 따라 결과를 측정할 수 있습니다.

이 개념 증명을 반복하는 것이 좋습니다. 이후 반복할 때마다 학습한 내용을 적용할 수 있습니다. 반복을 짧게 유지하면 적용한 내용을 더 빨리 배울 수 있습니다. 그런데 이것은 Couchbase에만 해당되는 것이 아니라 모든 것에 해당됩니다!

마지막으로 개념 증명이 성공적이었다면(그리고 성공할 것이라고 확신합니다) 이제 프로덕션을 준비할 때입니다. 시간을 내어 아키텍처, 내린 결정, 잘된 점, 잘되지 않은 점 등을 검토하세요. 더 많이 문서화할수록 나머지 팀과 조직이 다음 프로젝트에서 더 나은 결과를 얻을 수 있습니다.

요약

이 5단계로 개념 증명을 작성하면 성공에 도움이 될 것입니다! 이제 시작하기만 하면 됩니다:

작성자

게시자 매튜 그로브스

Matthew D. Groves는 코딩을 좋아하는 사람입니다. C#, jQuery, PHP 등 무엇이든 풀 리퀘스트를 제출할 정도로 코딩을 좋아합니다. 90년대에 부모님의 피자 가게를 위해 QuickBASIC POS 앱을 만든 이후로 전문적으로 코딩을 해왔습니다. 현재 Couchbase의 선임 제품 마케팅 관리자로 일하고 있습니다. 여가 시간에는 가족과 함께 축구 경기를 관람하고 개발자 커뮤니티에 참여하며 시간을 보냅니다. 그는 .NET의 AOP, .NET의 프로 마이크로서비스, Pluralsight 저자, Microsoft MVP의 저자이기도 합니다.

모든 게시물 웹사이트

댓글 남기기