NoSQL 데이터베이스의 특성

2.1 NoSQL이라는 용어의 등장

최근 "NoSQL"이라는 용어가 매우 유행하고 인기를 얻었으며 모든 종류의 소프트웨어 솔루션이 이 기호 아래에서 적극적으로 개발 및 홍보되고 있습니다. NoSQL은 엄청난 양의 데이터, 선형 확장성, 클러스터, 내결함성, 비관계성과 동의어가 되었습니다. 그러나 NoSQL 스토리지가 무엇인지, 용어가 어떻게 등장했는지, 그리고 공통적인 특징이 무엇인지 명확하게 이해하는 사람은 거의 없습니다. 이 격차를 메우도록 노력합시다.

이 용어의 가장 흥미로운 점은 90년대 후반에 처음 사용되었음에도 불구하고 2009년 중반에 현재 사용되는 형태에서만 진정한 의미를 얻었다는 것입니다. - 모든 데이터를 ASCII 파일로 저장하고 SQL 대신 셸 스크립트를 사용하여 데이터에 액세스하는 Carlo Strozzi가 만든 소스 데이터베이스. 현재 형태의 "NoSQL"과는 아무런 관련이 없습니다.

2009년 6월 Johan Oskarsson은 샌프란시스코에서 회의를 조직하여 IT 스토리지 및 처리 시장의 새로운 경향에 대해 논의했습니다. 회의의 주요 추진력은 BigTable 및 Dynamo와 같은 새로운 오픈 소스 제품이었습니다. 회의의 밝은 표시를 위해 트위터 해시태그에 딱 맞는 크고 간결한 용어를 찾아야 했습니다. 이러한 용어 중 하나는 RackSpace의 Eric Evans가 제안한 "NoSQL"입니다. 이 용어는 단 한 번의 회의를 위해 계획되었고 의미 론적으로 깊은 부하가 없었지만 바이럴 광고처럼 글로벌 네트워크 전체에 퍼져 사실상 IT 산업의 전체 트렌드의 이름이되었습니다. 그건 그렇고, Voldemort (Amazon Dynamo 클론), Cassandra, Hbase (Google BigTable의 아날로그), Hypertable, CouchDB, MongoDB가 회의에서 연설했습니다.

"NoSQL"이라는 용어는 그 기원이 완전히 자발적이며 일반적으로 인정되는 정의나 과학적 제도가 없다는 점을 다시 한 번 강조할 가치가 있습니다. 이 이름은 오히려 관계형 데이터베이스에서 벗어난 IT 개발 벡터의 특징을 나타냅니다. No SQL의 직접적인 정의를 지지하는 사람들이 있지만 Not Only SQL의 약자입니다. Pramod Sadalaj와 Martin Fowler는 최근 저서 "NoSQL Distilled"에서 NoSQL 세계에 대한 지식을 그룹화하고 체계화하려고 했습니다.

2.2 NoSQL 데이터베이스의 기본 특성

