언제 Cassandra를 복용해서는 안되나요?


199

최근 카산드라 와 관련된 많은 이야기가있었습니다 .

트위터, 디그, 페이스 북 등이 모두 사용합니다.

언제 이치에 맞습니까?

  • 카산드라 사용
  • 카산드라를 사용하지 않고
  • Cassandra 대신 RDMS를 사용하십시오.

7
아마도 CW 여야합니까? 이것은 꽤 주관적인 IMO 인 NoSQL과 관계형 데이터베이스입니다.
Ed James

3
메시징 시스템에 적합한 지 알고 싶습니다. 트위터가 그것을 사용한다면 괜찮을 것이라고 생각하지만 모든 트위터에 그것을 사용할 수는 없습니까?
Luke

답변:


164

은 총알과 같은 것은 없으며 모든 것은 특정 문제를 해결하기 위해 만들어졌으며 자체 장단점이 있습니다. 어떤 문제 설명을 가지고 있으며 해당 문제에 가장 적합한 솔루션은 무엇입니까?

질문과 같은 순서로 질문에 하나씩 답변 해 드리겠습니다. 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로 이러한 종류의 시스템을 관리하는 것은 복잡하고 지루할 것입니다.

카산드라를 사용하지 않을 때

위의 설명이 의미가 있다면 대답해야한다고 생각하지 않습니다.


1
대답의 문제점은 모든 NoSQL 솔루션을 하나로 묶습니다. 자세한 내용은 dataconomy.com/sql-vs-nosql-need-know 를 참조하십시오 . NoSQL 환경에서 기본 부서는 문서, 키-값, 그래프 및 큰 테이블입니다. 문제마다 특성이 다릅니다. mongo에 적합한 솔루션은 cassandra에 적합하지 않을 수 있습니다.
Yehosef

17
이 응답이 "모든 NoSQL 솔루션을 하나로 묶는"유일한 방법은 NoSQL 범주입니다. 그 외에도 포스트는 각 NoSQL 데이터베이스가 다른 문제에 대해 "다른 솔루션을 제공한다"고 지적하는 훌륭한 일을합니다. 저자가 몽고, 카산드라 또는 다른 NoSQL 데이터베이스가 동일한 문제를 해결한다고 약간 암시조차 느끼지 못했습니다.
Nick Suwyn

NoSQL database일이 아닙니다. NoSQL현대의 비 관계형 데이터베이스에 사용되는 용어 일뿐입니다 ( wiki 참조 ).
eddyP23

2
또한 모든 NoSQL 데이터베이스가 ACID가 아닌 것은 아닙니다. 그래프 DB는 일반적으로 ACID입니다.
eddyP23

Cassandra는 경량 트랜잭션을 사용하여 행 수준의 원자 작업과 파티션 당 원자 및 격리를 지원합니다. 요구 사항이 행 수준에서 ACID를 가져야하는 경우 Cassandra를 사용할 수 없습니까? 중요한 데이터조차도?
TechEnthusiast

52

분산 데이터 시스템을 평가할 때는 CAP 정리를 고려해야합니다. 일관성, 가용성 및 파티션 허용 오차 중 두 가지를 선택할 수 있습니다.

Cassandra는 최종 일관성을 지원하는 사용 가능한 파티션 허용 시스템입니다. 자세한 내용은 내가 쓴이 블로그 게시물 : NoSQL Systems에 대한 Visual Guide를 참조하십시오 .


두 파티션이 모두 큰 파티션을 마지막으로 본 시점은 언제입니까? 내 질문보기 stackoverflow.com/questions/7969874/...
아론 워터스

5
Cassandra는 또한 쿼리 시점에 일관성 요구 사항을 지정할 수 있도록합니다. 이는 일부 사용 사례에서 유용한 절충이 될 수 있습니다.
Richard Marr

30

Cassandra는 특정 문제에 대한 해답입니다. 데이터가 너무 많아서 하나의 서버에 맞지 않을 때는 어떻게해야합니까? 모든 데이터를 여러 서버에 저장하고 은행 계좌를 해치지 않고 개발자를 미치게 만들지 않는 방법은 무엇입니까? Facebook은 매일 4 테라 바이트의 새로운 압축 데이터를받습니다. 이 숫자는 1 년 안에 두 번 이상 증가 할 것입니다.

