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

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

문 닫았습니다.이 질문은의견에 입각한현재 답변을 받지 않고 있습니다.

---

이 질문을 개선하고 싶으십니까?이 게시물을 편집하여 사실과 인용으로 답변할 수 있도록 질문을 업데이트합니다.

2년 전에 문을 닫았습니다.

이 질문을 개선합니다.

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

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

다음을 수행하는 것이 합리적인 경우는 언제입니까?

• 카산드라를 사용하고,
• 카산드라를 사용하지 않습니다.
• 카산드라 대신 RDMS를 사용합니다.

은탄만 한 것이 없고, 모든 것이 특정한 문제를 해결하기 위해 만들어졌으며 나름의 장단점이 있습니다.당신이 어떤 문제 진술을 가지고 있는지, 그리고 그 문제에 가장 적합한 해결책이 무엇인지는 당신에게 달려 있습니다.

질문하신 순서대로 차례대로 답변 드리도록 하겠습니다.카산드라는 NoSQL 데이터베이스 제품군을 기반으로 하므로 질문에 답하기 전에 NoSQL 데이터베이스를 사용하는 이유를 이해하는 것이 중요합니다.

NoSQL을 사용하는 이유

RDBMS의 경우 MySQL, Oracle, MS SQL, Postgre와 같은 모든 데이터베이스를 선택하기가 매우 쉽습니다.이 범주의 SQL은 ACID 속성을 지향하는 거의 동일한 종류의 솔루션을 제공합니다.NoSQL의 경우, 모든 NoSQL 데이터베이스가 서로 다른 솔루션을 제공하고 있으며 애플리케이션/시스템 요구사항에 가장 적합한 솔루션을 파악해야 하기 때문에 결정이 어려워집니다.예를 들어, MongoDB는 스키마가 필요 없는 문서 저장소를 필요로 하는 사용 사례에 적합합니다.HBase는 검색 엔진, 로그 데이터 분석, 또는 거대한 2차원 조인 없는 테이블 스캔이 필요한 모든 장소에 적합할 수 있습니다.Redis는 트리, 큐, 링크된 목록 등 다양한 데이터 구조에 대한 In-Memory 검색을 제공하도록 설계되었으며 실시간 리더보드, Pub-sub 종류의 시스템을 만드는 데 적합할 수 있습니다.마찬가지로 이 범주에는 다른 문제에 적합한 다른 데이터베이스(카산드라 포함)가 있습니다.자, 그럼 처음 질문으로 넘어가면서 하나씩 답을 해보도록 하겠습니다.

카산드라 사용 시기

NoSQL 제품군의 일원인 Cassandra는 매우 무거운 쓰기 시스템이 요구사항 중 하나이며 저장된 데이터 위에 응답성이 뛰어난 보고 시스템이 필요한 문제에 대한 솔루션을 제공합니다.각 요청에 대해 로그 데이터가 저장되고, 이를 중심으로 분석 플랫폼을 구축하여 시간당 히트 수, 브라우저별, IP별 등을 실시간으로 집계하는 웹 분석의 활용 사례를 생각해 보십시오.이 블로그 게시물을 참조하면 카산드라가 적합한 사용 사례에 대해 자세히 알 수 있습니다.

카산드라 대신 RDMS를 사용하는 경우

카산드라는 NoSQL 데이터베이스를 기반으로 하며 ACID 및 관계형 데이터 속성을 제공하지 않습니다.ACID 특성에 대한 강력한 요구 사항(예: 재무 데이터)이 있는 경우, 카산드라는 이 경우 적합하지 않습니다.물론 이에 대한 해결책을 만들 수는 있지만 ACID 속성을 시뮬레이션하기 위해 많은 응용 프로그램 코드를 작성하게 되고 출시 시간에 맞춰 손실을 입게 됩니다.또한 카산드라로 그런 시스템을 관리하는 것은 복잡하고 지루할 것입니다.

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

위의 설명이 일리가 있다면 답변할 필요가 없다고 생각합니다.

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