많은 이기종 시스템이 현재 NoSQL 레이블 아래 숨겨져 있기 때문에 모든 NoSQL에 대한 공통적인 특성은 거의 없습니다(아마도 가장 완전한 목록은 http://nosql-database.org/에서 찾을 수 있음). 많은 특성은 특정 NoSQL 데이터베이스에만 해당되며 나열할 때 분명히 언급하겠습니다.

1. SQL을 사용하지 않는다

많은 데이터베이스가 잘 알려진 선호 구문과 유사한 쿼리 언어를 사용하려고 시도하지만 아무도 완전히 구현하지 못했고 성공할 가능성이 없기 때문에 ANSI SQL DML을 의미합니다. 예를 들어 hadup( http://www.drawntoscalehq.com/ 및 http://www.hadapt.com/ ) 에서 SQL을 구현하려고 시도하는 신생 기업이 있다는 소문이 있지만 .

2. 비정형(스키마리스)

의미는 관계형 데이터베이스와 달리 NoSQL 데이터베이스에서는 데이터 구조가 규제되지 않는다는 것입니다(프로그래밍 언어와 유추할 경우 약하게 입력됨). 먼저 선언적으로 구조를 변경하지 않고도 별도의 줄이나 문서에 임의의 필드를 추가할 수 있습니다. 전체 테이블의. 따라서 데이터 모델을 변경해야 하는 경우 애플리케이션 코드의 변경 사항을 반영하는 것만으로도 충분합니다.

예를 들어 MongoDB에서 필드 이름을 바꿀 때:

BasicDBObject order = new BasicDBObject();
order.put("date", orderDate); // this field was a long time ago
order.put("totalSum", total); // before we just used "sum"

응용 프로그램 논리를 변경하면 읽을 때도 새 필드가 필요합니다. 그러나 데이터 스키마가 없기 때문에 이미 존재하는 다른 주문 개체에서 totalSum 필드가 누락되었습니다. 이 상황에서 추가 조치를 위한 두 가지 옵션이 있습니다.

첫 번째는 모든 문서를 크롤링하고 모든 기존 문서에서 이 필드를 업데이트하는 것입니다. 데이터의 양으로 인해 이 프로세스는 잠금 없이 발생하므로(alter table rename column 명령과 유사) 업데이트 중에 이미 존재하는 데이터를 다른 프로세스에서 읽을 수 있습니다. 따라서 애플리케이션 코드를 확인하는 두 번째 옵션은 불가피합니다.

BasicDBObject order = new BasicDBObject();
Double totalSum = order.getDouble("sum"); // This is the old model
if (totalSum  == null)
totalSum = order.getDouble("totalSum"); // This is the updated model

그리고 이미 다시 녹음할 때 이 필드를 새로운 형식으로 데이터베이스에 쓸 것입니다.

스키마가 없는 유쾌한 결과는 희소 데이터 작업의 효율성입니다. 한 문서에 date_published 필드가 있고 두 번째 문서에는 없으면 두 번째 문서에 대해 빈 date_published 필드가 생성되지 않습니다. 이것은 원칙적으로 논리적이지만 덜 분명한 예는 친숙한 테이블/열 개념을 사용하는 열 계열 NoSQL 데이터베이스입니다. 그러나 스키마가 없기 때문에 열은 선언적으로 선언되지 않으며 사용자의 데이터베이스 세션 중에 변경/추가될 수 있습니다. 이를 통해 특히 목록 구현을 위해 동적 열을 사용할 수 있습니다.

구조화되지 않은 스키마에는 단점이 있습니다. 위에서 언급한 데이터 모델을 변경할 때 애플리케이션 코드의 오버헤드 외에도 기본에서 모든 종류의 제한이 없다는 점(null, 고유, 검사 제약 조건 등)이 없습니다. 다른 프로젝트의 데이터베이스를 병렬로 작업할 때 구조 데이터를 이해하고 제어하는 ​​데 추가적인 어려움이 있습니다(데이터베이스 측면에 사전이 없음). 그러나 급변하는 현대 사회에서 이러한 유연성은 여전히 ​​장점입니다. 예를 들어 Twitter는 5년 전에는 트윗과 함께 약간의 추가 정보(시간, Twitter 핸들 및 몇 바이트의 추가 메타 정보)만 저장했지만 지금은 메시지 자체 외에도 몇 가지 더 많은 정보를 저장했습니다. 킬로바이트의 메타데이터가 데이터베이스에 저장됩니다.

(이하 주로 key-value, document 및 column-family 데이터베이스에 대해 설명하며, 그래프 데이터베이스에는 이러한 속성이 없을 수 있음)

2.3. 집계(aggregates) 형식의 데이터 표현

정규화 목적으로 애플리케이션의 논리적 비즈니스 엔터티를 다양한 물리적 테이블에 저장하는 관계형 모델과 달리 NoSQL 저장소는 이러한 엔터티에서 전체적인 개체로 작동합니다.

이 예는 표준 전자 상거래 개념적 관계형 모델 "주문 - 주문 항목 - 결제 - 제품"에 대한 집계를 보여줍니다. 두 경우 모두 주문은 위치와 하나의 논리적 개체로 결합되는 반면 각 위치는 제품에 대한 링크와 일부 속성(예: 이름)을 저장합니다(이러한 비정규화는 검색할 때 제품 개체를 요청하지 않기 위해 필요합니다. 주문 - 분산 시스템의 기본 규칙은 개체 간의 "조인"입니다. 하나의 집계에서 지불은 주문과 결합되고 객체의 필수 부분이며 다른 하나는 별도의 객체에 배치됩니다. 이것은 NoSQL 데이터베이스에서 데이터 구조를 설계하기 위한 기본 규칙을 보여줍니다. 애플리케이션의 요구 사항을 준수하고 가장 빈번한 요청에 대해 가능한 한 많이 최적화되어야 합니다.

쿼리가 집계 구조에 적합하지 않을 때 데이터에 대한 임의 쿼리를 시도할 때 종종 비정규화된 대형 객체로 작업하는 데 많은 문제가 있다는 점을 지적하면서 많은 사람들이 이의를 제기할 것입니다. 주문 라인 항목 및 결제와 함께 주문을 사용하지만(앱이 작동하는 방식임) 비즈니스에서 지난 달에 판매된 특정 제품의 단위 수를 세도록 요청하는 경우 어떻게 됩니까? 이 경우 OrderItem 테이블을 스캔하는 대신(관계형 모델의 경우) NoSQL 스토리지에서 전체 주문을 검색해야 하지만 이 정보가 많이 필요하지는 않습니다. 불행히도 이것은 분산 시스템에서 이루어져야 하는 절충안입니다. 기존의 단일 서버 시스템에서처럼 데이터를 정규화할 수 없습니다.

두 접근 방식의 장단점을 표로 그룹화하려고 했습니다.