database 몽고 - 카산드라를 사용하지 않을 때?




vs db (14)

최근 Cassandra 와 관련된 이야기가 많이있었습니다.

트위터, 디그, 페이스 북 등 모든 사람들이 그것을 사용합니다.

언제 그것이 의미가 있습니까 :

  • 카산드라 (Cassandra)
  • 카산드라를 사용하지 마십시오.
  • Cassandra 대신 RDMS를 사용하십시오.

Answers

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

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


  • 테이블 전체에서 완벽한 트랜잭션 관리를 지원하지 않습니다.
  • 보조 색인은 지원되지 않습니다.
  • 보조 인덱스 용 Elastic search / Solr에 의존해야하며 사용자 정의 동기화 구성 요소를 작성해야합니다.
  • ACID 준수 시스템이 아닙니다.
  • 쿼리 지원은 제한적입니다.

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

archichecture는 순전히 cap theorem에 기반을두고 있습니다. cap theorem은 유용성과 파티션 공차이며 흥미롭게도 결국 일관되게 발생합니다.

사용하지 마세요, 클러스터의 랙에 데이터 볼륨을 저장하지 않는다면 사용하지 마세요. 시계열 데이터를 저장하지 않으면 사용하지 마십시오. 서버를 패터닝하지 않으면 사용하지 마십시오. 강력한 일관성이 필요한 경우에는 사용하지 마십시오.


NoSQL의 일반적인 개념은 애플리케이션에 가장 적합한 데이터 저장소를 사용해야한다는 것입니다. 재무 데이터 테이블이 있으면 SQL을 사용하십시오. 관계형 스키마에 매핑하기 위해 복잡하거나 느린 쿼리가 필요한 객체가있는 경우 객체 또는 키 / 값 저장소를 사용하십시오.

물론 실제로 발생하는 실제 문제는 그 두 극단 사이의 어딘가에 있지 않으며 어느 솔루션도 완벽하지 않습니다. 각 상점의 기능과 다른 상점의 사용 결과를 고려해야하며 이는 해결하려는 문제점에 매우 중요합니다.


@Paco 거품을 터뜨리는 것은 유감이지만 특히 재무 데이터의 경우 트랜잭션 일관성이 매우 중요합니다. 카산드라 (Cassandra)와 같은 데이터베이스에서 강조된 것처럼, 실패한 스크립트는 부작용을 남길 수 있습니다. 부작용은 업데이트 된 테이블과 그렇지 않은 테이블을 포함 할 수 있습니다. 한 예 : £ 100은 사용자 1의 계정에서 사용자 2의 계정으로 이동합니다. 트랜잭션은 각 계정에 대해 기록되어 하나에서 제거되고 다른 계정에 추가되었음을 표시합니다. 물론 그것은 당신의 디자인에 달려 있습니다. 다른 시나리오에서는 은행에 지불합니다. 한 계정에서 자금을 제거하고 다른 계정에 추가해야합니다. 일관성이 부족하면 돈이 시스템에서 누락되거나 중복 계산 될 가능성이 있습니다. 어느 쪽이든, 은행은 문제가 있음을 발견합니다.

트랜잭션 일관성이 비즈니스에 결정적인 경우가 많이 있습니다. 앱이 안전하고 효과적인 방식으로 처리되거나 데이터베이스가 완전히 처리해야하며 후자는 '안전한'옵션입니다.

캐서 앤드라를 통한 조인 지원 부족으로 다른 적절한 앱을 함께 사용하지 않는 한 그 사용법이 제한됩니다. 그 메모에서 트리거 기능, 외래 키 등이 부족합니다. 궁극적으로 당신이 필요로하는 것까지 모두 내려갑니다. 예를 들어 검색 공급자이고 거대한 고객 기반을 보유하고 있다면 Cassandra가 가장 적합 할 것입니다. OLTP와 일부보고 사례 또는 작은로드 볼륨의 경우 요구 사항에 대한 완전한 불일치 일 수 있습니다.


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

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


DataStax에 따르면, 카산드라는 필요가있을 때 최고의 사용 사례가 아닙니다.

1- 하이 엔드 하드웨어 장치. 2- 롤백 기능이없는 ACID 호환 (은행 거래)


은색 탄환처럼 아무것도 없습니다. 모든 것이 특정 문제를 해결하기 위해 만들어지며, 자신의 장단점이 있습니다. 문제에 대한 진술과 그 문제에 가장 적합한 해결 방법은 무엇입니까?

귀하가 질문 한 순서대로 질문에 하나씩 대답하려고 노력할 것입니다. Cassandra는 NoSQL 데이터베이스 계열을 기반으로하므로 질문에 대답하기 전에 NoSQL 데이터베이스를 사용해야하는 이유를 이해하는 것이 중요합니다.

NoSQL을 사용해야하는 이유

