NoSQL : 비정형 데이터 란 무엇입니까?

우리는 현재 mssql 서버 기반 솔루션으로 리소스의 가장자리에서 실행 중입니다.

우리는 이제 짐을 다루기위한 다음 움직임에 관한 많은 전통적인 옵션을 가지고 있습니다 :

• 더 빠른 CPU 및 IO 구매
• 일부 고객을 분리하여 서버 분리
• DB를 클러스터로 이동

라이센스 및 하드웨어 또는 시간면에서 모두 비쌉니다. 따라서 전체 시스템을 SQL 엔진 cassandra가 약속하지 않는 확장 가능한 솔루션으로 이동하여 다른 옵션을 추가하고 싶습니다.

그러나 나는 SQL 데이터베이스에 대해 잘 모르고 경험이 없으므로 "비정형"데이터의 구조를 이해해야합니다.

애플리케이션에서 기본적으로 사용자가 입력 한 데이터를 다양한 방법으로 "키-값"목록으로 저장합니다. 주 요소와 같은 헤드 요소를 포함하는 상위 테이블이 있고 주문의 내용을 구성하는 키-값 쌍이있는 하위 테이블이 있습니다 (예 : Order_Lines).

비즈니스 측면에서 주문 및 주문 라인은 하나의 단위입니다. 그러나 RDBMS로 인해 테이블에 저장되며 항상 결합되어야합니다.

작업 중에 때때로 상단 부분 만로드하도록 선택하지만 대부분의 경우 헤드 행과 일부 KVP를로드하여 유용한 정보를 표시합니다.

예를 들어, 개요 목록에서 헤드 식별자 + 일부 값을 각 행의 열에 표시합니다.

업데이트 : 우리는 모든 종류의 양식을 저장합니다. 기본적으로 "문서"를 저장합니다. 그럼에도 불구하고, 우리는 이러한 양식을 어떤 값, 정렬 등으로도 준비하고 검색해야합니다. 데이터 액세스 제어는 데이터베이스에 또 다른 계층의 요소를 추가합니다.

짐작할 수 있듯이 특정 KVP의 양과 가용성은 개체마다 다릅니다. 서로 다른 데이터 조합에 대해 수천 개의 테이블을 작성해야하므로 각 유형의 오브젝트에 대해 단일 테이블을 작성할 수있는 유효한 가능성이 없습니다.

데이터 셋과 같은 이러한 "사전"이 noSQL 데이터베이스에 더 잘 저장됩니까? 그리고 이것으로부터 성능상의 이점이 있습니까? cassandra가이 head + KVP를 하나의 데이터 세트로 모델링 할 것입니까? cassandra 웹 페이지와 일부 자습서를 살펴보면 데이터 구성 측면에서 RDBMS와 cassandra 사이에 큰 차이가 없다는 인상을 받았습니다. 각 행의 목록.

깨달음은 환영합니다, 또한 문제를 설명하는 논문에 대한 포인터는 괜찮습니다.

구별해야 할 몇 가지 개념이 있습니다. 하나는 구조에 관한 것이고 다른 하나는 스키마에 관한 것입니다.

구조화 된 데이터는 응용 프로그램이받는 각 바이트의 의미를 응용 프로그램이 미리 알고있는 데이터입니다. 좋은 예는 센서의 측정입니다. 반면 트위터 스트림은 구조화되어 있지 않습니다. 스키마는이를 적용하도록 요청 된 방법으로 DBMS에 전달되는 구조의 양에 관한 것입니다. DBMS가 저장하는 데이터를 구문 분석하는 정도를 제어합니다. SQL Server와 같은 스키마 필수 DBMS는 구문 분석되지 않은 데이터 (이진) 또는 선택적으로 구문 분석 된 데이터 (xml) 및 완전 구문 분석 된 데이터 (열)를 저장할 수 있습니다.

