반응형

시스템에서 카산드라를 사용한지 3년이 넘어가면서 그 동안 도움을 받았거나 좋은 내용들의 글을 모아놨었는데 로컬에 남겨놓는건 찾기도 힘들고 언제 사라질지 모르니 포스팅으로 남겨본다.

1. How is data written?

https://docs.datastax.com/en/archived/cassandra/2.2/cassandra/dml/dmlHowDataWritten.html

 

How is data written?

Understand how Cassandra writes and stores data. Cassandra processes data at several stages on the write path, starting with the immediate logging of a write and ending in with a write of data to disk: Logging data in the commit log Writing data to the mem

docs.datastax.com

 

2. How is data read?

https://docs.datastax.com/en/archived/cassandra/3.0/cassandra/dml/dmlAboutReads.html

 

How is data read?

How Cassandra combines results from the active memtable and potentially multiple SSTables to satisfy a read. To satisfy a read, Cassandra must combine results from the active memtable and potentially multiple SSTables. Cassandra processes data at several s

docs.datastax.com

 

3. Materialized View Performance in Cassandra 3.x

https://www.datastax.com/dev/blog/materialized-view-performance-in-cassandra-3-x

 

Materialized View Performance in Cassandra 3.x | Datastax

DataStax, Titan, and TitanDB are registered trademarks of DataStax, Inc. and its subsidiaries in the United States and/or other countries. Apache, Apache Cassandra, Cassandra, Apache Tomcat, Tomcat, Apache Lucene, Lucene, Apache Solr, Apache Hadoop, Hadoop

www.datastax.com

 

4. Apache Cassandra Materialized View Design

https://docs.google.com/document/d/1sK96wsE3uwFqzrLQju_spya6rOTxojOKR9N7W-rPwdw/edit

 

Google 문서 - 온라인에서 문서를 작성하고 수정할 수 있으며 무료입니다.

하나의 계정으로 모든 Google 서비스를 문서로 이동하려면 로그인하세요.

accounts.google.com

 

5. Cassandra 3.0 Materialized Views Technical Deep Dive

http://www.doanduyhai.com/blog/?p=1930

 

Cassandra 3.0 Materialized Views Technical Deep Dive | DOAN DuyHai's blog

In this blog post, we’ll dig into the brand new materialized view feature of Cassandra 3.0. We’ll see how it is implemented internally, how you should use it to get the most of its performance and which caveats to avoid. For the remaining of this post Cass

www.doanduyhai.com

 

6. 카산드라 compaction관련 장애처리

http://knight76.tistory.com/entry/cassandra-compaction-%EA%B4%80%EB%A0%A8

 

cassandra gc 튜닝 - compaction과 full gc

cassandra를 운영하면서 CMS Full GC가 발생하면서 수십 초동안 stop the world (hang)이 발생했다. 이를 간단히 해결한 내용을 작성한다. Case #1 node repair를 하고 난 직후 바로 다른 table(colum family)에서..

knight76.tistory.com

 

7. Myths of Big Partitions

https://www.slideshare.net/DataStax/myths-of-big-partitions-robert-stupp-datastax-cassandra-summit-2016

 

Myths of Big Partitions (Robert Stupp, DataStax) | Cassandra Summit 2…

Large partitions shall no longer be a nightmare. That is the goal of CASSANDRA-11206. 100MB and 100,000 cells per partition is the recommended limit for a sing…

www.slideshare.net

 

8. Hinted Handoff: repair during write path

https://docs.datastax.com/en/cassandra/3.0/cassandra/operations/opsRepairNodesHintedHandoff.html

 

Hinted Handoff: repair during write path

Describes hinted handoff, repair during write path. On occasion, a node becomes unresponsive while data is being written. Reasons for unresponsiveness are hardware problems, network issues, or overloaded nodes that experience long garbage collection (GC) p

docs.datastax.com

 

9. Cassandra performance: the most comprehensive overview you’ll ever see

https://www.scnsoft.com/blog/cassandra-performance

 

Cassandra Performance: The Most Comprehensive Overview You’ll Ever See