RDBMS의 경우,이 범주의 MySQL, Oracle, MS SQL, PostgreSQL과 같은 모든 데이터베이스가 ACID 속성을 지향하는 거의 동일한 종류의 솔루션을 제공하므로 선택하기가 매우 쉽습니다. NoSQL은 모든 NoSQL 데이터베이스가 서로 다른 솔루션을 제공하고 어느 것이 당신의 app / system 요구 사항에 가장 적합한지를 이해해야하기 때문에 결정이 어려워집니다. 예를 들어, MongoDB는 시스템에서 스키마가없는 문서 저장소가 필요한 사용 사례에 적합합니다. HBase는 검색 엔진, 로그 데이터 분석 또는 거대하고 2 차원적인 조인리스 테이블 검색이 필요한 장소에 적합합니다. Redis는 나무, 대기열, 연결된 목록 등 다양한 종류의 데이터 구조에 대한 메모리 내 검색을 제공하기 위해 제작되었으며 실시간 순위표, pub-sub 종류의 시스템을 만드는 데 적합합니다. 마찬가지로이 카테고리에 다른 데이터베이스 (카산드라 포함)가 있으며 다른 문제 진술에 적합합니다. 이제 원래의 질문으로 이동하고 하나씩 대답하십시오.

카산드라를 사용하는 경우

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

Cassandra 대신 RDMS를 사용해야하는 경우

Cassandra는 NoSQL 데이터베이스를 기반으로하며 ACID 및 관계형 데이터 속성을 제공하지 않습니다. ACID 속성 (예 : 재무 데이터)에 대한 강한 요구 사항이있는 경우 Cassandra는이 경우 적합하지 않습니다. 분명히 해결 방법을 찾을 수는 있지만 ACID 속성을 시뮬레이트하기 위해 많은 응용 프로그램 코드를 작성하게 될 것이므로 시장 출시 시간을 놓치게 될 것입니다. 또한 카산드라와 같은 종류의 시스템을 관리하는 것은 복잡하고 지루한 작업입니다.

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

위의 설명이 의미가있는 경우 응답 할 필요가 없다고 생각합니다.


Mongodb은 매우 강력한 집계 함수와 풍부한 집계 프레임 워크를 가지고 있습니다. 개발자는 관계형 데이터베이스 세계에서 익숙한 많은 기능을 제공합니다. 문서 데이터 / 저장소 구조는 예를 들어 Cassandra보다 복잡한 데이터 모델을 허용합니다.

물론이 모든 것은 절충점이됩니다. 따라서 데이터베이스 (NoSQL, NewSQL 또는 RDBMS)를 선택할 때 해결하려는 문제와 확장 성 요구 사항을 살펴보십시오. 어느 데이터베이스도이 모든 것을 수행하지 않습니다.


선택을 더 쉽게 만드는 또 다른 상황은 sum, min, max, etcetera 및 복잡한 쿼리 (위에서 언급 한 금융 시스템에서와 같이)와 같은 집계 함수를 사용하고자 할 때 관계형 데이터베이스가 nosql 데이터베이스보다 편리 할 때입니다. Inverted 인덱스를 많이 사용하지 않는 한 nosql 데이터베이스에서는 불가능합니다. nosql을 사용하면 코드에서 집계 함수를 수행하거나 자체 columnfamily에 seperatly를 저장해야하지만이 작업은 매우 복잡해지고 nosql을 사용하여 얻은 성능이 저하됩니다.


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


실제 사례를 읽으십시오.

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

그들은 DB 동기화가 너무 느리기 때문에 MySql을 선택하지 않은 이유를 자세히 설명합니다.

Cassandra는 Amazon Dynamo 및 기타 고 가용성 NoSQL 데이터베이스와 같습니다.

안정성, 고 가용성 기능. 백업은 최대한 빨리 수행됩니다. 읽고 쓰기

BigTable 클론 인 HBase 보다 좋습니다. [위키 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.

카산드라는 다음과 같은 경우에 좋은 선택입니다 :

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

  2. DB에 많은 양의 글이있을 것입니다.

  3. Big Data, Hadoop, Hive 및 Spark와 통합해야한다는 요구 사항이 있습니다.

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

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

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

  7. 튜닝을위한 많은 커스터마이징 요구 사항이 있습니다.


버전 2.x에서는 원자 적으로 기록 된 batch 에서 CQL 문을 결합 할 수 있습니다. 모든 명령문이 성공하거나 모두 성공하지 못합니다. 경량 트랜잭션 에 대해서도 읽을 수 있습니다. 그 이상 - 카산드라에게 몇 가지 지속 관리자가 있습니다. 클라이언트 수준에서 외래 키 동작을 수행 할 수 있습니다. 예 : Achilles and Kundera .





database rdbms nosql cassandra