Windows 및 .NET을 사용하는 Couchbase - 2부

Windows 및 .NET을 사용하는 Couchbase - 2부 - Lingo

이 블로그 게시물은 시리즈의 2부입니다. 1부에서는 Windows에서 Couchbase를 설치하고 설정하는 방법에 대해 설명했습니다..

In 1부 - 설정를 얻는 방법에 대한 기본 사항을 보여 드렸습니다. 카우치베이스 서버 를 실행하고 있습니다. 여러분도 저처럼 코드에 들어가서 무엇을 할 수 있는지 보고 싶을 것입니다. 하지만 그 전에 Couchbase의 용어 몇 가지를 살펴보고 싶습니다. 사용하기 어려운 도구는 아니지만 여러분에게 익숙한 SQL Server와 같은 RDBMS 시스템과는 다릅니다. 따라서 이 블로그 포스트 시리즈는 저와 마찬가지로 여러분을 위한 것입니다: 저는 지금 배우면서 배우고 있습니다.

다음은 개발자의 관점에서 본 짧은 버전입니다: 카우치베이스 클러스터 포함 노드. 노드에는 다음이 포함됩니다. 버킷. 버킷에는 다음이 포함됩니다. 문서. 문서를 검색하는 방법은 여러 가지가 있습니다. N1QL를 사용하거나 뷰(맵/축소 사용)를 사용해서도 가능합니다. (카우치베이스 4.5, 부품 의 문서를 업데이트할 수 있습니다. 하위 문서 API). 이제 각 요소를 좀 더 자세히 살펴보겠습니다.

클러스터

우선 "클러스터." Couchbase의 강점 중 하나는 더 많은 데이터를 효율적으로 처리하기 위해 서버를 추가로 도입하는 스케일아웃 기능입니다. 이는 서버를 더 강력하고 빠른 서버로 교체하는 스케일업과는 대조적인 개념입니다(Couchbase에서도 가능합니다). 클러스터는 서로 협력하여 하나의 논리적 서버처럼 작동하는 관련 노드의 모음입니다. 클러스터에 노드가 하나만 있어도 항상 하나의 클러스터를 다루게 됩니다. "카우치"는 "신뢰할 수 없는 상품 하드웨어 클러스터"의 약자입니다.

노드

노드는 클러스터의 단일 구성 요소입니다. 일반적으로 하나의 서버에 해당합니다. 클러스터를 정의할 때 각 서비스별로 RAM 할당량을 정의합니다. 이것은 클러스터의 각 노드가 특정 서비스를 제공하는 데 사용할 RAM의 양입니다. 따라서 데이터 RAM 할당량이 2GB인 경우 데이터 서비스를 제공하는 클러스터의 각 노드는 2GB의 RAM을 사용할 수 있습니다. 또한 각 노드는 클러스터에 디스크 공간을 제공합니다.

노드는 데이터 저장, 인덱싱, 쿼리, 전체 텍스트 검색 등 하나 이상의 서비스를 제공합니다. 하나의 노드가 모든 서비스를 제공하는 것부터 각 서비스 유형에 대해 하나의 노드까지 원하는 대로 클러스터를 구성한 다음 스케일 아웃 및/또는 스케일 업할 수 있습니다. (예시: 데이터 저장용 노드를 5개 더 추가하고, 인덱싱용 노드를 1개 더 추가하고, 쿼리용 서버는 정말 강력한 단일 서버를 사용할 수 있습니다.)

노드는 다른 노드의 복제 데이터도 저장합니다. 이렇게 하면 다른 노드가 다운되면 복제 데이터가 활성으로 '승격'되어 애플리케이션이 정상적으로 작동할 수 있습니다.

코드 작성의 관점에서 볼 때 이러한 동작은 모두 투명해야 합니다. 클러스터의 노드 구성은 변경될 수 있고 변경될 것이지만 코드는 변경될 필요가 없습니다.

버킷

A 버킷 는 문서를 저장하는 공간입니다. 각 문서에는 키가 있습니다. 버킷 내에서 각 키는 고유해야 합니다. 버킷 안의 문서가 전혀 비슷할 필요는 없습니다. 사용자에 대한 정보가 포함된 문서와 건물에 대한 정보가 포함된 문서를 저장할 수 있습니다. 노드에 여러 개의 버킷을 구성할 수 있지만, 10개 이하의 버킷을 사용하는 것이 좋습니다. 관계형 데이터베이스에 비유하자면 버킷은 데이터베이스 인스턴스나 카탈로그와 비슷합니다. 테이블과는 다릅니다.