카산드라는 궁극적인 일관성을 지원하는 사용 가능한 파티션 허용 시스템입니다.자세한 내용은 내가 작성한 블로그 게시물을 참조하십시오.NoSQL 시스템에 대한 시각 가이드.

카산드라는 특정한 문제에 대한 답입니다.데이터가 너무 많아서 한 서버에 맞지 않을 때는 어떻게 해야 합니까?많은 서버에 모든 데이터를 저장하고 은행 계좌를 파산시키지 않고 개발자들을 미치게 하지 않는 방법은 무엇입니까?페이스북은 매일 4테라바이트의 새로운 압축 데이터를 받습니다.그리고 이 숫자는 1년 안에 두 배 이상 증가할 가능성이 높습니다.

이 정도의 데이터가 없거나 Enterprise Oracle/DB2 클러스터 설치에 필요한 수백만 명의 비용과 이를 설정하고 유지 관리하는 데 필요한 전문가가 있다면 SQL 데이터베이스를 사용해도 무방합니다.

그러나 Facebook은 더 이상 카산드라를 사용하지 않고 이제 MySQL을 거의 독점적으로 애플리케이션 스택에서 파티션을 위로 이동시켜 더 빠른 성능과 더 나은 제어를 제공합니다.

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

물론 당신이 마주치는 현실 세계의 문제는 그 두 극단 사이 어딘가에 있으며, 어느 해결책도 완벽하지 않을 것입니다.각 스토어의 기능과 하나를 다른 스토어에 사용할 경우 발생하는 결과를 고려해야 합니다. 이는 해결하려는 문제에 매우 구체적일 것입니다.

카산드라를 사용할 때와 사용하지 않을 때에 대한 위의 답변 외에, 만약 여러분이 카산드라를 사용하기로 결정했다면, 여러분은 카산드라 자체를 사용하는 것이 아니라, 그곳의 많은 사촌들 중 하나를 고려해 볼 수 있을 것입니다.

위의 몇몇 답변들은 이미 카산드라와 많은 속성을 공유하고, 약간의 작은 또는 큰 차이점이 있는 다양한 "NoSQL" 시스템을 가리키고 있으며, 특정한 요구에 대해서는 카산드라 자체보다 더 나을 수 있습니다.

