Cassandra에서 버전이 지정된 계층의 효율적인 모델링

면책 조항 :
이것은 꽤 긴 게시물입니다. 먼저 내가 다루는 데이터와이 데이터로 무엇을하고 싶은지 설명합니다.
그런 다음 숙제를 시도했기 때문에 고려한 세 가지 가능한 해결책을 자세히 설명합니다 (저는 맹세합니다 :]). 나는 첫 번째 솔루션의 변형 인 "최상의 추측"으로 끝납니다.

내 궁극적 인 질문은 : Cassandra를 사용하여 내 문제를 해결하는 가장 현명한 방법 은 무엇입니까? 내 시도 중 하나입니까, 아니면 다른 것입니까?
숙련 된 Cassandra 사용자로부터 조언 / 피드백을 찾고 있습니다.

내 데이터 :
트리 구조 (제목, 부제목, 섹션,…)의 문서를 소유하는 많은 SuperDocuments가 있습니다.

각 SuperDocument 구조는 시간이 지남에 따라 변경 될 수 있으므로 (대부분 제목의 이름 변경) 아래와 같이 여러 버전의 구조를 제공합니다.

내가 찾는 것 :
각 SuperDocument에 대해 위와 같이 날짜별로 해당 구조의 타임 스탬프를 지정해야하며 주어진 날짜에 대해 가장 가까운 이전 버전의 SuperDocument 구조를 찾고 싶습니다. (예 : 가장 최근 버전 version_date < given_date)

이러한 고려 사항은 문제를보다 쉽게 ​​해결하는 데 도움이 될 수 있습니다.

• 버전은 불변입니다. 변경은 거의 없으며 변경 될 때마다 전체 구조의 새로운 표현을 만들 수 있습니다.
• 구조의 하위 트리에 액세스 할 필요가 없습니다.
• 주어진 잎의 모든 조상을 찾을 필요가없고 나무 안의 특정 노드 / 잎에 접근 할 필요도 없다고 말하는 것이 괜찮다고 말하고 싶습니다. 전체 트리를 확보하면 클라이언트 코드에서이 모든 작업을 수행 할 수 있습니다.

좋아, 해보자. 나는 정말 카산드라를 사용하기 시작했다는 것을 명심 해라
. 데이터 모델링에 대한 많은 리소스를 읽거나 봤지만 현장에서 많은 (아무것도!) 경험이 없습니다!
그것은 또한 모든 것이 CQL3로 작성된다는 것을 의미합니다 ... 죄송합니다 Thrift 애호가!

이 문제를 해결하기위한 첫 번째 시도는 다음 표를 만드는 것이 었습니다.

CREATE TABLE IF NOT EXISTS superdoc_structures (
    doc_id varchar,
    version_date timestamp,
    pre_pos int,
    post_pos int,
    title text,

    PRIMARY KEY ((doc_id, version_date), pre_pos, post_pos)

) WITH CLUSTERING ORDER BY (pre_pos ASC);

그러면 다음과 같은 구조가됩니다.

여기 내 나무에 Nested Sets 모델 을 사용하고 있습니다. 나는 구조를 순서대로 유지하는 것이 잘 작동 할 것이라고 생각했지만 다른 제안에 열려 있습니다.

이 솔루션이 마음에 듭니다. 각 버전에는 고유 한 행이 있으며 각 열은 계층 수준을 나타냅니다.
하지만 문제는 내가 (솔직히) 내 데이터를 다음과 같이 쿼리하려고한다는 것입니다.

SELECT * FROM superdoc_structures 
    WHERE doc_id="3399c35...14e1" AND version_date < '2014-03-11' LIMIT 1

카산드라는 내가 그렇게 할 수 없다는 것을 재빨리 상기시켰다! (파티 셔 너가 클러스터 노드에서 행 순서를 유지하지 않기 때문에 파티션 키를 통해 스캔 할 수 없습니다)

그럼 ...?
글쎄, Cassandra는 파티션 키에 부등식을 사용하도록 허용하지 않기 때문에 그렇게하십시오! 클러스터링 키를
만들면 version_date모든 문제가 사라질 것입니다. 그래,별로 ...

첫 시도:

CREATE TABLE IF NOT EXISTS superdoc_structures (
    doc_id varchar,
    version_date timestamp,
    pre_pos int,
    post_pos int,
    title text,

    PRIMARY KEY (doc_id, version_date, pre_pos, post_pos)

) WITH CLUSTERING ORDER BY (version_date DESC, pre_pos ASC);

나는 이것이 덜 우아하다고 생각합니다. 모든 버전 과 구조 수준은 이전 솔루션과 비교하여 이제 매우 넓은 행의 열로 만들어집니다.

Problem: with the same request, using LIMIT 1 will only return the first heading. And using no LIMIT would return all versions structure levels, which I would have to filter to only keep the most recent ones.

Second try:

there's no second try yet... I have an idea though, but I feel it's not using Cassandra wisely.

The idea would be to cluster by version_date only, and somehow store whole hierarchies in each column values. Sounds bad doesn't it?

I would do something like this:

CREATE TABLE IF NOT EXISTS superdoc_structures (
    doc_id varchar,
    version_date timestamp,
    nested_sets map<int, int>,
    titles list<text>,

    PRIMARY KEY (doc_id, version_date)

) WITH CLUSTERING ORDER BY (version_date DESC);

The resulting row structure would then be:

It looks kind of all right to me in fact, but I will probably have more data than the level title to de-normalize into my columns. If it's only two attributes, I could go with another map (associating titles with ids for instance), but more data would lead to more lists, and I have the feeling it would quickly become an anti-pattern.
Plus, I'd have to merge all lists together in my client app when the data comes in!

ALTERNATIVE & BEST GUESS
After giving it some more thought, there's an "hybrid" solution that might work and may be efficient and elegant:

I could use another table that would list only the version dates of a SuperDocument & cache these dates into a Memcache instance (or Redis or whatever) for real quick access.
That would allow me to quickly find the version I need to fetch, and then request it using the composite key of my first solution.

That's two queries, plus a memory cache store to manage. But I may end up with one anyway, so maybe that'd be the best compromise?
Maybe I don't even need a cache store?

All in all, I really feel the first solution is the most elegant one to model my data. What about you?!