NoSQL이 무엇이고 Couchbase가 그 그림에 어떻게 들어맞는지 설명할 때 관계형 데이터베이스에 대한 질문을 받곤 하는데, 이 둘을 비교하지 않을 수 없습니다. 아키텍처는 상당히 다르지만 개념에서 몇 가지 유사점을 찾을 수 있습니다. 이 글은 이러한 유사점을 이해하기 위해 2분 정도 읽어보시기 바랍니다.
표/열 V.S. 문서
개발자의 관점에서 시작하겠습니다. 개발자는 코드에서 종종 도메인 개체를 조작합니다. 이러한 객체 중 일부는 데이터베이스에서 읽거나 데이터베이스에 유지됩니다. 관계형 DB에서 개체는 열로 구성된 테이블에서 하나 이상의 행으로 표현됩니다. 열에는 이름과 유형이 있습니다. 문서 DB에서 문서는 전통적으로 키/값 쌍이며, 값은 JSON 문서(JSON 문자열)입니다. 키/값 DB가 개발자에게 값을 기반으로 문서를 쿼리할 수 있는 방법을 제공할 때 문서 DB라는 용어를 사용합니다.
JSON 문서에는 여러 개의 필드가 있을 수 있으며 각 필드에는 이름과 유형이 있습니다. 따라서 비유를 좀 더 확장하면 JSON을 사용하면 문서별로 유연한 열 집합을 가질 수 있습니다. 즉, 모든 테이블/열을 한 번만 정의할 필요가 없습니다. 문서 DB에서 필요에 따라 유연하게 수정할 수 있습니다. 이것이 바로 스키마리스 에 관한 것입니다. 스키마가 없는 것이 아니라 스키마를 쉽게 변경할 수 있는 것이 중요합니다. JSON 문서의 입력된 필드는 유연한 추론 스키마인 스키마를 만듭니다.
세분화라는 주제를 테이블에 올려놓고 우리의 새로운 하위 문서 API. 이 기능은 Couchbase 4.5에서 제공될 예정입니다. 관계 데이터베이스에서는 특정 열의 특정 행을 수정하거나 읽을 수 있기 때문에 개체의 특정 필드를 수정하거나 읽을 수 있습니다. JSON 문서와 동일하게 JSON 문서의 특정 필드를 수정하거나 읽는 것입니다. 이것이 바로 하위 문서 API를 통해 할 수 있는 일입니다.
SQL 쿼리를 실행할 때 FROM 절은 테이블을 참조합니다. Couchbase에는 선언적 쿼리 언어인 N1QL. 이는 SQL의 상위 집합이므로 다른 것들 사이에서 조인을 수행할 수 있습니다. cool 물건. 그리고 카우치베이스에는 테이블이 없기 때문에 FROM 절은 버킷에 적용됩니다. JOIN 쿼리도 버킷 간에 이루어집니다. 이제 다음 주제로 넘어가겠습니다.
스키마 V.S. 버킷
테이블과 열은 일반적으로 스키마 또는 데이터베이스(저장 프로시저, 구체화된 뷰, 카운터 등과 같은 다른 것들과 함께)라고 하는 곳에 저장됩니다. Couchbase에서는 문서가 버킷에 저장됩니다. 옵션과 기능의 집합은 상당히 다릅니다. 보안을 예로 들어보겠습니다. 관계형 데이터베이스에서는 테이블의 특정 열에 대한 권한까지 지정할 수 있습니다. 버킷에서는 키/값 쌍만 저장할 수 있습니다. 따라서 이에 대한 권한만 부여할 수 있습니다. 즉, 특정 사용자에게만 버킷에 대한 읽기 또는 읽기/쓰기 권한만 부여할 수 있습니다. 따라서 보안을 강화하려면 애플리케이션 수준에서 수행해야 합니다. 이것은 지금 당장 NoSQL DB를 선택할 때 감수해야 하는 트레이드 오프 중 하나이며, 관계형 DB에 있던 애플리케이션 로직 중 일부가 애플리케이션 계층으로 이동하게 됩니다. 이것이 좋은 것인지 아닌지는 논쟁의 여지가 있습니다.
개발자로서 저는 코드에 로직이 있는 것을 선호하지만 이것은 제 의견일 뿐입니다. 아래 댓글에서 이에 대한 토론을 시작할 수 있습니다.) 여러분의 생각을 알려주세요! 이 주제를 이 범위를 넘어 클러스터, 복제 및 샤딩에 대해 이야기 할 수도 있지만 더 이상 2 분 이상 읽지 않을 것입니다 :)