또한 최근(이 질문이 처음 제기된 지 several 년 후) 실라(https://en.wikipedia.org/wiki/Scylla_(database)) 참조)라는 카산드라 복제품이 출시되었습니다.실라는 C++의 카산드라를 오픈 소스로 재구현한 것으로, 원래의 자바 카산드라보다 처리량이 훨씬 높고 대기 시간이 짧다고 주장합니다.그러니 이미 카산드라를 고려하고 있다면 실라도 고려해 보는 게 좋을 겁니다

카산드라가 정말 필요한지 결정하는 데 도움이 되는 몇 가지 중요한 측면에 초점을 맞추겠습니다.이 리스트는 완전한 것이 아니라, 단지 내가 생각하고 있는 요점들 중 일부일 뿐입니다.

• (데이터 세트 전체에서) 관계에 대한 엄격한 요구 사항이 있는 경우 카산드라를 첫 번째 선택으로 간주하지 마십시오.

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

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

• 카산드라와 같은 분산 DB를 사용하면 모든 문제가 해결될 것이라고 생각하는 팀이라면 더 열심히 생각해 보세요.이러한 DB는 기본값이 많기 때문에 매우 간단하지만 특정 문제를 해결하기 위해 DB를 최적화하고 마스터링하는 데는 상당한 엔지니어링 작업이 필요합니다.

• 카산드라는 열 방향이지만 동시에 각 행에는 고유한 키가 있습니다.따라서 색인화된 행 중심의 상점으로 생각하는 것이 도움이 될 것입니다.문서 보관소로도 사용할 수 있습니다.

• 카산드라가 필드를 미리 정의하도록 강요하지는 않습니다.따라서, 만약 여러분이 시작 모드에 있거나 여러분의 특징이 진화하고 있다면 (민첩하게) - 카산드라는 그것을 받아들입니다.따라서 먼저 질의에 대해 생각하고 이에 응답할 데이터에 대해 생각하는 것이 좋습니다.

• 카산드라는 쓰기 작업 시 매우 높은 처리량에 최적화되어 있습니다.캐시와 같이 읽기 작업이 많은 경우 카산드라는 최적의 선택이 아닐 수도 있습니다.

맞아요. 많은 양의 데이터가 있고, 수많은 쿼리가 있지만 매우 적은 다양한 쿼리가 있을 때 카산드라를 사용하는 것이 합리적입니다.카산드라는 기본적으로 파티셔닝 및 복제 작업을 수행합니다.모든 쿼리가 동일한 파티션 키를 기반으로 한다면 카산드라가 최선입니다.파티션 키가 아닌 속성에 대한 쿼리를 받으면 카산드라는 새 파티션 키로 전체 데이터를 복제할 수 있습니다.이제 두 개의 서로 다른 파티션 키를 가진 동일한 데이터의 복제본이 두 개 있습니다.

그럼 다음 질문을 하게 되네요.카산드라를 사용하지 않을 때.앞서 언급했듯이 카산드라는 모든 새로운 분할 키에 대해 전체 데이터베이스를 복제하여 확장합니다.하지만 계속해서 새로운 복사본을 만들 수는 없습니다.따라서 쿼리의 다양성이 높을 때, 즉 각 쿼리마다 where 절에 다른 열이 있을 때 카산드라는 좋은 옵션이 아닙니다.

이제 세 번째 질문.RDBMS를 사용하는 핵심은 ACID 속성을 원하는 경우입니다.만약 당신이 결제 서비스와 같은 것을 구축하고 있고 각각의 거래가 분리되기를 원한다면, 각각의 거래는 완료되거나 아예 일어나지 않을 것이고, 시스템 장애에도 불구하고 지속적으로 변경될 것이며, 거래가 완료되기 전과 완료된 후에 은행 계좌에 걸쳐 돈이 일정하게 유지될 것입니다.RDBMS가 이를 달성하는 데 도움이 되는 유일한 옵션입니다.

이 글에서는 특히 Cassandra를 사용할 때(다른 NoSQL 옵션과 달리) -> 최상의 데이터베이스 선택이라는 질문의 전체적인 내용을 설명합니다.한번 확인해보세요.

편집: Proximab의 코멘트에 있는 질문에 답하자면, 은행 시스템을 생각할 때 우리는 즉시 "ACID가 가장 좋은 솔루션"이라고 생각합니다.그러나 은행 시스템조차도 계좌 소유자의 개인 정보, 계좌 내역, 신용 카드 내역, 신용 기록 등과 같은 거래 관련 데이터를 처리하지 못할 수 있는 여러 하위 시스템으로 구성되어 있습니다.

이 모든 정보는 어떤 데이터베이스나 다른 데이터베이스에 저장되어야 합니다.이제 계좌 잔고와 같은 계좌 관련 정보를 저장한다면, 그것은 항상 일관성을 유지해야 하는 것입니다.예를 들어, A 계좌에서 B 계좌로 돈을 보내려고 하면, A 계좌에서 사라진 돈이 B 계좌에 바로 나타나야 하고, 두 계좌에 동시에 존재할 수는 없습니다.이 시스템은 어느 지점에서도 일치할 수 없습니다.여기서 ACID가 가장 중요합니다.

반면, 신용 카드 내역이나 신용 기록을 저장하고 있다면, 이는 잘못된 손에 들어가지 않아야 하며, 인증된 사용자에게만 접근을 허용하는 것이 필요합니다.나는 카산드라가 지지한다고 믿습니다.즉, 신용 기록과 신용 카드 거래와 같은 데이터는 계속해서 증가하는 데이터라고 생각합니다.또한 이 데이터에 대해 쿼리할 수 있는 수가 매우 제한적입니다.이 두 가지 조건이 카산드라를 완벽한 해결책으로 만듭니다.

카산드라를 배치하는 도중에 누군가와 이야기를 나누는 것은 다대다를 잘 다루지 못합니다.그들은 초기 테스트를 하기 위해 해킹 작업을 하고 있습니다.카산드라 컨설턴트와 이 문제에 대해 이야기를 나눴는데 이 문제가 해결되면 추천하지 않겠다고 합니다.

다음과 같은 질문을 스스로에게 해야 합니다.

1. (볼륨, 속도) 컴퓨터가 쓸 수 없을 정도로 많은 정보를 쓰고 읽을 것입니까?
2. (글로벌) 세계 한 지역의 글을 다른 지역에서도 쓸 수 있도록 전 세계적으로 이런 글을 읽고 읽을 수 있는 능력이 필요하겠습니까?
3. (신뢰도)클라우드, 어느 국가, VM, Container, Bare metal 등에 상관없이 항상 데이터베이스가 가동되고 실행되어야 합니까?
4. (확장성)이러한 데이터베이스를 손쉽게 확장하고 선형적으로 확장할 수 있어야 합니까?
5. (일관성) 일부 쓰기는 비동기적으로 수행되고 다른 쓰기는 인증을 받아야 하는 경우에 조정 가능한 일관성이 필요합니까?
6. (Skill) 이 기술을 배우는 데 필요한 모든 것과 모든 사람이 어디서나 빠르게 사용할 수 있는 글로벌 분산 데이터베이스를 구축하는 데 필요한 데이터 모델링을 수행할 의향이 있습니까?

이 질문들 중 "아마도" 또는 "아니오"라고 생각한 것이 있다면, 다른 것을 사용해야 합니다.만약 여러분이 그 모든 것에 대한 답으로 "지옥 예"를 가지고 있다면, 카산드라를 사용해야 합니다.

한 박스에서 모든 작업을 수행할 수 있을 때 RDBMS를 사용합니다.대부분의 사람들보다 더 쉽고 누구나 작업할 수 있을 것입니다.

여기서 다른 답변 외에, 무거운 단일 질의 대 1,000만 개의 가벼운 질의 부하도 고려해야 할 또 다른 사항입니다.NoSql 스타일 DB에서 단일 쿼리를 자동으로 최적화하는 것은 본질적으로 더 어렵습니다.저는 몽고DB를 사용해 본 적이 있는데 복잡한 쿼리를 계산하려고 할 때 성능 문제가 발생했습니다.카산드라를 사용해 본 적은 없지만 같은 문제가 있을 것으로 예상됩니다.

한편, 부하가 매우 많은 소규모 쿼리의 부하일 것으로 예상되고 쉽게 확장할 수 있는 경우 대부분의 NoSql DB에서 제공하는 궁극적인 일관성을 활용할 수 있습니다.궁극적인 일관성은 관계형이 아닌 데이터 모델의 기능이 아니라 NoSql 기반 시스템에서 구현하고 설정하는 것이 훨씬 쉽다는 점에 유의하십시오.

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

제가 MongoDB를 사용한 경험으로는 결국 쿼리가 복잡하기 때문에 Mongo가 쿼리를 최적화하고 여러 데이터에서 일부를 실행할 수 있는 방법이 많지 않았습니다.몽고는 여러 쿼리를 병렬화하지만 하나의 쿼리를 최적화하는 데는 그다지 능숙하지 않습니다.

몇 가지 실제 사례를 읽어 보겠습니다.

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로 인해)