Couchbase가 빠른 이유는 각 버킷이 많은 문서를 RAM에 저장하기 때문입니다. 문서에 대한 요청이 들어올 때 문서(또는 적어도 문서의 메타데이터)는 이미 RAM에 저장되어 있을 가능성이 높으므로 디스크에 액세스할 필요가 없습니다. 새 문서나 업데이트된 문서가 들어오면 RAM에서 업데이트된 다음 대기열에 넣어 디스크에 쓰고 다른 노드에 복제합니다. 다른 문서를 위해 메모리를 확보해야 하는 경우, 메타데이터는 나중에 검색할 수 있도록 RAM에 남아 있으며, 해당 값만 추출됩니다( 그렇지 않으면 버킷을 구성합니다.).

문서

아주 기본적인 의미에서 Couchbase 버킷은 거대한 Dictionary에 불과합니다. 키는 고유한 것이면 무엇이든 사용할 수 있고, 값은 무엇이든 넣을 수 있습니다. 그러나 값에 JSON을 저장하기로 결정하면 구조, 인덱싱, N1QL, 보기 등의 추가 기능도 사용할 수 있습니다. 따라서 JSON이 아닌 값을 사용할 수 있고 지원되지만, 일반적으로 대부분의 값은 JSON으로 저장됩니다. 이것이 바로 Couchbase를 "문서 데이터베이스"라고 부르는 이유입니다. 각 버킷에는 다음이 포함됩니다. 문서값 및 관련 메타데이터(예: 키)입니다.

따라서 영어로는 다음과 같이 말하는 것이 합리적입니다:

• "이봐, 카우치베이스 클러스터 X, 버킷 'foo'에 있는 'bar' 키가 있는 문서의 값을 알려주세요."
• "안녕하세요, 카우치베이스 클러스터 X, 버킷 'foo'에 값이 'baz'인 새 문서가 있고, 키는 'qux'입니다.
• "안녕하세요, 카우치베이스 클러스터 X, 버킷 'foo'에서 'corge' 키가 있는 문서의 값을 'grault' 값으로 변경해 주세요.

N1QL

카우치베이스는 관계형 데이터베이스가 많은 개발자의 커리어에서 큰 부분을 차지해 왔다는 사실을 잘 알고 있습니다. 많은 개발자가 SQL을 작성하는 데 편안함을 느낍니다. 그러나 문서 데이터베이스는 실제로 관계형 데이터베이스와 같은 방식으로 작동하지 않기 때문에 완전히 새로운 작업 방식을 배워야 하는 경우가 많습니다. 하지만 Couchbase Server에서는 JSON 문서를 사용하는 경우 다음과 같은 언어로 쿼리를 작성할 수 있습니다. N1QL (N1QL은 "비-첫 번째 정규식 쿼리 언어"의 약자이며 "니켈"로 발음됩니다). N1QL은 SQL의 상위 집합입니다. 즉, 기본적으로 SQL을 알고 있다면 N1QL도 알고 있다는 뜻입니다. 몇 가지 차이점과 몇 가지 추가 키워드가 있지만, 얼마나 유사한지 보여드리기 위해 예시를 들어보겠습니다:

그러면 다음과 같은 내용이 반환됩니다:

이후 블로그 게시물에서 설명하겠지만 Linq2Couchbase 라이브러리는 N1QL을 활용하여 엔티티 프레임워크, NHibernate.Linq 또는 익숙한 다른 Linq 공급자와 매우 유사한 느낌의 Linq 공급자를 제공합니다.

색인

색인 는 관계형 데이터베이스에서와 마찬가지로 중요합니다. 아마도 더 중요한 이유는 Couchbase가 확장됨에 따라 처리할 수 있는 데이터의 양이 많기 때문일 것입니다.

버킷에서 N1QL 쿼리를 사용하려면 최소한 기본 인덱스를 만들어야 합니다. 이것은 버킷 자체에 있는 인덱스입니다. N1QL로 인덱스를 만드는 방법은 다음과 같습니다: 내 버킷에 기본 인덱스 만들기;

JSON 문서를 사용하는 경우 JSON 문서의 필드를 기반으로 인덱스를 만들 수 있습니다. 예를 들어 '이름' 또는 '작성자'가 있는 문서가 많고 이러한 필드를 기반으로 자주 쿼리하는 경우 해당 필드에 대한 인덱스를 만들 수 있습니다. 이를 "보조 인덱스"라고 합니다.

결론

저도 여러분만큼이나 코드에 뛰어들고 싶지만, 먼저 이 용어를 정리해 두는 것이 좋습니다. 일부 세부 사항을 희생하면서까지 가장 중요한 개념에 집중하려고 노력했습니다. 질문이 있으시면 아래에 댓글을 남겨 주세요, 트위터로 문의하기를 참조하거나 matthew.groves AT couchbase DOT com으로 이메일을 보내주세요. 여러분의 의견을 듣고 싶습니다.