이 정도의 데이터가 없거나 Enterprise Oracle / DB2 클러스터 설치 비용과 수백만 달러를 지불하고이를 설정 및 유지 관리하는 데 필요한 전문가가 있다면 SQL 데이터베이스를 사용하는 것이 좋습니다.

그러나 Facebook은 더 이상 cassandra를 사용하지 않으며 이제는 더 빠른 성능과 더 나은 제어를 위해 애플리케이션 스택에서 파티셔닝을 거의 독점적으로 MySQL을 사용합니다.


27

NoSQL의 일반적인 아이디어는 응용 프로그램에 가장 적합한 데이터 저장소를 사용해야한다는 것입니다. 재무 데이터 테이블이있는 경우 SQL을 사용하십시오. 관계형 스키마에 매핑하기 위해 복잡하거나 느린 쿼리가 필요한 개체가있는 경우 개체 또는 키 / 값 저장소를 사용하십시오.

물론 실제로 발생하는 거의 모든 문제는이 두 극단 사이에 있으며 해결책이 완벽하지는 않습니다. 각 상점의 기능과 하나를 다른 것보다 사용했을 때의 결과를 고려해야합니다. 이는 해결하려는 문제에 매우 특정한 것입니다.


3
스키마는 변경되지 않으며 테이블 구조에 적합하며 손실 / 일관되지 않은 데이터로 인해 실제 문제가 발생할 수 있습니다.
Tom Clarkson

4
불일치 한 데이터가 은행에 실제 문제를 일으킬 수있는 이유를 이해하지 못합니다. 시나리오 : 한 개의 은행 계좌가 있으며 한도를 100 달러 이상으로, 두 개의 은행 카드가 있습니다. 두 개의 다른 ATM에서 두 개의 카드로 동시에 돈을 인출하려고 할 때, $ 100의 2 배와 우편함에 추가 비용이 든 편지를 받게됩니다. 은행은 일관되지 않은 데이터를 사용하여 돈을 벌고 있습니다 (한도 이하인 경우 추가 요금). 하나의 큰 관계형 데이터베이스를 통해 세계의 모든 ATM을 서로 연결하는 것은 어렵습니다. 일관되지 않은 재무 데이터가 문제가 될 수있는 예를 제시 할 수 있습니까?
Paco

5
그 물건은 모두 COBOL 및 배치 처리이며 생각만큼 디자인이 안정적이지 않습니다. ATM은 모든 종류의 통합 데이터 저장소에 연결되지 않으므로 적절한 예는 아닙니다. 인터넷에있는 모든 사람이 데이터베이스에 직접 액세스 할 수 없기 때문에 SQL이 웹 앱에 적합하지 않다고 말하는 것과 같습니다. 게다가, 나는 은행에 대해 아무 말도 한 적이 없습니다. 전자 상거래 사이트에서 주문과 같은 것을 생각하면 SQL을 새롭고 신뢰할 수없는 조직으로 취급 할 필요가 없습니다.
Tom Clarkson

6
@Paco : 첫 번째 ATM은 잔액 (100 달러)을 읽으며 두 번째 ATM도 동일합니다. 두 ATM 모두 $ 100에서 $ 100를 차감하고 $ 0의 최종 잔액을 귀하의 계좌에 다시 씁니다. 결과 : 은행은 $ 100를 잃습니다.
Seun Osewa

9
@Paco : 요점은 적절한 거래 분리가 없으면 일반 은행은 계좌가 인출되었음을 알 수 없다는 것입니다. 그들은조차 알지 못할 것입니다.
Seun Osewa

14

Cassandra를 사용하고 사용하지 않을 때에 대한 답변 외에 Cassandra를 사용하기로 결정한 경우 Cassandra 자체를 사용하지 말고 많은 사촌 중 하나를 사용하는 것이 좋습니다.

위의 답변 중 일부는 Cassandra와 많은 속성을 공유하는 다양한 "NoSQL"시스템을 이미 지적했으며, 약간의 차이가 있거나 큰 차이가 있으며 특정 요구에 대해 Cassandra 자체보다 낫습니다.