---

카산드라는 아마존 다이너모 종이를 기반으로 합니다.

특징:

안정성.

고가용성(HA)

백업 성능이 우수

읽기 및 쓰기가 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년 현재.

지원이 필요하다면, 고전적인 카산드라를 대체하기 위해 실라DB를 사용하는 것을 추천합니다.

Postgres kv 플러그인도 카산드라보다 빠릅니다.그러나 멀티 인스턴스 확장성은 없습니다.

선택을 더 쉽게 하는 또 다른 상황은 합, 최소, 최대와 같은 집합 함수를 사용하고 싶을 때입니다.위에서 언급한 금융 시스템에서와 같이 관계형 데이터베이스가 nosql 데이터베이스보다 더 편리할 수 있습니다. 둘 다 실제로 많은 반전 인덱스를 사용하지 않는 한 nosql 데이터베이스에서 가능하지 않기 때문입니다.nosql을 사용할 경우 코드로 집계 함수를 수행하거나 자체 열 패밀리에 별도로 저장해야 하지만 이로 인해 nosql을 사용함으로써 얻을 수 있는 성능이 저하됩니다.

다음과 같은 경우 카산드라를 선택하는 것이 좋습니다.

1. DB에서 ACID 속성을 요구하지 않습니다.

2. DB에는 방대하고 방대한 양의 쓰기가 있을 것입니다.