Cassandra Performance: The Most Comprehensive Overview You’ll Ever See Head of Data Analytics Department, ScienceSoft Apache Cassandra obviously can’t tell the future. It can only enable you to organize data storage (or at least make it as organized as it

www.scnsoft.com

 

반응형
반응형
이전에 데이터 처리하는 어플리케이션을 개발할 때 NoSQL로 어떤걸 쓰면 좋을지 조사한 글을 포스팅해본다.
그 당시 고민했던 NoSQL 중 카산드라(Cassandra), HBASE, MongoDB 세 가지로 선정해 조사했었다.
RDBMS? NOSQL?
  • 데이터의 읽기 쓰기 등 퍼포먼스에 치중한다면 NOSQL, 트랜잭션과 같은 정합성 위주의 시스템을 사용한다면 RDBMS
  • RDBMS 컬럼 변경 용이하지 않음, NOSQL 컬럼 변경 용이
  • NOSQL의 경우 sorting, join, grouping, range query, index 매우 취약
  • RDBMS 학습 비용 x
  • NOSQL 학습 비용 소요 (운영시 어떤 장애상황이 생길지 예측이 어려움)
  • NOSQL 가장 큰 장점 (Scale-Out, RDBMS보다 상대적으로 빠른 쓰기/읽기)

NOSQL 분류
[ 키 밸류형 ] redis, memcached, Oracle Coherence
[ 컬럼형 ] Cassandra, HBASE, Cloud Datastore
[ 문서형 ] MongoDB, Couchbase, MarkLogic, PostgreSQL, MySQL, DynamoDB MS-DocumentDB
[ 그래프형 ] Neo4j

DataStore설 명장 점단 점
Cassandra

-Facebook에 의해 2008년 아파치 오픈소스로 공개된 분산 데이터 베이스 (자바 언어 기반) 
-컬럼 단위로 관리되어 컬럼형으로 분류 
-대용량의 데이터 트랜잭션에 대해 고성능 처리가 가능(실제 트위터 MYSQL -> Cassandra로 전환)

-대량으로 쓰기가 발생하는 서비스에 좋음 
-확장성이 뛰어남  
-Apache Foundation에서 개발중이며커뮤니티 활발 
- Scale-Out

-최소 3대 이상 구성(클러스터 환경) 
-복잡한 조건 검색 불가 
-데이터 갱신 및 입력시 Atomic한 처리가 힘듬

HBase

-대량 데이터를 우수한 성능으로 데이터 일관성을 보장하면서 다뤄야 할 때 주로 사용 
-대량 데이터 분석 및 처리를 위해 사용되는 Hadoop의 산하 프로젝트로 시작된 데이터베이스 (HDFS 및 MapReduce등과 함께 사용하기에 최적화) 
-수십 테러바이트가 넘는 빅데이터에 적합

-하둡 기반에서 동작하고 다양한 하둡 의 도구들과 상호 운영성이 좋음
-데이터 일관성 보장 우수(상대적)

-5대 미만에서는 사용할 수 없다(대규모 전용) 
-성능이 좋진 않다 (상대적)

MongoDB

-MongoDB는 10gen 사에서 개발된 높은 성능과 확장성을 가지고 있는 데이터베이스
NoSQL 데이터베이스에서는 문서형 데이터베이스로 분류(C언어 기반)
-데이터를 입력할때 데이터 구조 정보를 포함하여 BSON(JSON을 바이너리화한것)형식으로 저장하고, key value로 사용
-NON-SCHEMA
-비정형 데이터, 파일 데이터등의 스키마프리(Scheme free)모델에서 적합  - SQL 과 비슷한 방식의 쿼리 사용

-스키마 없이 사용 가능 
-SQL 과 비슷한 방식의 쿼리 사용 
-몽고는 쓰기할때 메모리에 먼저 Write 후에
  1분 단위로 Flushing하는 Write back 방식을     사용한기 때문에 write성능이 좋음
-Read시에는 파일의 Index를 메모리에 로딩해   놓고 찾는다(memory mapped file) - 빠름
-다양한 기능 제공

-JOIN이나 트랜잭션 처리가 불가능 
-디스크에 쓰기가 비동기식으로 이루어진다. 때문에 경우에 따라 데이터가 유실될 가능성도 있다.

[ Cassandra & HBase ]

  • 카산드라 클러스터 설정 및 구성이 HBase 클러스터 구성보다 훨씬 쉽다.
  • 카산드라가 일반적으로 write시 5배 이상의 더 나은 성능, read시 4배 이상의 성능을 보인다.

[ Cassandra & MongoDB ]

  • Cassandra 노드가 추가될수록 MonogoDB  보다 훨씬 나은 선형적인 성능 향상을 보인다.
    - 다중 Index가 필요한 구조라면 MongoDB를 선택하고, 데이터 항목 변경이 많고 unique access가 많은 경우라면 Cassandra가 적합
  • http://db-engines.com/en/system/Cassandra;MongoDB

성능비교

https://academy.datastax.com/planet-cassandra/nosql-performance-benchmarks
https://www.datastax.com/nosql-databases/benchmarks-cassandra-vs-mongodb-vs-hbase



반응형

+ Recent posts