NoSQL DBMS는 구문 분석 (키-값 저장소)이없는 스펙트럼에 있습니다. Cassandra는 이와 관련하여 풍부한 기능을 제공합니다. 관계형 상점과 현저하게 다른 곳은 데이터의 균일성에 있습니다. 테이블이 정의되면 해당 정의와 일치하는 데이터 만 보유 될 수 있습니다. 그러나 Cassandra에서는 열과 패밀리가 정의되어 있어도 같은 테이블에있는 두 행이 서로를 보일 필요가 없습니다. 단일 행에 들어가는 양 (문서라고도 함)과 포인터로 연결된 개별 항목을 결정하는 것은 응용 프로그램 디자이너에게 달려 있습니다. 실제로, 얼마나 많은 비정규 화를 원하십니까?

장점은 단일 순차 읽기로 전체 데이터 세트를 검색 할 수 있다는 것입니다. 이것은 빠르다. 한 가지 단점은 애플리케이션 프로그래머 인이 데이터 저장소에 닿는 모든 코드의 모든 데이터 무결성 및 이전 버전과의 호환성 문제에 대한 책임은 전적으로 사용자에게 있다는 것입니다. 제대로 이해하기 어려울 수 있습니다. 또한 데이터에 대한 한 가지 관점에 잠겨 있습니다. 주문 번호로 행을 입력하면 특정 제품, 지역 또는 고객에 대한 판매를 어떻게보고합니까?

noSQL 데이터베이스 IMHO의 주류 임에도 불구하고 이러한 기술을 채택하는 것에 대한 결정은 현재 보유하고있는 성능뿐만 아니라 저장된 정보에 따라 필요한 성과에 따라 이루어져야합니다. 이것은 아마도 가장 좋은 방법은 SQL 데이터베이스를 고수하고 HW를 향상시키는 것입니다.

그러나 또한 나는 당신의 질문에서 나를 생각하게 한 것을 읽었습니다. 데이터베이스의 현재 상태는별로 없지만 "기본적으로 사용자가 입력 한 데이터를"키-값 "목록으로 다양한 방식으로 저장합니다"라는 문장 은 문제가 데이터 모델이 아니라 열악한 것이 아니라고 생각하게합니다. 물리적 자원의 부족. "전통적인"SQL 데이터베이스에서 놀라운 성능으로 실제로 큰 테이블 (100 억 행)을 관리했습니다.

나는 그것이 틀렸다고 말하는 것이 아닙니다. 물론 현재 솔루션에 대한 작은 정보로 올바른 데이터 모델에서 당신을 평가할 수는 없지만 데이터 모델을 다른 옵션과 함께 추가 옵션으로 다시 방문하는 것을 생각하십시오. 거기에 약간의 실마리가있을 수 있습니다.

일반적으로 키-값 목록은 모델을 최종 상태로 구현할 수없는 경우 직면해야 할 여러 키를 모르거나 가능한 값 중 하나의 값이 필요할 때 트레이드 오프로 사용하기에 좋습니다. 특정 요소의 키. 그러나 구현할 때는 일반적으로 일반적인 사용 사례를 식별하고 데이터 모델 결정이 최선인지 여부를 결정하기에 충분한 양의 정보를 수집 한 후 잠시 후에 이러한 결정을 다시 생각하고 싶습니다. 일정한 수의 키가 있다는 것을 알고 있다면 전통적인 방식으로 일반 테이블 디자인으로 벤치 마크를 시도하십시오.

CREATE TABLE benchmarkTable (
  element INTEGER,
  key1 VARCHAR(xx),
  key2 INTEGER,
  key3 DECIMAL(5,2),
...
);

... 해당 지수를 추가합니다. 두 가지 방법으로 시도해보고 실행 계획을 측정하십시오. 한 번에 하나 이상의 키를 수집하면 데이터 블록 크기를 줄여 성능을 향상시킬 수 있기 때문에 특히 놀라게 될 수 있습니다.

이것이 도움이되거나 최소한 가능성을 넓히고 새로운 조사의 길을 열어 주길 바랍니다.