3. 빅 데이터, 하둡, 하이브 및 스파크와 통합해야 합니다.

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

5. 내결함성이 뛰어난 메커니즘이 필요합니다.

6. 동질적인 시스템의 요구사항이 있습니다.

7. 튜닝을 위해서는 많은 커스터마이징이 필요합니다.

SQL 시맨틱스가 포함된 완전히 일관된 데이터베이스가 필요한 경우에는 카산드라가 해결책이 아닙니다.카산드라는 키 값 조회를 지원합니다.SQL 쿼리를 지원하지 않습니다.카산드라의 데이터는 "결국 일관성"이 있습니다.동시 데이터 조회는 일관성이 없을 수 있지만 결국에는 일관성이 있습니다.

엄격한 의미론이 필요하고 SQL 쿼리에 대한 지원이 필요한 경우 MySQL, PostGres와 같은 다른 솔루션을 선택하거나 Cassandra와 Solr를 결합합니다.

Apache cassandra는 다양한 상용 서버에 걸쳐 대량의 구조화된 데이터를 관리하는 동시에 가용성이 높고 단일 장애 지점이 없는 분산 데이터베이스입니다.

아키텍처는 가용성과 파티션 공차라는 캡 정리에 순수하게 기반을 두고 있으며 흥미롭게도 궁극적으로는 일관성이 있습니다.

사용 안 함, 클러스터 랙 전체에 데이터 볼륨을 저장하지 않는 경우 사용 안 함, 시계열 데이터를 저장하지 않는 경우 사용 안 함, 서버 패치를 적용하지 않는 경우 사용 안 함, 강력한 일관성이 필요한 경우 사용 안 함.

Mongodb는 매우 강력한 집합 기능과 표현적 집합 프레임워크를 가지고 있습니다.이것은 관계형 데이터베이스 세계에서 개발자들이 사용하는 데 익숙한 많은 기능을 가지고 있습니다.예를 들어 문서 데이터/저장 구조를 사용하면 카산드라보다 더 복잡한 데이터 모델을 사용할 수 있습니다.

물론 이 모든 것들은 절충안을 동반합니다.따라서 데이터베이스(NoSQL, NewSQL 또는 RDBMS)를 선택할 때 어떤 문제를 해결하려고 하는지 그리고 확장성 요구사항을 살펴봅니다.데이터베이스에서 모든 것을 수행하는 사람은 없습니다.

DataStax에 따르면 Cassandra는 다음과 같은 필요성이 있을 때 최적의 사용 사례가 아닙니다.

1- 고급 하드웨어 장치. 2- ACID를 준수하며 롤백(은행 거래) 없음

• 테이블 전체에 걸친 완벽한 트랜잭션 관리를 지원하지 않습니다.
• 보조 색인이 지원되지 않습니다.
• Elastic search / Solr for Secondary index에 의존해야 하며, Custom sync component를 작성해야 합니다.
• ACID를 준수하지 않는 시스템.
• 쿼리 지원이 제한되어 있습니다.

언급URL : https://stackoverflow.com/questions/2634955/when-not-to-use-cassandra