카산드라(Cassandra) ttl은 read의 성능에 영향을 미치는가?

테스트 환경 및 프로세스

1. 알파 카산드라(node3개)에 ttl을 설정한 테이블과 ttl설정을 하지 않은 테이블을 각각 만든다.
2. 각각의 테이블에 2만개씩의 데이터를 넣는다 (id, value1, value2)  - id(1~20000)
3. api로 해당 테이블을 select하는 요청(id는 1~20000 중 랜덤으로 선택)을 한다.(20초동안 2000번)

테스트 결과 1

99th percentile에 주목해주세요(요청의 99% 평균 처리시간을 의미합니다.

	1번	2번	3번
NO TTL 테이블 select 요청
TTL 걸린 테이블 select 요청

99th percentile을 보시면 알겠지만 ttl이 걸린 테이블이 오히려 처리속도가 더 빠른경우도 있습니다....(살짝 멘붕)

아무리 그래도 ttl걸린 테이블이 당연히 latency가 높을줄 알았는데....ㅎㅎ

그래서 각각의 테이블에 10000개의 데이터를 더 놓고 테스트를 진행하였습니다.

여기서 다른점은 ttl이 걸린 테이블에 임의로 10000개의 데이터의 ttl을 1분을 주고 tombstone이 발생하도록 하였습니다.

그리고 나서 다시 api로 select 테스트를 하였습니다.

테스트 결과2 (각각 테이블에 1만개씩 더 밀어넣음 - ttl걸린테이블에는 tombstone이 발생하도록 ttl을 1분으로 설정하고 넣음)

	1	2	3
NO TTL 테이블 select 요청
TTL 걸린 테이블 select 요청

결과를 보시면 1만개씩을 더 밀어넣었지만 기존 TTL이 걸리지 않은 테이블은 첫 번째 테스트 속도와 거의 비슷한 결과를 도출한 반면

1만개의 데이터를 tombstone이 발생하도록 밀어넣은 TTL이 설정된 테이블은 속도가 현저히 떨어진 것을 확인해볼 수 있습니다.

그렇다면 왜 이런 결과가 나온것인가?

카산드라는 read요청이 들어올 경우 첫 번째로 memtable을 뒤지고
그 다음으로 row cache데이터가 있다면 row cache데이터를 확인합니다. (카산드라는 빈번하게 요청되는 row를 위한 캐시기능을 제공합니다)
row cache에도 데이터가 없는 경우 Bloom filter(메모리에 상주) 확인하여 찾는 row의  키가 있는 SSTables를 확인하여
해당 SSTables를 통해서 데이터를 읽어오게 됩니다.

따라서 데이터가 insert되면서 Bloom filter SSTables내의 데이터의 키값들이 해싱되어 업데이트 되는 경우에는
실제로 SSTables(dis I/O)를 사용하지 않고 데이터를 가지고 오게되어 빠르게 처리가 가능합니다.

하지만 Bloom filter의 해싱된 데이터들이 업데이트 되기전 SSTables의 값이 delete나 drop등으로 변경되는 경우에는
Bloom filter와 SSTable사이간 데이터의 정밀도가 떨어지게 됩니다.

이 경우 Bloom filter는 이미 SSTable내의 Tombstone된 데이터를 가르키게 되고 잘못된 포인팅으로 인해
카산드라는 SSTables에서 직접 해당 데이터를 다시 가져오는 작업(Disk I/O 발생)을 진행합니다.
이러한 이유로 ttl이 걸린 테이블 혹은 row에서 select시 성능이 떨어질 수 있다고 생각됩니다.
더 정확한 내용은 다음 문서를 참고해보시면 좋을 것 같습니다.
[Cassandra how is data read?](How is data read?)

TTL을 설정하고도 성능을 떨어트리지 않는 방법이 있는가?

SSTables과 Bloom Filter 정밀도를 높여서 운영하는 방법입니다.
하지만 모든선택에는 tradeoff가 있듯이 정밀도를 높이게 되면 더 많은 메모리를 필요로 하게 됩니다.
설정 방법은 테이블을 만들 때 bloom_filter_fp_chance 옵션을 주는 방법입니다.
추천값은 0.1이지만 최대 1.0까지 설정이 가능합니다.
1.0으로 설정할 경우 SSTables과의 정밀도를 높일 수 있으나 더 많은 메모리를 필요로 하기 때문에
상황에 맞는 설정값으로 운영하시면 될 것 같습니다.

Chapter 2. Introducing Cassandra

Cassandra in 50 Words or Less

Distributed and Decentralized

• The fact that Cassandra is decentralized means that there is no single point of failure.
• All of the nodes in a Cassandra cluster function exactly the same. This is sometimes referred to as “server symmetry.” (서버 대칭)
• they are all doing the same thing, by definition there can't be a special host that is coordinating activities(활동을 조정하는),
  as with the master/slave setup that you see in MySQL, Bigtable, and so many others.
• RDMBS(master/slave) - centerlized, NOSQL(cluster) - distributed
• Note that while we frequently understand master/slave replication in the RDBMS world, there are NoSQL databases such as MongoDB that follow the master/slave scheme as well.
• Decentralization has two key advantages
  • it's simpler to use than master/slave, and it helps you avoid outages.(중단을 방지)
  • It can be easier to operate and maintain a decentralized store than a master/slave store because all nodes are the same.
    That means that you don't need any special knowledge to scale; setting up 50 nodes isn't much different from setting up one.
• Cassandra is distributed and decentralized, there is no single point of failure, which supports high availability.

Elastic Scalability

• Scalability is an architectural feature of a system that can continue serving a greater number of requests with little degradation in performance(성능저하거의없이)
• Horizontal scaling means adding more machines that have all or some of the data on them so that no one machine has to bear the entire burden of serving requests.
• You don't have to restart your process. You don't have to change your application queries. You don't have to manually rebalance the data yourself. Just add another machine
• you won't need to upset(뒤집다) the entire apple cart to scale back (!!!!important)

High Availability and Fault Tolerance

• Cassandra is highly available. You can replace failed nodes in the cluster with no downtime, and you can replicate data to multiple data centers
  to offer improved local performance and prevent downtime if one data center experiences a catastrophe(대재앙) such as fire(화재) or flood.

Tuneable Consistency

• When considering consistency, availability, and partition tolerance, we can achieve only two of these goals in a given distributed system, a trade-off known as the CAP theorem
• In Cassandra, consistency is not an all-or-nothing proposition.
• We might more accurately term it “tuneable consistency” because the client can control the number of replicas to block on for all updates.
• The replication factor lets you decide how much you want to pay in performance to gain more consistency.

Brewer's CAP Theorem

• Consistency
  • All database clients will read the same value for the same query, even given concurrent updates.
• Availability
  • All database clients will always be able to read and write data.
• Partition tolerance
  • The database can be split into multiple machines; it can continue functioning in the face of network segmentation breaks.
• Brewer's theorem is that in any given system, you can strongly support only two of the three.
• “You can have it good, you can have it fast, you can have it cheap: pick two.”

• Figure2-1illustrates visually that there is no overlapping(중첩) segment where all three are obtainable(세 가지 모두 얻을수 있는).

So what does it mean in practical terms(실제적인 측면) to support only two of the three facets of CAP?

Row-Oriented

• Cassandra's data model can be described as a partitioned row store, in which data is stored in sparse multidimensional(다차원) hashtables.
• "Partitioned" means that each row has a unique key which makes its data accessible, and the keys are used to distribute the rows across multiple data stores.

High Performance

• Cassandra was designed specifically from the ground up to take full advantage of multiprocessor/multi-core machines, and to run across many dozens of these machines housed in multiple data centers.
• As you add more servers, you can maintain all of Cassandra's desirable properties(바람직한 특성) without sacrificing performance(성능저하).

Is Cassandra a Good Fit for My Project?

• if you expect that you can reliably serve traffic with an acceptable level of performance with just a few relational databases, it might be a better choice to do so,
  simply because RDBMSs are easier to run on a single machine and are more familiar.
• the ability to handle application workloads that require high performance at significant write volumes with many concurrent client threads is one of the primary features of Cassandra.

그렇다면 DMP에 Cassandra를 쓰는게 적합한가???

번외

CAP Theorem

• CAP Theorem은 분산시스템에서 일관성(Consistency), 가용성(Availability), 분할 용인(Partition tolerance)이라는 세 가지 조건을 모두 만족할 수 없다는 정리로, 세 가지 중 두 가지를 택하라는 것으로 많이 알려졌있다.
• CAP는 분산시스템 설계에서 기술적인 선택을 돕는다. 분산시스템이 모든 것 특성을 만족시킬 수 없음을 인지하게 하고 선택지를 제공해주는 것이다.

CAP Theorem의 오해와 진실

The system continues to operate despite arbitrary message loss or failure of part of the system

The network will be allowed to lose arbitrarily many messages sent from one node to another

• CAP Theorem의 정의를 살펴보면 마치 C,A,P가 동등한 선상에 있는 것처럼 느껴진다. 이런 연유로 C,A,P가 모두 분산시스템의 특성에 대한 것으로 여겨지지만, 실상은 그렇지 않다.
  앞에서 언급한 정의를 생각해본다면, C와 A는 분산시스템의 특성이지만, P는 그 분산시스템이 돌아가는 네트워크에 대한 특성이다.
• CAP Theorem의 정의가 이해하기 어렵게 되어 있다. 세 가지 특성 중 두 개까지 고를 수 있다는 것으로도 많이 알려졌는데 마치 P를 포기하고 CA를 선택할 수도 있는 것 같은 기분을 들게 한다.
  하지만 실상은 P의 정의는 네트워크가 임의의 메시지 손질을 할 수 있다는 것을 허용하느냐는 의미로 네트워크가 가끔 장애가 날 수 있다는 것을 인정하냐는 것이다.
  P의 선택을 배제하려면 절대로 장애가 나지 않는 네트워크를 구성해야하지만 그런 것은 세상에 존재하지 않는다. 따라서 원하든 원하지 않든 P는 선택되어야 하며 결국 선택권은 C나 A중 하나 밖에 없다.

CAP보다는 PACELC를 사용하자

if there is a partition (P) how does the system tradeoff between availability and consistency (A and C);

else (E) when the system is running as normal in the absence of partitions, how does the system tradeoff between latency (L) and consistency (C)?

• 파티션(네트워크 장애)상황일 때에는 A와 C는 상충하며 둘 중 하나를 선택해야 한다는 것이다.
• 변경된 값을 모든 노드에서 바라볼 수 있도록 하려면 신뢰성 있는 프로토콜을 이용하여 데이터에 관여하는 모든 노드에 데이터가 반영되어야 한다.
  하지만 네트워크 단절이 일어나 몇 개의 노드에 접근할 수 없을 때 C를 위해 데이터 반영이 아예 실패하던지 C를 포기하고 일단 접근 가능한 노드들이게 만 데이터를 반영하던지 둘 중의 하나만 골라야 한다.
• 정상상황일 때에는 L과 C는 상충하며 둘 중 하나를 선택해야 한다. 모든 노드들에 새로운 데이터를 반영하는 것은 상대적으로 긴 응답시간이 필요하기 때문이다.

결론

• 절대로 장애가 없는 네트워크는 존재하지 않으며, 따라서 분산시스템에서 P는 무조건 인정하고 들어가야 한다
• 네트워크가 단절되었을 때 시스템이 어떻게 동작할지 결정해야 하며, 이 때 C와 A를 모두 만족시키는건 불가능하므로 둘 중에 하나를 골라야 한다.
• CAP로 표현하는 것보다 PACELC로 표현하는 것이 훨씬 명확하다.

[ Cassandra definitive guide(카산드라 완벽 가이드 정리). Chapter1. Beyond Relational Databases ]

Chapter1. Beyond Relational Databases

Preface

• Apache Cassandra는 2009년 1월 Apache에서 Incubator프로젝트로 처음 시작했다.
• 카산드라는 페이스북, 트위터, 넥플릭스(Netflix)를 포함한 웹상의 가장 큰 회사들에 사용되고 있다.
• 빠른 쓰기를 수행하고 수백 테라 바이트의 데이터를 분산화 시켜 저장할 수 있고 단일 실패 지점(SPOF)가 없다.
• 이 책은 Apache Cassandra 3.0과 DataStax Java Driver 버전 3.0을 사용하여 개발되었습니다.

Chapter1. Beyond Relational Databases

If at first the idea is not absurd, then there is no hope for it.
Albert Einstein

What's Wrong with Relational Databases?

• We encounter scalability problems(확장성 문제) when our relational applications become successful and usage goes up.
• Joins are inherent in(내재되어 있다) any relatively normalized relational database(상대적으로 정규화된 데이터베이스) of even modest size, and joins can be slow.
• The way that databases gain consistency is typically through the use of transactions, which require locking some portion of the database so it's not available to other clients.
• This can become untenable(견딜수 없는) under very heavy loads, as the locks mean that competing users start queuing up, waiting for their turn to read or write the data

We typically address these problems in one or more of the following ways.

• Throw hardware at the problem by adding more memory, adding faster processors, and upgrading disks.This is known as vertical scaling. - This can relieve you for a time.

• When the problems arise again, the answer appears to be similar: now that one box is maxed out(최대치), you add hardware in the form of additional boxes in a database cluster.

• We try to improve our indexes and optimize the queries. But this also has a limitaion.

• When we use cache, Now we have a consistency problem between updates in the cache and updates in the database, which is exacerbated(악화시키다) over a cluster.

• For addressing these problems we try denormalization. But this violates rules of relational data.

RDBMS: The Awesome and the Not-So-Much

• There are many reasons that the relational database has become so overwhelmingly popular over the last four decades.
  • An important one is the Structured Query Language (SQL), which is feature-rich and uses a simple, declarative syntax.
• SQL is easy to use. The basic syntax can be learned quickly, and conceptually SQL and RDBMSs offer a low barrier to entry.

TRANSACTIONS, ACID-ITY, AND TWO-PHASE COMMIT

• RDBMSs and SQL also support transactions
• ACID (Atomic, Consistent, Isolated, Durable)

• Transactions become difficult under heavy load. When you first attempt to horizontally scale a relational database, making it distributed, you must now account for(고려하다) distributed transactions,
  where the transaction isn't simply operating inside a single table or a single database, but is spread across multiple systems.
• In order to continue to honor the ACID properties of transactions, you now need a transaction manager to orchestrate(조정) across the multiple nodes.
• In order to account for successful completion across multiple hosts(여러 호스트에서 성공적 완료를 설명하기 위해), the idea of a two-phase commit (sometimes referred to as “2PC”) is introduced.
• But then, because two-phase commit locks all associated resources, it is useful only for operations that can complete very quickly.

Gregor Hohpe, a Google architect, wrote a wonderful and often-cited blog entry called“Starbucks Does Not Use Two-Phase Commit”.

스타벅스의 사례에 접목해보면, "2단계 커밋"은 점원(cashier)이 커피가 완성될 때까지 한 고객만을 바라보며 영수증과 돈을 테이블 위에 올려놓고 기다리는 것과 같습니다. 마지막으로 음료가 준비되면, 영수증과 돈으로 일거에 교환하는 것입니다. 이런 상황에서는 점원뿐만 아니라 고객까지도 "트랜잭션(거래)"이 끝날 때 까지 자리를 떠날 수 없게 됩니다. 이러한 "2단계 커밋" 방식을 적용하게 되면 일정 시간에 서비스 할 수 있는 고객 수는 극적으로 감소할 것이고, 스타벅스의 비즈니스를 확실하게 망하게 만들 것입니다. 이것은 2단계 커밋이 일상을 좀 더 단순하게 만들 수는 있지만, 메시지들의 자유로운 흐름을 방해하게 된다(그리고 확장성을 해친다)는 사실을 일깨워 주는 사례입니다. 왜냐하면, 비동기의 다중 작업 흐름 속에서 트랜잭션의 상태를 관리해야 하기 때문입니다.
출처: http://sunnykwak.tistory.com/100 一生牛步行

Summary

• Relational databases are very good at solving certain(특정) data storage problems, but because of their focus, they also can create problems of their own when it's time to scale.
• The recent interest in non-relational databases reflects the growing sense of need in the software development community for web scale data solutions.

번외

• 2000년 후반으로 넘어오면서 인터넷이 활성화되고, 소셜네트워크 서비스 등이 등장하면서 관계형 데이터 또는 정형데이터가 아닌 데이터, 즉 비정형데이터라는 것을 보다 쉽게 담아서 저장하고 처리할 수 있는 구조를 가진 데이터 베이스들이 관심을 받게 되었다.
  • 해당 기술의 발전과 더불어 NoSQL 데이터베이스가 각광을 받게되었고 어떤 엔지니어들은 NoSQL을 Modern web-scale databases라고 정의하기도 한다고 한다.

NoSQL과 RDBMS 차이점

• 관계형 모델을 사용하지 않으며 테이블간의 조인 기능이 없음
• 대부분 여러 대의 데이터베이스 서버를 묶어서(클러스터링) 하나의 데이터베이스를 구성
• 관계형 데이터베이스에서는 지원하는 Data처리 완결성(Transaction ACID 지원) 미보장
• 데이터의 스키마와 속성들을 다양하게 수용 및 동적 정의(Schema-less)
• 데이터베이스의 중단 없는 서비스와 자동 복구 기능지원
• 다수가 Open Source로 제공
• 확장성, 가용성이 높음

NoSQL 종류

Key Value DB

• key와 value의 쌍으로 데이터가 저장되는 단순한 형태의 솔루션
• Riak, Vodemort, Tokyo etc.

Columnar Store

• Key Value에서 발전된 형태의 Column Family데이터 모델을 사용
• HBasem Cassandra, ScyllaDB etc.

Document DB

• JSON, XML과 같은 Collection 데이터 모델 구조를 채택하고 있다.
• MongoDB, CoughDB etc.

Graph DB

• Nodes, Relatsionship, Key-value 데이터 모델을 채용하고 있다.
• Neo4J, OreientDB etc.

데이터 엔지니어로 살아가기 113일째(카산드라) - 0621

실시간으로 데이터를 처리해서 카산드라에 밀어넣고 있는데 알파에 같은 환경을 구축해서 데이터파이프라인 구축하는게 생각보다 너무 오래걸리고 있다. 그동안 알파환경이 관리가 제대로 되고 있지 않아 생각보다 여러가지 문제들에 부딪히며 해결하고 있는 중이다.

오늘 실시간 잡 로그를 보던 중 마이크로배치(10초)단위로 데이터를 읽어와 처리할 때마다 카산드라 커넥션을 맺었다 끊는 작업을 하고 있었다. 당연히 커넥션풀을 이용해 처리가 될 줄 알았는데...

무튼 알파환경에서도 리얼 환경과 동일한 데이터 파이프라인을 구축해 실제 테스트를 진행할 수 있도록 해야겠다.

알파환경이 구축되는 대로 카산드라와 HBASE에 대한 학습이 좀 더 체계적으로 필요할 듯 싶다.