나는 카산드라에 중첩 된 동적 문서를 저장하는 방법을 모색하고 각 행 많은 JSON 객체 만 몇 행과 상점을 작성하는 것이 좋습니다 프레젠테이션을 발견 해요 : https://speakerdeck.com/dzello/store-json-the-hard-way?slide=112왜 누군가가 하나의 카산드라 행에 여러 행을 저장합니까?
내가 기반의 열 이름을 만들 수있는 아이디어를 이해를 속성 경로에서, 그리고 작은 개체를 연결하면 일반적으로 처리량이 높아진다는 것을 알았지 만 오버 헤드가 많다고 생각합니다.
행당 하나의 개체를 저장하는 C *의 성능이 너무 나빠 목록을 만드는 데 어려움이 있습니까? C *에 대해 내가 누락 된 부분이 있을까요?
스토어에서 Json the Hard Way 슬라이드는 Cassandra의 정상 작동 외에도 많은 양의 보조 압축 및 삭제 표시를 수행하는 Cassandra의 전문가입니다.
데이터 지역성은 성능면에서 중요하며 단일 C * 파티션에 여러 논리 행이있는 것이 중요합니다. 모든 CQL 스키마 정의는 개발자가 동일한 파티션에 어떤 데이터가 들어가는지를 쉽게 지정할 수 있도록하기위한 것입니다. 예를 들어
CREATE TABLE soda_sold_per_store (
store text, date timestamp, soda_name text, soda_count int,
PRIMARY KEY (store,date,soda_count,soda_name)
를 들어
은 모든 상점과 정보가 soda_name에 다음 soda_count 마지막 날짜를 기준으로 정렬됩니다 파티션 내의 단일 카산드라 파티션이 테이블을 설명합니다.시간이 지남에 따라 특정 저장소에서 판매되는 음료수의 수를 쿼리하는 쿼리는 매우 빠릅니다 (디스크에서 이미 정렬 된 인접한 데이터의 단일 파티션에만 부딪 쳤습니다). 다른 쿼리는이 스키마에서 매우 어려울 것입니다. "특정 날짜에 모든 매장에서 판매되는 총 소다수는 얼마입니까?" 모든 저장소를 포함하는 쿼리는이 테이블을 사용하는 모든 노드에서 데이터를 수신해야하며 데이터가 디스크에서 연속되지는 않습니다. Cassandra는 이러한 종류의 절충안을 부과합니다. 모델링 된 테이블은 매우 빠르지 만 특정 쿼리에 대해서만 빠를 수 있습니다. 다행스럽게도 Cassandra는 매우 저렴하므로 여러 테이블을 보유하고 있으며 각 테이블은 수요가 많은 쿼리 중 하나를 만족시키는 것이 일반적입니다.