또한 최근 (이 질문이 처음 요청 된 후 몇 년이 지난 후) Scylla라는 Cassandra 클론 ( https://en.wikipedia.org/wiki/Scylla_(database) 참조 )이 릴리스되었습니다. Scylla는 C ++에서 Cassandra를 오픈 소스로 다시 구현 한 것으로 원본 Java Cassandra보다 처리량이 높고 지연 시간이 현저히 낮으며 기능, API 및 파일 형식과 호환됩니다. 따라서 이미 카산드라를 고려하고 있다면 실라도 고려할 수 있습니다.


9

Cassandra를 배포하는 동안 누군가와 이야기하면 다대 다를 잘 처리하지 못합니다. 그들은 초기 테스트를 위해 해킹 작업을 수행하고 있습니다. 나는 카산드라 컨설턴트와이 문제에 관해 이야기했고, 만약 당신이이 문제가 있다면 그것을 추천하지 않을 것이라고 말했다.


4

자신에게 다음과 같은 질문을해야합니다.

  1. (볼륨, 속도) 많은 컴퓨터에서 쓰기를 처리 할 수없는 많은 정보를 작성하고 읽을 것입니다.
  2. (글로벌) 전 세계의 다른 지역에서 쓰기에 액세스 할 수 있도록 전 세계에서이 쓰기 및 읽기 기능이 필요합니까?
  3. (신뢰할 수 있음) VM, 컨테이너 또는 베어 메탈에 관계없이 어느 클라우드, 어느 국가에 관계없이이 데이터베이스를 항상 가동하고 다운시키지 않는가?
  4. (확장 성) 쉽게 확장하고 선형 적으로 확장 할 수 있으려면이 데이터베이스가 필요합니까?
  5. (일관성) 인증이 필요한 곳에서 일부 쓰기가 비동기 적으로 발생할 수있는 TUNABLE 일관성이 필요합니까?
  6. (기술) 이 기술을 배우기 위해 필요한 모든 일을 기꺼이 하시겠습니까? 어디서나 모든 사람에게 빠른 글로벌 분산 데이터베이스를 만들 수 있습니까?

이러한 질문 중 하나라도 "아마도"또는 "아니오"라고 생각되면 다른 것을 사용해야합니다. 당신이 그들 모두에 대한 답변으로 "지옥"을 가지고 있다면, 당신은 카산드라를 사용해야합니다.

한 상자에서 모든 작업을 수행 할 수 있으면 RDBMS를 사용하십시오. 아마도 대부분의 사람들보다 쉽고 아마도 누구나 함께 할 수 있습니다.


3

무거운 단일 쿼리 대 가질 리언 라이트 쿼리 로드는 여기에 다른 답변과 함께 고려해야 할 또 다른 포인트입니다. NoSql 스타일 DB에서 단일 쿼리를 자동으로 최적화하는 것은 본질적으로 어렵습니다. 복잡한 쿼리를 계산할 때 MongoDB를 사용하고 성능 문제가 발생했습니다. Cassandra를 사용하지 않았지만 동일한 문제가 발생할 것으로 예상합니다.

반면에 부하가 매우 작은 쿼리의 부하 일 것으로 예상되고 쉽게 확장 할 수있게하려면 대부분의 NoSql DB에서 제공하는 최종 일관성을 활용할 수 있습니다. 최종 일관성은 실제로 비 관계형 데이터 모델의 기능은 아니지만 NoSql 기반 시스템에서 구현하고 설정하는 것이 훨씬 쉽습니다.

매우 무거운 단일 쿼리의 경우 최신 RDBMS 엔진은 쿼리의 일부를 병렬 처리하는 적절한 작업을 수행하고 단일 컴퓨터에서 처리하는 CPU 및 메모리를 활용할 수 있습니다. NoSql 데이터베이스에는 데이터 구조에 대한 충분한 정보가 없어서 큰 쿼리를 지능적으로 병렬화 할 수있는 가정을 할 수 있습니다. 더 많은 서버 (또는 코어)를 쉽게 확장 할 수 있지만 쿼리가 복잡성 수준에 도달하면 기본적으로 NoSql 엔진이 지능적으로 처리하는 방법을 알고있는 부분으로 수동으로 분할해야합니다.

MongoDB에 대한 경험에서, 결국 쿼리의 복잡성으로 인해 Mongo가이를 최적화하고 여러 데이터에서 일부를 실행하기 위해 할 수있는 일은 많지 않았습니다. Mongo여러 쿼리를 병렬화 하지만 단일 쿼리 를 최적화하는 데는 좋지 않습니다.


3

실제 사례를 읽어 봅시다.

http://planetcassandra.org/apache-cassandra-use-cases/

이 기사에서 : http://planetcassandra.org/blog/post/agentis-energy-stores-over-15-billion-records-of-time-series-usage-data-in-apache-cassandra

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보다 빠릅니다. 다중 인스턴스 확장 성이없는 방법.


하나의 데이터베이스 기술 만 사용하지 않아도됩니다. 실제로 콤보를 가지고 특정 문제에 적합한 것을 사용할 수 있습니다.
Pepito Fernandez

3

카산드라가 정말로 필요한지 결정하는 데 도움이 될 수있는 중요한 측면에 중점을 둘 것입니다. 이 목록은 완전한 것이 아니라 내 마음의 가장 중요한 부분 중 일부입니다.

  • 관계에 대한 엄격한 요구 사항이있는 경우 (데이터 집합에서) Cassandra를 첫 번째 선택으로 고려하지 마십시오.

  • Cassandra는 기본적으로 AP 시스템 (CAP)입니다. 그러나 조정 가능한 일관성을 지원하므로 CP도 지원하도록 구성 할 수 있습니다. AP라는 곳을 읽고 CP 시스템을 찾고 있다고해서 무시하지 마십시오. Cassandra는보다 정확하게 "조정 가능하게 일관성있는"이라고하며 이는 가용성 수준과 균형을 이루어 필요한 일관성 수준을 쉽게 결정할 수있게합니다.

  • 규모가 크지 않거나 분산되지 않은 DB를 처리 할 수있는 경우 Cassandra를 사용하지 마십시오.

  • Cassandra와 같은 분산 DB를 사용하면 팀이 모든 문제를 해결할 것이라고 생각하면 더 열심히 생각하십시오. 이러한 DB를 시작하려면 많은 기본값이 제공되므로 매우 간단하지만 특정 문제를 해결하기 위해 최적화하고 마스터하려면 상당한 양의 엔지니어링 노력이 필요합니다.

  • Cassandra는 열 지향적이지만 동시에 각 행에는 고유 키가 있습니다. 따라서이를 색인화 된 행 지향 저장소로 생각하면 도움이 될 수 있습니다. 문서 저장소로 사용할 수도 있습니다.

  • Cassandra는 미리 필드를 정의하도록 강요하지 않습니다. 따라서 시작 모드에 있거나 기능이 민첩하게 진화하고 있다면 Cassandra가이를 수용합니다. 따라서 쿼리에 대해 먼저 생각한 다음 쿼리 할 데이터에 대해 생각하십시오.

  • Cassandra는 쓰기시 실제로 높은 처리량을 위해 최적화되었습니다. 사용 사례가 캐시와 같이 읽기가 많은 경우 Cassandra가 이상적인 선택이 아닐 수 있습니다.


2

합계, 최소, 최대 등의 집계 함수 및 위에서 언급 한 재무 시스템과 같은 복잡한 쿼리와 같은 집계 함수를 사용하려는 경우 관계형 데이터베이스가 nosql 데이터베이스보다 더 편리한 경우가 있습니다. 실제로 많은 인덱스를 사용하지 않으면 nosql 데이터베이스에서는 불가능합니다. nosql을 사용하는 경우 코드에서 집계 함수를 수행하거나 별도로 고유 한 columnfamily에 저장해야하지만 이는 nosql을 사용하여 얻는 모든 기능을 상당히 복잡하게하고 성능을 저하시킵니다.


CouchdB은 wiki.apache.org/couchdb/…와 같은 집계 함수 계산을 매우 쉽게 해줍니다 . 기술적으로 이것은 "코드 상"이지만 Cassandra와 마찬가지로 "복잡한"것도 아닙니다.
user359996

2
실제로 코드로 집계를 작성하는 데 하루가 걸릴 수 있다는 데 동의하지만 데이터베이스를 거의 0 주기로 사용하는 백엔드 서버에서 실행하도록 작성할 수 있습니다. SQL 데이터베이스를 사용하면 5 분 정도 소요될 수있는 한 줄로 결과를 얻을 수 있습니다. 그러나 실행할 때마다 전체 데이터베이스 속도가 느려집니다. 따라서 두 가지 장단점이 있습니다. 예를 들어, 은행은 한밤중에 약 10 분에서 15 분 동안 모든 웹 사이트 액세스를 종료합니다. 그들은 확실히 확실히 COBOL을 사용하고 있지만 매우 유사한 문제입니다.
Alexis Wilke

1

SQL 의미 체계가있는 완전히 일관된 데이터베이스가 필요한 경우 Cassandra가 해결책이 아닙니다. Cassandra는 키-값 조회를 지원합니다. SQL 쿼리를 지원하지 않습니다. 카산드라의 데이터는 "결국 일관성"입니다. 데이터의 동시 조회가 일치하지 않을 수 있지만 결국 조회는 일관됩니다.

엄격한 의미론이 필요하고 SQL 쿼리에 대한 지원이 필요한 경우 MySQL, PostGres와 같은 다른 솔루션을 선택하거나 Cassandra와 Solr을 함께 사용하십시오.


1
CQL (Cassandra Query Language) 은 SQL 과 매우 유사 합니다. 실제로 CQL은 SQL과 유사한 인터페이스를 찾는 사람들에게 다른 NoSQL 옵션보다 Cassandra의 이점이라고 말합니다.
arussell84

1
카산드라는 기술적으로 일관성이 없습니다. Cassandra를 사용하면 가용성에 대한 일관성을 유지할 수 있습니다. 카산드라는 기본적으로 CAP 정리의 균형을 맞추고 있습니다. 결국 일관된 쓰기를 수행 한 다음 일관되게 읽기를 할 수 있으며, 그 반대로 또는 일관되게 읽을 수 있으며, 이는 모두 읽기 / 쓰기 수준과 결합 된 복제 요소에 따라 다릅니다. 나는 이런 이유로 따옴표로 "결국 일관성을 유지했다"라는 대답을 받았지만, 명확성이 순서대로있는 것 같습니다.
tsturzl

1

다음과 같은 경우 Cassandra가 좋습니다.

  1. DB의 ACID 속성이 필요하지 않습니다.

  2. DB에 많은 양의 쓰기가있을 것입니다.

  3. Big Data, Hadoop, Hive 및 Spark와 통합해야합니다.

  4. 실시간 데이터 분석 및 보고서 생성이 필요합니다.

  5. 인상적인 내결함성 메커니즘이 필요합니다.

  6. 동종 시스템이 필요합니다.

  7. 튜닝을 위해 많은 사용자 정의가 필요합니다.


0

Mongodb에는 매우 강력한 집계 함수와 표현 집계 집계 프레임 워크가 있습니다. 여기에는 개발자가 관계형 데이터베이스 세계에서 사용하는 데 익숙한 많은 기능이 있습니다. 예를 들어 문서 데이터 / 스토리지 구조는 Cassandra보다 더 복잡한 데이터 모델을 허용합니다.

이 모든 것은 물론 트레이드 오프와 함께 제공됩니다. 따라서 데이터베이스 (NoSQL, NewSQL 또는 RDBMS)를 선택할 때 해결하려는 문제와 확장 성 요구를 살펴보십시오. 아무도 데이터베이스를 모두 수행하지 않습니다.


0

DataStax에 따르면 Cassandra는 필요한 경우 최상의 사용 사례가 아닙니다.

1- 고급 하드웨어 장치. 롤백이없는 2 ACID (은행 거래)


0
  • 테이블 전체에서 완전한 트랜잭션 관리를 지원하지 않습니다.
  • 보조 인덱스는 지원되지 않습니다.
  • 보조 인덱스에 대해서는 Elastic search / Solr을 사용해야하며 사용자 지정 동기화 구성 요소를 작성해야합니다.
  • ACID 호환 시스템이 아닙니다.
  • 쿼리 지원이 제한됩니다.

0

Apache cassandra는 많은 상용 서버에서 대량의 구조화 된 데이터를 관리하기위한 분산 데이터베이스이며, 고 가용성 서비스를 제공하고 단일 장애 지점은 없습니다.

이 아키텍처는 순전히 가용성, 분할 허용 오차, 흥미롭게도 일관된 캡 정리를 기반으로합니다.

클러스터 랙에 데이터 볼륨을 저장하지 않는 경우에는 사용하지 마십시오. 시계열 데이터를 저장하지 않는 경우에는 사용하지 마십시오. 서버를 순찰하지 않는 경우에는 사용하지 마십시오. 강력한 일관성이 필요한 경우에는 사용하지 마십시오.


강력한 일관성 보장, 서버는 항상 쓰기를 수행하며 모든 읽기는 최신을 제공합니다.
Remario
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.