ID와 Blob을 저장하는 간단한 CQL 테이블을 사용하면 수십억 개의 행을 저장할 때의 문제 또는 성능 영향이 있습니까?Cassandra 2.0.2 CQL 긴 행 제한/성능 영향
이전 버전의 카산드라에서는 넓은 행을 사용하는 것으로 알고 있었지만 CQL을 사용하면이 문제를 해결할 수 있습니다. 데이터가 함께 클러스터되거나 어떤 순서로든 필터링 할 수 있도록하는 특별한 요구 사항이 없습니다. 나는 CQL 테이블의 많은 행이 어떤 식 으로든 문제가 될 수 있는지 궁금합니다.
내 데이터를 비닝하는 것이 좋습니다. 즉, ID의 해시 % n 인 파티션 키를 만들고 n 빈 (수백만 개)으로 데이터를 제한 할 것입니다. 그 오버 헤드를 추가하기 전에 실제로 그것이 가치 있는지 여부를 확인하고 싶습니다.
처음에는 정확하지 않다고 생각합니다.
이전 버전의 카산드라에서는 로우가 많았지 만 CQL은 우리가 그걸 벗어나도록 권장하는 것 같습니다.
넓은 행이 지원됩니다. Jonathan Ellis의 게시물이 있습니다. Does CQL support dynamic columns/wide rows? :
일반적인 오해는 CQL이 동적 열이나 넓은 행을 지원하지 않는다는 것입니다. 반대로 CQL은 Thrift 모델로 수행 할 수있는 모든 작업을 지원하지만 더 쉽고 편리하게 사용할 수 있도록 설계되었습니다.
"잠재적으로 수십억 개의 행을 저장할 때 성능에 미치는 영향"에 대해서는이 행의 크기를 기억해야합니다. 아론 모튼에 따르면
이 mail thread :
행이 느려질 수 MB 것들의 몇 10 년대 위에 도착하면 그들이 50메가바이트 위 얻을 때 공간이 100MB 이상 얻을 때, 그들은, 통증이있을 수 있습니다 그것은 경고 신호입니다. 그리고 그들이 1GB를 초과 할 때, 당신은 당신이 그 때 무슨 일이 일어나는지 알고 싶지 않습니다.
이상 :
큰 행은 압축을 통해 이동하는 데 시간이 더 걸릴 더 JVM GC와 을 야기하는 경향이 수리하는 동안 문제가 있습니다. yaml 파일 의 in_memory_compaction_limit_in_mb 주석을 참조하십시오. 수리하는 동안 우리는 행 범위의 차이점을 감지하고 노드 사이에서 이들을 스트리밍합니다. 너비가 넓은 열과 단일 열이 동기화되어있는 경우 노드에서 해당 행의 새 복사본을 만들고 압축해야합니다. 매우 넓은 행을 가진 노드의로드가 에 의해 150GB 아래로 내려가는 것을 보았습니다. 압축 설정을 줄였습니다.
IMHO 모든 것이 10의 몇 안되는 행에서 동일합니다.
Aaron Morton (마지막 피클)과의 대화에서 그는 테이블 당 수십억 개의 행이 반드시 문제가되지 않는다고 지적했습니다.
"이보다 더 많은 것을 알고있는 사람과 대화를 나눈"과 같이이 답변을 남겨 두지 만 특별히 과학적이지는 않습니다.
답장을 보내 주셔서 감사합니다. 사실, 저는 제 질문에 틀린 말을했을 수도 있습니다. 나는 주로 행의 크기보다는 CQL 테이블에 잠재적으로 수십억 개의 행이있는 성능에 영향이 있는지 걱정하고 있습니다. –
테이블에 수십억 개의 행 또는 테이블에 수십억 개의 열이 있습니까? –
테이블에 수십억 개의 행이 있습니다. 질문을 수정합니다. –