나는 카산드라를 배우고 있습니다. 이제, NoSQL이 다루는 SQL의 문제에 대해 생각하고 있으며, 매우 큰 데이터의 경우에 대한 질문이 있습니다.NoSQL의 한 파티션에서 데이터가 너무 큰 경우 쿼리가 느려지지 않도록하려면 어떻게해야합니까?
매우 큰 데이터를 처리하는 SQL에 대해 다른 서버에 테이블을 조인하기 때문에 테이블이 다른 서버에 있고 쿼리가 느리다는 것을 많은 페이지에서 말하고 있다고 생각했습니다. 이것은 NoSQL이 처리하는 SQL의 문제점입니다. 하지만 NoSQL을 사용하더라도 파티션이 너무 크면 데이터 모델을 변경하고 더 작은 파티션을 만들고 여러 쿼리를 만들어 동일한 결과를 얻지 않아도됩니까? 그리고, 느린가요? 또는 2B 셀이 충분히 크기 때문에 파티션의 공간이 부족하지는 않습니까?
귀하의 질문은 여러 가지 다른 문제가 혼합되어 있다고 생각합니다.
우선 큰 데이터와 SQL의 문제는 일반적으로 쿼리가 느려지지는 않지만 데이터가 커지면서 솔루션을 확장 할 수 없다는 것입니다. 제안한 것처럼 테이블을 여러 서버로 수동으로 분할하도록 선택한 경우 더 많은 서버가 필요할 때 무엇을합니까? 데이터 모델을 다시 디자인합니까? 또한 업데이트가 여러 테이블을 수정해야하지만 다른 호스트에있는 경우 어떻게 일관성을 보장합니까?
둘째, 조인을 언급했는데 이것은 카산드라와 같은 NoSQL 솔루션이 이 아닌을 지원하는 것입니다. 직접 데이터를 직접 비정규 화해야합니다 (즉, 이미 조인 된 데이터를 테이블에 넣어야합니다). 일부 경우 카산드라의 새로운 "Materialized Views"기능이 유용 할 수 있습니다.
셋째, 아마도 가장 중요한 것은 거대한 파티션에 대해 물었습니다. 실제로 Cassandra는 거대한 파티션을 처리하도록 설계되지 않았으며 최선의 방법은 언급 한 20 억 하드 한도를 훨씬 밑도는 것입니다. Datastax (카산드라 개발 회사의 상업용 회사)는 https://docs.datastax.com/en/dse-planning/doc/planning/planningPartitionSize.html에서 " 100,000 개 항목 이하의 최대 행 수 및 100MB 미만의 디스크 크기 ".
거대한 파티션이 카산드라에서 불필요한 이유는 여러 가지가 있습니다. 그 중 하나는 디스크 포맷 (sstables 및 이른바 "승격 된 인덱스")을 사용하면 거대한 파티션의 중간으로 점프하는 것이 비효율적이며 특정 행을 읽거나 반복 할 때이 작업을 수행해야한다는 것입니다 모든 행. 압축 및 복구와 같은 일부 작업은 전체 파티션에서 작동하며 매우 느려질 수 있습니다 (그리고 최악의 경우에도 많은 메모리를 사용합니다). 예를 들어 10 억 개의 행으로 구성된 파티션이 2 개의 노드에서 단 하나의 행으로 서로 다른 경우 파티션 기반 복구는 전체 파티션을 네트워크를 통해 전송해야합니다.
일반적으로 Apache Cassandra보다 효율적인 Scandex (https://en.wikipedia.org/wiki/Scylla_(database))는 거대한 파티션 (Cassandra와 마찬가지로 중간 크기의 파티션이 좋음)과 비슷한 문제가 있지만 이러한 문제는 다음을 포함하여 적극적으로 해결되고 있습니다. 파일 형식을 다시 설계하므로 결국 Scylla는 임의 크기의 파티션을 지원해야합니다. 그러나 아직 우리는 아직 존재하지 않으며, 오늘날 파티션이 너무 커지 않도록하는 권장 사항은 Scylla에도 적용됩니다.
마지막으로 단일 파티션에서 너무 많은 행 문제를 해결하려면 이러한 거대한 파티션을 피하기 위해 데이터 모델을 조정해야합니다. 때로는 모델에서 설계 실수를 수정하기 만하면됩니다. 예를 들어, 관련없는 데이터를 많은 수의 데이터가 동일한 파티션에 쌓여있는 것처럼 보았을 때 쉽게 분리 된 파티션에 넣을 수 있습니다. 때로는 파티션을 인위적으로 분할해야합니다. 이것은 Cassandra의 소위 "시계열 데이터"모델링에서 일반적입니다. 여기서 우리는 매초마다 새로운 측정 값을 얻고이를 파티션에 행으로 추가합니다. 여기서 모든 데이터에 대해 하나의 거대한 파티션을 갖는 대신, 시간 창당 별도의 파티션을 만드는 것이 허용됩니다 (예 : 매일 또는 새 파티션 또는 주간 등).대부분의 쿼리는 어쨌든 단 하나의 시간 창과 관련되기 때문에 더 느려지지 않습니다.