답변:
은 총알과 같은 것은 없으며 모든 것은 특정 문제를 해결하기 위해 만들어졌으며 자체 장단점이 있습니다. 어떤 문제 설명을 가지고 있으며 해당 문제에 가장 적합한 솔루션은 무엇입니까?
질문과 같은 순서로 질문에 하나씩 답변 해 드리겠습니다. Cassandra는 NoSQL 데이터베이스 제품군을 기반으로하므로 질문에 대답하기 전에 NoSQL 데이터베이스를 사용해야하는 이유를 이해하는 것이 중요합니다.
NoSQL을 사용하는 이유
RDBMS의 경우,이 범주의 MySQL, Oracle, MS SQL, PostgreSQL과 같은 모든 데이터베이스는 ACID 속성을 지향하는 거의 동일한 종류의 솔루션을 제공하므로 선택이 매우 쉽습니다. NoSQL의 경우 모든 NoSQL 데이터베이스가 서로 다른 솔루션을 제공하므로 앱 / 시스템 요구 사항에 가장 적합한 솔루션을 이해해야하기 때문에 결정이 어려워집니다. 예를 들어 MongoDB는 시스템에 스키마가없는 문서 저장소가 필요한 사용 사례에 적합합니다. HBase는 검색 엔진, 로그 데이터 분석 또는 거대한 2 차원 조인리스 테이블 스캔이 필요한 장소에 적합 할 수 있습니다. Redis는 트리, 대기열, 링크 된 목록 등과 같은 다양한 데이터 구조에 대한 메모리 내 검색을 제공하도록 설계되었으며 실시간 리더 보드, 펍 서브 종류의 시스템을 만드는 데 적합 할 수 있습니다. 마찬가지로이 범주에는 다른 문제 설명에 적합한 다른 데이터베이스 (Cassandra 포함)가 있습니다. 이제 원래 질문으로 이동하여 하나씩 답변 해 보겠습니다.
카산드라 사용시기
Cassandra는 NoSQL 제품군의 일부이기 때문에 요구 사항 중 하나가 매우 무거운 쓰기 시스템을 갖고 있고 저장된 데이터 위에 응답 성이 뛰어난보고 시스템을 갖고 자하는 문제에 대한 솔루션을 제공합니다. 각 요청에 대해 로그 데이터가 저장되는 웹 분석의 유스 케이스를 고려하고 시간별, 브라우저 별, IP 등으로 실시간으로 적중을 계산하기 위해 분석 플랫폼을 구축하려고합니다. Cassandra가 적합한 사용 사례에 대한 자세한 내용은 이 블로그 게시물을 참조하십시오 .
Cassandra 대신 RDMS를 사용하는 경우
Cassandra는 NoSQL 데이터베이스를 기반으로하며 ACID 및 관계형 데이터 속성을 제공하지 않습니다. ACID 속성 (예 : 재무 데이터)에 대한 강력한 요구 사항이있는 경우 Cassandra는이 경우에 적합하지 않습니다. 분명히, 이에 대한 해결 방법을 만들 수 있지만 ACID 속성을 시뮬레이션하기 위해 많은 응용 프로그램 코드를 작성하게되어 시장 출시 시간이 크게 단축 될 수 있습니다. 또한 Cassandra로 이러한 종류의 시스템을 관리하는 것은 복잡하고 지루할 것입니다.
카산드라를 사용하지 않을 때
위의 설명이 의미가 있다면 대답해야한다고 생각하지 않습니다.
분산 데이터 시스템을 평가할 때는 CAP 정리를 고려해야합니다. 일관성, 가용성 및 파티션 허용 오차 중 두 가지를 선택할 수 있습니다.
Cassandra는 최종 일관성을 지원하는 사용 가능한 파티션 허용 시스템입니다. 자세한 내용은 내가 쓴이 블로그 게시물 : NoSQL Systems에 대한 Visual Guide를 참조하십시오 .
Cassandra는 특정 문제에 대한 해답입니다. 데이터가 너무 많아서 하나의 서버에 맞지 않을 때는 어떻게해야합니까? 모든 데이터를 여러 서버에 저장하고 은행 계좌를 해치지 않고 개발자를 미치게 만들지 않는 방법은 무엇입니까? Facebook은 매일 4 테라 바이트의 새로운 압축 데이터를받습니다. 이 숫자는 1 년 안에 두 번 이상 증가 할 것입니다.
이 정도의 데이터가 없거나 Enterprise Oracle / DB2 클러스터 설치 비용과 수백만 달러를 지불하고이를 설정 및 유지 관리하는 데 필요한 전문가가 있다면 SQL 데이터베이스를 사용하는 것이 좋습니다.
그러나 Facebook은 더 이상 cassandra를 사용하지 않으며 이제는 더 빠른 성능과 더 나은 제어를 위해 애플리케이션 스택에서 파티셔닝을 거의 독점적으로 MySQL을 사용합니다.
NoSQL의 일반적인 아이디어는 응용 프로그램에 가장 적합한 데이터 저장소를 사용해야한다는 것입니다. 재무 데이터 테이블이있는 경우 SQL을 사용하십시오. 관계형 스키마에 매핑하기 위해 복잡하거나 느린 쿼리가 필요한 개체가있는 경우 개체 또는 키 / 값 저장소를 사용하십시오.
물론 실제로 발생하는 거의 모든 문제는이 두 극단 사이에 있으며 해결책이 완벽하지는 않습니다. 각 상점의 기능과 하나를 다른 것보다 사용했을 때의 결과를 고려해야합니다. 이는 해결하려는 문제에 매우 특정한 것입니다.
Cassandra를 사용하고 사용하지 않을 때에 대한 답변 외에 Cassandra를 사용하기로 결정한 경우 Cassandra 자체를 사용하지 말고 많은 사촌 중 하나를 사용하는 것이 좋습니다.
위의 답변 중 일부는 Cassandra와 많은 속성을 공유하는 다양한 "NoSQL"시스템을 이미 지적했으며, 약간의 차이가 있거나 큰 차이가 있으며 특정 요구에 대해 Cassandra 자체보다 낫습니다.
또한 최근 (이 질문이 처음 요청 된 후 몇 년이 지난 후) Scylla라는 Cassandra 클론 ( https://en.wikipedia.org/wiki/Scylla_(database) 참조 )이 릴리스되었습니다. Scylla는 C ++에서 Cassandra를 오픈 소스로 다시 구현 한 것으로 원본 Java Cassandra보다 처리량이 높고 지연 시간이 현저히 낮으며 기능, API 및 파일 형식과 호환됩니다. 따라서 이미 카산드라를 고려하고 있다면 실라도 고려할 수 있습니다.
Cassandra를 배포하는 동안 누군가와 이야기하면 다대 다를 잘 처리하지 못합니다. 그들은 초기 테스트를 위해 해킹 작업을 수행하고 있습니다. 나는 카산드라 컨설턴트와이 문제에 관해 이야기했고, 만약 당신이이 문제가 있다면 그것을 추천하지 않을 것이라고 말했다.
자신에게 다음과 같은 질문을해야합니다.
이러한 질문 중 하나라도 "아마도"또는 "아니오"라고 생각되면 다른 것을 사용해야합니다. 당신이 그들 모두에 대한 답변으로 "지옥"을 가지고 있다면, 당신은 카산드라를 사용해야합니다.
한 상자에서 모든 작업을 수행 할 수 있으면 RDBMS를 사용하십시오. 아마도 대부분의 사람들보다 쉽고 아마도 누구나 함께 할 수 있습니다.
무거운 단일 쿼리 대 가질 리언 라이트 쿼리 로드는 여기에 다른 답변과 함께 고려해야 할 또 다른 포인트입니다. NoSql 스타일 DB에서 단일 쿼리를 자동으로 최적화하는 것은 본질적으로 어렵습니다. 복잡한 쿼리를 계산할 때 MongoDB를 사용하고 성능 문제가 발생했습니다. Cassandra를 사용하지 않았지만 동일한 문제가 발생할 것으로 예상합니다.
반면에 부하가 매우 작은 쿼리의 부하 일 것으로 예상되고 쉽게 확장 할 수있게하려면 대부분의 NoSql DB에서 제공하는 최종 일관성을 활용할 수 있습니다. 최종 일관성은 실제로 비 관계형 데이터 모델의 기능은 아니지만 NoSql 기반 시스템에서 구현하고 설정하는 것이 훨씬 쉽습니다.
매우 무거운 단일 쿼리의 경우 최신 RDBMS 엔진은 쿼리의 일부를 병렬 처리하는 적절한 작업을 수행하고 단일 컴퓨터에서 처리하는 CPU 및 메모리를 활용할 수 있습니다. NoSql 데이터베이스에는 데이터 구조에 대한 충분한 정보가 없어서 큰 쿼리를 지능적으로 병렬화 할 수있는 가정을 할 수 있습니다. 더 많은 서버 (또는 코어)를 쉽게 확장 할 수 있지만 쿼리가 복잡성 수준에 도달하면 기본적으로 NoSql 엔진이 지능적으로 처리하는 방법을 알고있는 부분으로 수동으로 분할해야합니다.
MongoDB에 대한 경험에서, 결국 쿼리의 복잡성으로 인해 Mongo가이를 최적화하고 여러 데이터에서 일부를 실행하기 위해 할 수있는 일은 많지 않았습니다. Mongo 는 여러 쿼리를 병렬화 하지만 단일 쿼리 를 최적화하는 데는 좋지 않습니다.
실제 사례를 읽어 봅시다.
http://planetcassandra.org/apache-cassandra-use-cases/
MySql을 선택하지 않은 이유는 db 동기화가 너무 느리기 때문입니다.
(2 구 커밋, FK, PK로 인해)
Cassandra는 Amazon Dynamo 용지를 기반으로합니다.
풍모:
안정
고 가용성
백업이 잘 수행됩니다
읽기 및 쓰기가 HBase보다 우수합니다 (Java의 BigTable 복제).
wiki http://en.wikipedia.org/wiki/Apache_Cassandra
그들의 결론 은 다음과 같습니다.
We looked at HBase, Dynamo, Mongo and Cassandra.
Cassandra was simply the best storage solution for the majority of our data.
2018 년 기준
다시 지원이 필요한 경우 ScyllaDB를 사용하여 클래식 cassandra를 교체하는 것이 좋습니다.
Postgres kv 플러그인은 cassandra보다 빠릅니다. 다중 인스턴스 확장 성이없는 방법.
카산드라가 정말로 필요한지 결정하는 데 도움이 될 수있는 중요한 측면에 중점을 둘 것입니다. 이 목록은 완전한 것이 아니라 내 마음의 가장 중요한 부분 중 일부입니다.
관계에 대한 엄격한 요구 사항이있는 경우 (데이터 집합에서) Cassandra를 첫 번째 선택으로 고려하지 마십시오.
Cassandra는 기본적으로 AP 시스템 (CAP)입니다. 그러나 조정 가능한 일관성을 지원하므로 CP도 지원하도록 구성 할 수 있습니다. AP라는 곳을 읽고 CP 시스템을 찾고 있다고해서 무시하지 마십시오. Cassandra는보다 정확하게 "조정 가능하게 일관성있는"이라고하며 이는 가용성 수준과 균형을 이루어 필요한 일관성 수준을 쉽게 결정할 수있게합니다.
규모가 크지 않거나 분산되지 않은 DB를 처리 할 수있는 경우 Cassandra를 사용하지 마십시오.
Cassandra와 같은 분산 DB를 사용하면 팀이 모든 문제를 해결할 것이라고 생각하면 더 열심히 생각하십시오. 이러한 DB를 시작하려면 많은 기본값이 제공되므로 매우 간단하지만 특정 문제를 해결하기 위해 최적화하고 마스터하려면 상당한 양의 엔지니어링 노력이 필요합니다.
Cassandra는 열 지향적이지만 동시에 각 행에는 고유 키가 있습니다. 따라서이를 색인화 된 행 지향 저장소로 생각하면 도움이 될 수 있습니다. 문서 저장소로 사용할 수도 있습니다.
Cassandra는 미리 필드를 정의하도록 강요하지 않습니다. 따라서 시작 모드에 있거나 기능이 민첩하게 진화하고 있다면 Cassandra가이를 수용합니다. 따라서 쿼리에 대해 먼저 생각한 다음 쿼리 할 데이터에 대해 생각하십시오.
Cassandra는 쓰기시 실제로 높은 처리량을 위해 최적화되었습니다. 사용 사례가 캐시와 같이 읽기가 많은 경우 Cassandra가 이상적인 선택이 아닐 수 있습니다.
합계, 최소, 최대 등의 집계 함수 및 위에서 언급 한 재무 시스템과 같은 복잡한 쿼리와 같은 집계 함수를 사용하려는 경우 관계형 데이터베이스가 nosql 데이터베이스보다 더 편리한 경우가 있습니다. 실제로 많은 인덱스를 사용하지 않으면 nosql 데이터베이스에서는 불가능합니다. nosql을 사용하는 경우 코드에서 집계 함수를 수행하거나 별도로 고유 한 columnfamily에 저장해야하지만 이는 nosql을 사용하여 얻는 모든 기능을 상당히 복잡하게하고 성능을 저하시킵니다.
SQL 의미 체계가있는 완전히 일관된 데이터베이스가 필요한 경우 Cassandra가 해결책이 아닙니다. Cassandra는 키-값 조회를 지원합니다. SQL 쿼리를 지원하지 않습니다. 카산드라의 데이터는 "결국 일관성"입니다. 데이터의 동시 조회가 일치하지 않을 수 있지만 결국 조회는 일관됩니다.
엄격한 의미론이 필요하고 SQL 쿼리에 대한 지원이 필요한 경우 MySQL, PostGres와 같은 다른 솔루션을 선택하거나 Cassandra와 Solr을 함께 사용하십시오.
Apache cassandra는 많은 상용 서버에서 대량의 구조화 된 데이터를 관리하기위한 분산 데이터베이스이며, 고 가용성 서비스를 제공하고 단일 장애 지점은 없습니다.
이 아키텍처는 순전히 가용성, 분할 허용 오차, 흥미롭게도 일관된 캡 정리를 기반으로합니다.
클러스터 랙에 데이터 볼륨을 저장하지 않는 경우에는 사용하지 마십시오. 시계열 데이터를 저장하지 않는 경우에는 사용하지 마십시오. 서버를 순찰하지 않는 경우에는 사용하지 마십시오. 강력한 일관성이 필요한 경우에는 사용하지 마십시오.