표 디자인 카산드라

Question

나는 서로 다른 센서를 가지고 있다고 말하는 기계의 데이터를 유지하려고합니다.

CREATE TABLE raw_data (
    device_id uuid, 
    time timestamp, 
    id uuid, 
    unit text, 
    value double, 
    PRIMARY KEY ((device_id, unit), time) 
) 

데이터를 전송할 때 어떤 센서를 사용했는지 알아야합니다. "sensor_id"필드를 추가하고 센서 관련 데이터를 다른 테이블에 저장할 수 있습니다. 이 접근법에 대한 문제점은 변경할 수있는 센서 (A, B, C)의 위치를 ​​저장해야한다는 것입니다. 센서 테이블의 위치를 ​​변경하면 이전 데이터가 무효화됩니다.

저는 아직도 관계형으로 많은 것을 생각하고 있습니다. 이 문제를 어떻게 해결 하시겠습니까?

Answer 1

테이블 설명이 주어지면 device_id가 기기의 식별자 (또는 PK)라고 말하고 싶지만 이것은 분명히 생각한 바가 아닙니다 ... 그리고 이것이이 문제의 근원입니다.

나는 보행자를보고 싶지 않지만 관계형 모델에서 관계는 테이블 간의 관계가 아니라 관계 (또는 관계가 아니라) , 즉. PK를 포함한 PK를 포함하여 "도메인 값"에서 취한 값 (그물에서 쉽게 찾을 수있는 Codd의 관계형 모델 정의 참조). 관계형 모델에서 테이블은 관계이고 쿼리 (조인을 포함한 SQL의 SELECT)도 관계입니다. NoSQL이 있더라도 엔티티는 최소한 최소한의 상식 모델링 인 최소한 처음 3 가지 정규형 (원 자성과 pk에 대한 의존성)을 따라야합니다.

PK에 관해서는 관계형 모델에서 자연 대 서브 로트 (부 자연스럽게 계산 된) 기본 키에 대한 화제가 있습니다. 나는 자연스럽고 종종 합성하는 경향이 있지만, 이것은 단지 의견이며, 물론 맥락에 달려있다.

데이터 모델 단위가 (IMHO) PK의 일부가되어서는 안됩니다 : 장치를 식별하지 않습니다. 이는 장치의 특성입니다. PK는 장치를 고유하게 식별해야하며 위치 또는 위치, 장치 또는 장치의 다른 특성이 아닙니다. 고유 한 ID, 일련 번호, 다른 특성의 조합은 장치에 고유하며 시간이나 다른 차원에서 변경되지 않습니다.

예를 들어 장치가 내장 된 차량의 경우, 장치에 대한 추가 정보를 검색하기 위해 참조 테이블을 사용하여 각 내장 장치에 대해 불투명 한 uuid PK를 제공 할 수 있습니다. : 자동차 제조업체, 자동차 일련 번호 (sno), 장치 유형, 장치 ID. 예를 들어 같은 :

CREATE TABLE raw_data (
    car_maker text, 
    car_sno text, 
    device_type text, 
    device_id text, 
    time timestamp, 
    id uuid, 
    unit text, 
    value double, 
    PRIMARY KEY ((car_maker, car_sno, device_type, device_id), time) 
) 

예를 들어 데이터 :

가

('bmw', '1256387A1AA43', 'tyrep', 'tyre1', 'bar', 150056709xxx, 2.4), 
('bmw', '1256387A1AA43', 'tyrec', 'tyre1', 'tempC',150056709xxx, 150), 
('bmw', '1256387A1AA43', 'tyrep', 'tyre2', 'bar', 150056709xxx,2.45), 
('bmw', '1256387A1AA43', 'tyrec', 'tyre2', 'tempC', 150056709xxx, 160), 
('bmw', '1256387A1AA43', 'tyrep', 'tyre3', 'bar', 150056709xxx,2.5), 
('bmw', '1256387A1AA43', 'tyrec', 'tyre3', 'tempC', 150056709xxx, 150), 
('bmw', '1256387A1AA43', 'tyre', 'tyre4', 'bar', 150056709xxx,2.42), 
('bmw', '1256387A1AA43', 'tyre', 'tyre4', 'tempC', 150056709xxx, 150), 

이것은 일반적인 생각과 문제에 정렬해야합니다. 때때로, uuids 및 계산 된 키가 가장 좋습니다.

카산드라를 사용하면 PK의 첫 번째 부분이 파티션 키이고 쿼리 할 수 ​​없기 때문에 (예 : 다음과 같이 다른 시스템을 매김하거나 어렵게 만드는 등) 쿼리를 모델링해야합니다. 스파크).

관계형을 너무 많이 생각하지 마십시오. 중복되는 것을 두려워하지 마십시오. 그리고 나는 카산드라 다이어그램을보고, 카산드라 스키마를 설계 할 때 도와 줄 수 있다고 제안한다. 쿼리는 here 또는 here이다.

최고의

,

알랭