[ Cassandra ] 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)

특징	DB기능	설명
Atomicity(원자성)	회복성의 보장, Commit/Rollback	트랜잭션은 분해가 불가능한 논리적 최소 단위로 실행 전체가 승인되거나 취소되어야 함 (All or Nothing)
Consistency(일관성)	무결성 제약조건, 동시성 제어	트랜잭션의 수행 이후 데이터는 무결성이 유지되고 모순되지 않아야 함
Isolation(고립성)	분산트랜잭션, Lock	다수의 트랜잭션이 동시에 수행되더라도 개별 트랜잭션의 결과에 영향을 미쳐서는 안됨
Durability(지속성)	회복기법, 회복 컴포넌트관리	성공적으로 수행된 트랜잭션은 해당 요인에 의해 변경 및 손실되지 않아야 함

• 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.