[ Cassandra ] Cassandra definitive guide(카산드라 완벽 가이드 정리). Chapter 2. Introducing Cassandra

Chapter 2. Introducing Cassandra

Cassandra in 50 Words or Less

"Apache Cassandra is an open source, distributed, decentralized, elastically scalable(탄력적인 확장성), highly available(고가용성), fault-tolerant, tuneably consistent, row-oriented database that bases its distribution design on Amazon's Dynamo and its data model on Google's Bigtable. Created at Facebook, it is now used at some of the most popular sites on the Web."

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(세 가지 모두 얻을수 있는).

[ Figure 2-2 ]

Although databases its on line two property

According to the Bigtable paper, the average percentage of server hours that "some data" was unavailable is 0.0047% (section 4), so this is relative, as we're talking about very robust systems already.

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

CA (Consistency, Availability)

To primarily support consistency and availability means that you're likely using two-phase commit for distributed transactions. It means that the system will block when a network partition occurs, so it may be that your system is limited to a single data center cluster in an attempt to mitigate(완화) this. If your application needs only this level of scale, this is easy to manage and allows you to rely on familiar, simple structures.

CP (Consistency, Partition tolerance)

To primarily(주로) support consistency and partition tolerance, you may try to advance your architecture by setting up data shards in order to scale. Your data will be consistent, but you still run the risk of some data becoming unavailable if nodes fail.

AP (Availability, Partition tolerance)

To primarily support availability and partition tolerance, your system may return inaccurate data, but the system will always be available, even in the face of network partitioning.

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의 오해와 진실

Brewer가 2000년에 이정리를 발표할 때 P에 대한 정의.

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

2002년에 이에 대해 Gilbert와 Lynch가 이 정리에 대해 증명에 사용된 P에 대한 새로운 정의

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중 하나 밖에 없다.

애초에 P는 네트워크 장애가 있을 수 있다는 것을 인정하느냐의 문제이고 이는 인정 할 수밖에 없는 문제이므로 처음부터 선택되어있는 것이다.

결국, CAP Theorem이 내포하고 있는 의미는 분산시스템에서 네트워크 장애상황일 때 일관성과 가용성 중 많아도 하나만 선택할 수 있다는 것이다.

하지만 이런 식의 해석은 정상 상황일 때의 분산시스템 동작을 서술해주지 못한다. 이에 대해 Daniel Abadi가 PACELC라는 아주 우아한 표기법을 제시하였다.

CAP보다는 PACELC를 사용하자

CAP는 분산시스템 디자이너의 선택에 도움을 주는 정리다. CAP가 장애 상황일 때의 선택에 대해 서술하는 것으로 생각하면, 정상 상황일 때의 선택에 대해 서술하지 못하게 된다.

그래서 정상상황일 때와 장애상황을 때를 나누어 설명하자는 것이 PACELC의 핵심이다. 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는 상충하며 둘 중 하나를 선택해야 한다. 모든 노드들에 새로운 데이터를 반영하는 것은 상대적으로 긴 응답시간이 필요하기 때문이다.

– HBase는 PC/EC이다. 장애 상황일때 C를 위해 A를 희생한다. 그렇지 않은 경우에도 C를 위해 L을 희생한다.

– Cassandra는 PA/EL이 가능하도록 디자인 되었다. 설정에 따라 Eventual Consistency의 특성을 가지게 되는데, 이 경우 PA/EL이 된다.

장애 상황인 경우에는 가능한 노드에만 데이터를 반영하고 정상으로 복구되면 필요한 노드에 데이터를 모두 반영한다. 정상상황일때도 Latency를 위해 모든 노드에 데이터를 반영하지 않는다.

결론

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

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